An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-15

[Ballot comment]
The discrepancy between the architecture document description in the charter and the draft previous abstract is now fixed. This is an improvement. However, I don't see how this document is actually useful. It's a mix of: "we could use X, Y, Z", but at the same time "we MUST support very detailed notifications" and we must integrate the outcome of the various requirement documents.

I don't see how the document could be salvaged. Anyway, I will not stand in the way of this publication, and will abstain.
It's probably my fault: I should have paid more attention at the charter discussion time.

===========================================================================

A couple of points, not all of them are minor (I've been wondering: COMMENT or DISCUSS. Let's go for a COMMENT)

- "Second is the access to structured information and state that is frequently not directly configurable".
I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
It would be good if the terminology were aligned.

-
  This I2RS architecture assumes a data-model driven protocol where the
  data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
  ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
  drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). "

RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1
btw, this "YANG" not "Yang"

- Are the two sentences redundant?
  As can be seen in Figure 1, an I2RS client can communicate with
  multiple I2RS agents.  An I2RS client may connect to one or more I2RS
  agents based upon its needs.

- 
  There are several key benefits for I2RS in using model-driven
  architecture and protocol(s).  First, it allows for transferring
  data-models whose content is not explicitly implemented or understood.

Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood.
Really confused.

-
  Two of the existing protocols which the
  which may be re-used are NETCONF [RFC6241] and RESTCONF
  [I-D.ietf-netconf-restconf].

"may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification)

    To handle I2RS Agent failure, the I2RS Agent must
      use two different notifications.

      NOTIFICATION_I2RS_AGENT_STARTING:  This notification signals to the
          I2RS Client(s) that the associated I2RS Agent has started.  It
          includes an agent-boot-count that indicates how many times the
          I2RS Agent has restarted since the associated routing element
          restarted.  The agent-boot-count allows an I2RS Client to
          determine if the I2RS Agent has restarted.  (Note: This
          notification will be only transmitted to I2RS clients which are
          know in some way after a reboot.)

- editorial:
  Optionally, a routing element may permit a priority to be to be

-
  For the case when the I2RS ephemeral state always wins for a data
  model, if there is an I2RS ephemeral state value it is installed
  instead of the local configuration state.

Again, I read that sentence multiple times, and could not understand it

- figure 2. "The initial services included in the I2RS architecture are as follows."
Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter?

-   
  The I2RS
  protocol may need to use several underlying transports (TCP, SCTP
  (stream control transport protocol), DCCP (Datagram Congestion
  Control Protocol)), with suitable authentication and integrity
  protection mechanisms

Do you really want to have define transports?



And below is Fred Baker's OPS DIR review:

The first nit is a statement in section 1.1:

  Such an interface also facilitates the injection of ephemeral state
  into the routing system.  Ephemeral state on a router is the state
  which does not survive a the reboot of a routing device or the reboot
  of the software handling the I2RS software on a routing device.

Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage.

I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times.


At the top of page 6, the first paragraph reads:

  The I2RS agent provides read and write access to selected data on the
  routing element that are organized into I2RS Services. Section 4
  describes how access is mediated by authentication and access control
  mechanisms.  Figure 1 shows I2RS agents being able to write ephemeral
  static state (e.g.  RIB entries), and to read from dynamic static
  (e.g.  MPLS LSP-ID or number of active BGP peers).  In addition, the

I have a hunch the authors intended to complete the final sentence.


In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says

  Thus, one of the key aims for I2RS is the keep the protocol and
  modeling architecture simple.  So for each architectural component or
  aspect, we ask ourselves "do we need this complexity, or is the
  behavior merely nice to have?"

Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple.

So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?"


In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read

  An I2RS Client is not automatically trustworthy.  Each I2RS Client is
  associated with identity with a set of scope limitations.

I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well.

[Ballot comment]
The discrepancy between the architecture document description in the charter and the draft previous abstract is now fixed. This is an improvement. However, I don't see how this document is actually useful. It's a mix of: "we could use X, Y, Z", but at the same time "we MUST support very detailed notification", and we must integrate the outcome of the various requirement documents.

I don't see how the document could be salvaged. Anyway, I will not stand in the way of this publication, and will abstain.
It's probably my fault: I should have paid more attention at the charter discussion time.

===========================================================================

A couple of points, not all of them are minor (I've been wondering: COMMENT or DISCUSS. Let's go for a COMMENT)

- "Second is the access to structured information and state that is frequently not directly configurable".
I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
It would be good if the terminology were aligned.

-
  This I2RS architecture assumes a data-model driven protocol where the
  data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
  ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
  drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). "

RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1
btw, this "YANG" not "Yang"

- Are the two sentences redundant?
  As can be seen in Figure 1, an I2RS client can communicate with
  multiple I2RS agents.  An I2RS client may connect to one or more I2RS
  agents based upon its needs.

- 
  There are several key benefits for I2RS in using model-driven
  architecture and protocol(s).  First, it allows for transferring
  data-models whose content is not explicitly implemented or understood.

Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood.
Really confused.

-
  Two of the existing protocols which the
  which may be re-used are NETCONF [RFC6241] and RESTCONF
  [I-D.ietf-netconf-restconf].

"may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification)

    To handle I2RS Agent failure, the I2RS Agent must
      use two different notifications.

      NOTIFICATION_I2RS_AGENT_STARTING:  This notification signals to the
          I2RS Client(s) that the associated I2RS Agent has started.  It
          includes an agent-boot-count that indicates how many times the
          I2RS Agent has restarted since the associated routing element
          restarted.  The agent-boot-count allows an I2RS Client to
          determine if the I2RS Agent has restarted.  (Note: This
          notification will be only transmitted to I2RS clients which are
          know in some way after a reboot.)

- editorial:
  Optionally, a routing element may permit a priority to be to be

-
  For the case when the I2RS ephemeral state always wins for a data
  model, if there is an I2RS ephemeral state value it is installed
  instead of the local configuration state.

Again, I read that sentence multiple times, and could not understand it

- figure 2. "The initial services included in the I2RS architecture are as follows."
Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter?

-   
  The I2RS
  protocol may need to use several underlying transports (TCP, SCTP
  (stream control transport protocol), DCCP (Datagram Congestion
  Control Protocol)), with suitable authentication and integrity
  protection mechanisms

Do you really want to have define transports?



And below is Fred Baker's OPS DIR review:

The first nit is a statement in section 1.1:

  Such an interface also facilitates the injection of ephemeral state
  into the routing system.  Ephemeral state on a router is the state
  which does not survive a the reboot of a routing device or the reboot
  of the software handling the I2RS software on a routing device.

Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage.

I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times.


At the top of page 6, the first paragraph reads:

  The I2RS agent provides read and write access to selected data on the
  routing element that are organized into I2RS Services. Section 4
  describes how access is mediated by authentication and access control
  mechanisms.  Figure 1 shows I2RS agents being able to write ephemeral
  static state (e.g.  RIB entries), and to read from dynamic static
  (e.g.  MPLS LSP-ID or number of active BGP peers).  In addition, the

I have a hunch the authors intended to complete the final sentence.


In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says

  Thus, one of the key aims for I2RS is the keep the protocol and
  modeling architecture simple.  So for each architectural component or
  aspect, we ask ourselves "do we need this complexity, or is the
  behavior merely nice to have?"

Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple.

So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?"


In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read

  An I2RS Client is not automatically trustworthy.  Each I2RS Client is
  associated with identity with a set of scope limitations.

I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well.

[Ballot comment]

- If i2rs were used to control home networks, then that would
raise more privacy issues, e.g. the agent's IP address can be
privacy sensitive. Would it be useful to rule that out of
scope? E.g. to say that i2rs SHOULD NOT be used where the
agent/router in question is specific to one person or home?

- section 2: security role, hmm..... Do netconf/restconf have
the concept of mapping identifiers to roles? If not, that
might be tricky to graft on. Not sure.

- section 4: "Mutual authentication between the I2RS Client
and I2RS Agent is required. " yay! thanks:-) Even better if
you did s/Mutual/Strong mutual/ to prevent someone saying that
TCP-MD5 is good enough.

- section 4: "The primary communication channel that is used
for client authentication and then used by the client to write
data requires integrity, confidentiality and replay
protection." yay! again! :-)

- section 4: "Other communications via I2RS may not require
integrity, confidentiality, and replay protection.  For
instance, if an I2RS Client subscribes to an information
stream of prefix announcements from OSPF, those may require
integrity but probably not confidentiality or replay
protection." sorry, boo! :-)

It's often unsafe to mix and match differently protected sets
of data between the same sets of entities. I think you'd be
better off there saying that the requirements may
*exceptionnally* differ but usually only because of e.g. some
level of broadcast or multicast being part of the story, where
we don't have good usable security solutions today. (This is
not a DISCUSS because I think the protocol work will end up
saying "just use TLS always" as that'll be simpler and better,
so I hope this'll be a non-issue. If you know already that
there's some other plan in place, then please say so we can
chat now and avoid a trickier discussion later.)

- section 4: I think you're heading here towards use of TLS
and not object level security. Is that right? If so, would it
be useful to say so? (Just so as to correctly set expectations
for later.)

- 7.7: Would it be useful to say that the relevant information
here is only about network state and stastics and not about
connections (e.g. who spoke to whom) or payloads?  That might
save some discussions about RFC2804 later on.

[Ballot comment]
Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet:

---

Minor Concerns:

Section 4.2 talks about authorization.  I would expect policy to
dictate that some writes come from a specific source, but it is
unclear to me whether I2RS can require that a particular write
request arrive on a particular channel.  Is this desirable?  If so,
please expand the discussion of authorization to cover this point.


Nits:

Sometimes you say "i2rs architecture", but it should say "I2RS
architecture" to be consistent throughout the document.

Sometimes you say "I2RS Agent" and other times you say "I2RS agent".
Please pick one and use it consistently.

Sometimes you say "I2RS Client" and other times you say "I2RS client".
Please pick one and use it consistently.

Section 3: s/ may may vary based / may vary based /

Section 6.3: s/ the yang data model / the YANG data model /

Section 6.4.2: some bullets have periods, but others do not.

Section 7.1: s/ Yang / YANG / (more than one place)

[Ballot comment]
In this text:

7.1.  One Control and Data Exchange Protocol

  The I2RS
  protocol may need to use several underlying transports (TCP, SCTP
  (stream control transport protocol), DCCP (Datagram Congestion
  Control Protocol)), with suitable authentication and integrity
  protection mechanisms.  These different transports can support
  different types of communication (e.g. control, reading,
  notifications, and information collection) and different sets of
  data.  Whatever transport is used for the data exchange, it must also
  support suitable congestion control mechanisms.  The transports
  chosen should be operator and implementor friendly to ease adoption.
 
I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios.

[Ballot comment]
A couple of points, not all of them are minor (I've been wondering: COMMENT or DISCUSS. Let's go for a COMMENT)

- "Second is the access to structured information and state that is frequently not directly configurable".
I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
It would be good if the terminology were aligned.

-
  This I2RS architecture assumes a data-model driven protocol where the
  data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
  ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
  drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). "

RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1
btw, this "YANG" not "Yang"

- Are the two sentences redundant?
  As can be seen in Figure 1, an I2RS client can communicate with
  multiple I2RS agents.  An I2RS client may connect to one or more I2RS
  agents based upon its needs.

- 
  There are several key benefits for I2RS in using model-driven
  architecture and protocol(s).  First, it allows for transferring
  data-models whose content is not explicitly implemented or understood.

Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood.
Really confused.

-
  Two of the existing protocols which the
  which may be re-used are NETCONF [RFC6241] and RESTCONF
  [I-D.ietf-netconf-restconf].

"may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification)

    To handle I2RS Agent failure, the I2RS Agent must
      use two different notifications.

      NOTIFICATION_I2RS_AGENT_STARTING:  This notification signals to the
          I2RS Client(s) that the associated I2RS Agent has started.  It
          includes an agent-boot-count that indicates how many times the
          I2RS Agent has restarted since the associated routing element
          restarted.  The agent-boot-count allows an I2RS Client to
          determine if the I2RS Agent has restarted.  (Note: This
          notification will be only transmitted to I2RS clients which are
          know in some way after a reboot.)

- editorial:
  Optionally, a routing element may permit a priority to be to be

-
  For the case when the I2RS ephemeral state always wins for a data
  model, if there is an I2RS ephemeral state value it is installed
  instead of the local configuration state.

Again, I read that sentence multiple times, and could not understand it

- figure 2. "The initial services included in the I2RS architecture are as follows."
Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter?

-   
  The I2RS
  protocol may need to use several underlying transports (TCP, SCTP
  (stream control transport protocol), DCCP (Datagram Congestion
  Control Protocol)), with suitable authentication and integrity
  protection mechanisms

Do you really want to have define transports?



And below is Fred Baker's OPS DIR review:

The first nit is a statement in section 1.1:

  Such an interface also facilitates the injection of ephemeral state
  into the routing system.  Ephemeral state on a router is the state
  which does not survive a the reboot of a routing device or the reboot
  of the software handling the I2RS software on a routing device.

Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage.

I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times.


At the top of page 6, the first paragraph reads:

  The I2RS agent provides read and write access to selected data on the
  routing element that are organized into I2RS Services. Section 4
  describes how access is mediated by authentication and access control
  mechanisms.  Figure 1 shows I2RS agents being able to write ephemeral
  static state (e.g.  RIB entries), and to read from dynamic static
  (e.g.  MPLS LSP-ID or number of active BGP peers).  In addition, the

I have a hunch the authors intended to complete the final sentence.


In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says

  Thus, one of the key aims for I2RS is the keep the protocol and
  modeling architecture simple.  So for each architectural component or
  aspect, we ask ourselves "do we need this complexity, or is the
  behavior merely nice to have?"

Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple.

So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?"


In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read

  An I2RS Client is not automatically trustworthy.  Each I2RS Client is
  associated with identity with a set of scope limitations.

I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well.

[Ballot comment]
Hi there,

Firstly, I support Alvaro's two significant comments, especially with regards to the outcomes of the I2RS initiated change. My reading of the draft is that the resulting architecture espouses to judge intent, or the very least the outcome of the intent, as safe. How? Apologies if I read more into this than intended, please help clarify.

I only saw one nit that hadn't been noticed in other comments.
Section 3: para, last sentence. "may may"

Thanks

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

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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-i2rs-architecture-13.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: i2rs@ietf.org, mach.chen@huawei.com, draft-ietf-i2rs-architecture@ietf.org, db3546@att.com, i2rs-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Architecture for the Interface to the Routing System) to Informational RFC


The IESG has received a request from the Interface to the Routing System
WG (i2rs) to consider the following document:
- 'An Architecture for the Interface to the Routing System'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the IETF architecture for a standard,
  programmatic interface for state transfer in and out of the Internet
  routing system.  It describes the basic architecture, the components,
  and their interfaces with particular focus on those to be
  standardized as part of the Interface to Routing System (I2RS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes an architecture for a standard, programmatic
  interface for state transfer in and out of the internet routing
  system.  It describes the basic architecture, the components, and
  their interfaces with particular focus on those to be standardized as
  part of I2RS.

Working Group Summary

  There has been significant debate and discussion relating to template,
  multi-head control, security and consensus was made on these topics.
 
Document Quality

  There was active discussion in the WG and the document passed through
  a number of iterations reflecting that. This document has been well
  reviewed and updated to reflect comments received in WG last call.

Personnel

  Document Shepherd: Mach Chen
  Responsible Area Director: Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has reviewed the draft and raised some editoral
  comments that also have been solved in the latest version. After the review,
  the Document Shepherd thinks that there is no outstanding issue with the
  draft and it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is strong consensus from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarizes the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
 
  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
 
  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
 
  Not applicable.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
 
  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
 
  This document includes no request to IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes an architecture for a standard, programmatic
  interface for state transfer in and out of the internet routing
  system.  It describes the basic architecture, the components, and
  their interfaces with particular focus on those to be standardized as
  part of I2RS.

Working Group Summary

  There has been significant debate and discussion relating to template,
  multi-head control, security and consensus was made on these topics.
 
Document Quality

  There was active discussion in the WG and the document passed through
  a number of iterations reflecting that. This document has been well
  reviewed and updated to reflect comments received in WG last call.

Personnel

  Document Shepherd: Mach Chen
  Responsible Area Director: Adrian Farrel

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has reviewed the draft and raised some editoral
  comments that also have been solved in the latest version. After the review,
  the Document Shepherd thinks that there is no outstanding issue with the
  draft and it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is strong consensus from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarizes the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
 
  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
 
  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
 
  Not applicable.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
 
  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
 
  This document includes no request to IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Not applicable.