Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Apr 2016 21:34:21 -0400

Joel: 

Follow-up on this stream after IETF.   In many ways, the protocol strawman
is the document which proposes using pieces X, Y, and Z in ways A, B, and C
to solve the I2RS problem.  Perhaps, the protocol strawman should have a
section that summarizes the requirements and solutions.  

Sue 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 8:17 AM
To: Benoit Claise; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)

Benoit, you seem to be looking for a level of specificity in the
architecture that the working group never intended.  The charter calls for a
high level architecture.

I believe your comment calls out an interesting gap in the charter, as there
is no document called out which actually says "we are using pieces X, Y, and
Z, in ways A, B, and C, to solve the I2RS problem."

We could have tried to use the architecture document for that, but the
intention was to use the architecture document to guide the selection of
protocol and mechanisms.

Yours,
Joel

On 3/24/16 6:53 AM, Benoit Claise wrote:
> Sue,
>
>>   >Two of the existing protocols which the
>>   > which may be re-used are NETCONF [RFC6241] and RESTCONF
>>   > [I-D.ietf-netconf-restconf].
>>
>>> editorial "may be reused".  / I will check with RFC editor (some 
>>> people say
>> reused /re-used).
>>
>>> 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)
>>
>> Sue: NETCONF and RESTCONF will be supported as part of the I2RS
protocols.
>> The architecture does out rule out other data transfer protocols, but 
>> says the WG will design I2RS as a higher level protocol that combines 
>> other protocols (NETCONF/RESTCONF + x).
> This is what I could not understand with the draft sentence: "Two of 
> the existing protocols which the which may _be re-used_ are NETCONF 
> [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
> Sure many things could be reused. I'm expecting from an architecture 
> document to explain which pieces are used and how they are used.
>> The I2RS requirements documents and
>> protocol strawman will state is if any other protocols will be used 
>> for a particular version of I2RS with a particular scope for data
modules.
> Probably, my issue stems from the fact that I2RS produces an 
> architecture before fixing requirements.
>>
>> I am sorry if this is not what you excepted, but it was my direction 
>> from my AD on how to approach this work.
>>
>> At this time, we are closing in on the last of the requirements 
>> documents - the requirements for other data flows.
>> draft-hares-i2rs-dataflow-req-02 that gives the potential scope of 
>> data flows, but IMO the first version of the I2RS is likely to stay 
>> with just NETCONF/RESTCONF with ephemeral state, push pub/sub 
>> support, syslog module library, and some yang changes.
>>
>>
>>>     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.)
> No comment on "the I2RS Agent _must _use two different notifications"?
> This one is clear spec.
>>> - 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
>> Sue: Reasonable editorial comment.  This was added to address another 
>> comment, But it looks like we broken something.  Text change below.
>>
>>   Old/  Optionally, a routing element may permit a priority to be to be
>>     configured on the device for the Local Configuration mechanism
>>     interaction with the I2RS model.  The policy mechanism would compare
>>     the I2RS client's priority with that priority assigned to the Local
>>     Configuration in order to determine whether Local Configuration or
>>     I2RS wins.
>>
>>     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.  The local configuration
>>     information is stored so that if/when I2RS client removes I2RS
>>     ephemeral state the local configuration state can be restored.
>> /
>> New:
>> Optionally, a routing element may permit a priority to be to be
> to be to be
>>     configured on the device for the Local Configuration mechanism
>>     interaction with the I2RS model.  The policy mechanism would compare
>>     the I2RS client's priority with that priority assigned to the Local
>>     Configuration in order to determine whether Local Configuration or
>>     I2RS wins.
>>
>>     For the case when the configured priority of the I2RS ephemeral
>>     Is higher than the Local Configuration's policy, the
>>     The I2RS ephemeral state value it is installed
> remove "it"
>>     instead of the local configuration state.  The local configuration
>>     information is stored so that if/when I2RS client removes I2RS
>>     ephemeral state the local configuration state can be restored.
>> /
>>
>>> 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?
>> Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the 
>> excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS 
>> - we are focusing on allowing ephemeral to be added to any data 
>> model.  I2RS WG is focused first on the I2RS protocol and protocol
independent modules.
>> After this, I2RS purpose is to simply support other WGs in creating 
>> data modules with ephemeral state.
>>
>>>    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?
>> Sue: We indicate that I2RS will use these protocols.  Each protocol 
>> we mention has to be then validated with requirements (see protocol 
>> security requirement and security environment requirements).
>>
> So I2RS will publish a second architecture doc when the requirements 
> are validated and the protocols (transport, config, notifications) are 
> finally selected?
>
> Regards, Benoit
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Apr 2016 22:02:58 -0400

Joel: 

I will need to resolve this before I can provide a final for the RFC editor.
Here's the way I understand these issues: 

1) draft-ietf-i2rs-architecture-13.txt - is a high-level architecture with
building blocks. 

2) It provides only general ideas on we are using "X, Y, and Z" in ways "A,
B, and C" to 

solve the "I2RS problem". 

3) detailed requirements on what the I2RS protocol and interface should be
are contained in 

   the i2rs requirements set 

.         Pub/sub requirements - draft-ietf-i2rs-pub-sub-requirements-06
(at IESG publication) 

.         Traceability requirements - draft-ietf-i2rs-traceability-08 (at
IESG publication) 

.         Protocol Security requirements -
draft-ietf-i2rs-protocol-security-requirements-03

.         Ephemeral State requirements - draft-ietf-i2rs-ephemeral-state-05

.         Data Flow Requirements  - draft-hares-i2rs-dataflow-req-03

.         I2RS security requirements for environment -
draft-ietf-i2rs-security-environment-reqs-01

The protocol strawman is the proposal for using "X, Y, and Z" in ways "A,B,
and C" in order

to solve the I2RS problem. 

4) The architecture document and use cases were useful in creating the key
informational models: 

1)      I2RS RIB Information model 

2)      I2RS FB-RIB informational model (under WG Adoption) 

3)      I2RS generic network model (
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>
draft-ietf-i2rs-yang-network-topo-02) - which has formed the basis for most
of the I2RS, TEAS and CCAMP ideas on models. 

Therefore, I think we followed the charter. 

What we really need to revise is the abstract.  To bring the expectations
for the architecture closer to task 1. 

How about changing the abstract to:  

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 high-level architecture, the building 

blocks of this high-level architecture, and their interfaces with 

particular focus on those to be standardized

as part of the Interface to Routing System (I2RS).

Sue 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 9:07 AM
To: Benoit Claise; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];

Now I understand your confusion.

Putting aside the abstract, I thought we were focused om task 1 (from the
charter) in writing.  I think we probably crept into task 2, resulting in a
document which is confusing about its scope.

Not sure how to resolve this.

Yours,

Joel

On 3/24/16 9:03 AM, Benoit Claise wrote:

> Joel,

> Thanks, that's helpful.

> 1. Let's look at the charter

>     The I2RS working group works to develop a high-level architecture that

>     describes the basic building-blocks necessary to enable the specific

>     use

>     cases, and that will lead to an understanding of the abstract

>     informational models and requirements for encodings and protocols

>     for the I2RS interfaces.

> 2. Let's review the draft 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).

> Reading 1., I understand your point of view.

> However, I read 2. as this draft is about "we are using pieces X, Y, 

> and Z, in ways A, B, and C, to solve the I2RS problem."

> I reviewed the draft content looking for 1., and could not find it.

> Do you understand my confusion?

>> architecture that the working group never intended.

>> The charter calls for a high level architecture.

>> I believe your comment calls out an interesting gap in the charter, 

>> as there is no document called out which actually says "we are using 

>> pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."

>> We could have tried to use the architecture document for that, but 

>> the intention was to use the architecture document to guide the 

>> selection of protocol and mechanisms.

>>>>> What does it mean? I was hoping that an architecture documents 

>>>>> would at

>>>>>   On my side this architecture is flexible (NETCONF or RESTCONF), 

>>>>> on the

>>>> The architecture does out rule out other data transfer protocols, 

>>>> but says the WG will design I2RS as a higher level protocol that 

>>>> combines other protocols (NETCONF/RESTCONF + x).

>>>> The I2RS requirements documents and protocol strawman will state is 

>>>> if any other protocols will be used for a particular version of 

>>>> I2RS with a particular scope for data modules.

>>>> I am sorry if this is not what you excepted, but it was my 

>>>> direction from my AD on how to approach this work.

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

>>>>>           notification will be only transmitted to I2RS clients 

>>>>> which are

>>>>> Again, I read that sentence multiple times, and could not 

>>>>> understand it

>>>> Sue: Reasonable editorial comment.  This was added to address 

>>>> another comment, But it looks like we broken something.  Text 

>>>> change below.

>>>>     interaction with the I2RS model.  The policy mechanism would 

>>>> compare

>>>>     interaction with the I2RS model.  The policy mechanism would 

>>>> compare

>>>> Sue:  Our charter is wide, but only ephemeral layer deep.  Due to 

>>>> the excellent people in the NETCONF/NETMOD, routing area (rtgwg) 

>>>> and TEAS - we are focusing on allowing ephemeral to be added to any 

>>>> data model.

>>>> I2RS WG

>>>> is focused first on the I2RS protocol and protocol independent modules.

>>>>>    The I2RS  protocol may need to use several underlying 

>>>>> transports (TCP,

>>> are validated and the protocols (transport, config, notifications) 

>>> are finally selected?

>>>  <mailto:[email-masked]> [email-masked]

>>>  <https://www.ietf.org/mailman/listinfo/i2rs>

>> .

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Apr 2016 22:43:54 -0400

Enhancing the protocol strawman to provide that seems sensible to me.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Apr 2016 22:44:47 -0400

That improves the abstract, and works for me.
Thank you,
Joel

On 4/21/16 10:02 PM, Susan Hares wrote:
> Joel:
>
> I will need to resolve this before I can provide a final for the RFC
> editor.   Here's the way I understand these issues:
>
> 1) draft-ietf-i2rs-architecture-13.txt - is a high-level architecture
> with building blocks.
>
> 2) It provides only general ideas on we are using "X, Y, and Z" in ways
> "A, B, and C" to
>
> 3) detailed requirements on what the I2RS protocol and interface should
> be are contained in
>
> ·Pub/sub requirements - draft-ietf-i2rs-pub-sub-requirements-06  (at
> IESG publication)
>
> ·Traceability requirements - draft-ietf-i2rs-traceability-08 (at IESG
> publication)
>
> ·Protocol Security requirements -
> ·Ephemeral State requirements - draft-ietf-i2rs-ephemeral-state-05
>
> ·Data Flow Requirements  - draft-hares-i2rs-dataflow-req-03
>
> ·I2RS security requirements for environment -
> The protocol strawman is the proposal for using "X, Y, and Z" in ways
> "A,B, and C" in order
>
> 4) The architecture document and use cases were useful in creating the
> key informational models:
>
> 1)I2RS RIB Information model
>
> 2)I2RS FB-RIB informational model (under WG Adoption)
>
> 3)I2RS generic network model (draft-ietf-i2rs-yang-network-topo-02
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>) –
> which has formed the basis for most of the I2RS, TEAS and CCAMP ideas on
> models.
>
> What we really need to revise is the abstract.  To bring the
> expectations for the architecture closer to task 1.
>
> *How about changing the abstract to: *
>
> Putting aside the abstract, I thought we were focused om task 1 (from
> the charter) in writing.  I think we probably crept into task 2,
> resulting in a document which is confusing about its scope.
>
>  >>> [email-masked] <mailto:[email-masked]>
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Apr 2016 23:53:23 -0400

Benoit: 

I'm cycling back to fix the draft-ietf-i2rs-architecture-13.txt. 

I hope you can help me through your comments as it is important to me that
you are in alignment with this architecture as we go forward.  Let me
provide a high-level answer for your architecture questions. 

Question 1: Will the architecture provide you the pieces of the
NETCONF/RESTCONF that will be used, and how these will be used for I2RS
protocol version 1. 

Answer: No, this is not the goal of the I2RS architecture.  The architecture
and the requirements were to come as a set of documents along with the
protocol strawman. 

The I2RS requirements documents will specify the requirements, and the
protocol strawman will provide a suggested implementation.  After that
point, it is up to the NETCONF group to provide us with a final proposal for
the I2RS protocol based on NETCONF/RESTCONF. 

The I2RS requirements documents are: 

1)      Pub-sub requirements -
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/>
draft-ietf-i2rs-pub-sub-requirements-06   (on IESG telechat for 5-5-2016) 

2)      Traceability - draft-ietf-i2rs-traceability-08.txt (on IESG telechat
for 5-5-2016) 

3)      Ephemeral state requirements -
draft-ietf-i2rs-ephemeral-state-06.txt

4)      Protocol security requirements -
draft-ietf-i2rs-protocol-security-requirements-04.txt (past WG LC, and
awaiting shepherd double check of -04.txt) 

5)      Data flow requirements - [individual draft, will go to WG adoption
call next week] 

draft-hares-i2rs-dataflow-req-04.txt  

6)      Protocol-strawman - draft-hares-i2rs-protocol-strawman [individual
draft, heading toward WG adoption]

The security environment is in:
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/
> draft-ietf-i2rs-security-environment-reqs-01 (will recycle a WG next
week). 

The requirements describe what needs to be done.  The protocol-strawman
suggests the pieces.  Based on the IETF 95 feedback,  items 3-6 are being
revised.  

Question 2:  So I2RS will publish a second architecture doc when the
requirements are validated and the protocols (transport, config,
notifications) are finally selected?

Answer:  The requirements were check with the NETCONF working group in IETF
93-95.   We are progressing the requirements through WG LC and the IESG.
During each I2RS WG LC, we will inform the NETCONF working group.  We are
counting on interaction with the NETCONF protocol.   If the IESG wishes a
bis of the architecture document, I will be glad to spin that draft after we
get the protocol done.  

The comments below are in red if that helps you read it. 

Sue Hares 

From: Benoit Claise [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 6:54 AM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)

Sue, 

 > [I-D.ietf-netconf-restconf].

editorial "may be reused".  / I will check with RFC editor (some people say

reused /re-used). 

What does it mean? I was hoping that an architecture documents would at

 On my side this architecture is flexible (NETCONF or RESTCONF), on the

YANG1.1), and in some cases, a complete specification (for example the

notification)
 
Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols.
The architecture does out rule out other data transfer protocols, but says
the WG will design I2RS as a higher level protocol that combines other
protocols (NETCONF/RESTCONF + x).  

This is what I could not understand with the draft sentence: "Two of the
existing protocols which the which may be re-used are NETCONF [RFC6241] and
RESTCONF > [I-D.ietf-netconf-restconf]."
Sure many things could be reused. I'm expecting from an architecture
document to explain which pieces are used and how they are used.

Benoit: See the above.  This mechanism is the direction from the AD.  In the
end, you will be reviewing in the next month the requirements and the
protocol strawman for publication.   If you wish, you can request all of
these documents (architecture, requirements (5), and protocol strawman get
published as a bundle. 

The I2RS requirements documents and protocol strawman will state is if any
other protocols will be used for a particular version of I2RS with a
particular scope for data modules. 

Probably, my issue stems from the fact that I2RS produces an architecture
before fixing requirements.

Benoit:  You are correct. 
 
I am sorry if this is not what you excepted, but it was my direction from my
AD on how to approach this work. 
 
At this time, we are closing in on the last of the requirements documents -
the requirements for other data flows. 
draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
flows, but IMO the first version of the I2RS is likely to stay with just
NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module
library, and some yang changes. 

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

notifications.

         notification will be only transmitted to I2RS clients which are

No comment on "the I2RS Agent must use two different notifications"?

Sue:  oops - Missed that one 

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

New/

To handle these two types of failures, 

the I2RS agent MUST support two different notifications: 

a notification for the I2RS agent terminating gracefully, 

and a notification for the I2RS agent starting up after an unexpected
failure.

The two notifications are described below followed by the a description of
their use in unexpected failures and graceful shutdown

Graceful shutdown : In this case, the I2RS agent can do

specific limited work as part of the process of being disabled. The

I2RS agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to

all its cached I2RS clients. If the I2RS agent restarts after a 

graceful termination, it will send a NOTIFICATION_I2RS_AGENT_STARTING

to each cached I2RS client.

This one is clear spec.

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

Sue: Reasonable editorial comment.  This was added to address another
comment, 
But it looks like we broken something.  Text change below. 

to be to be
thank you. Removed 

remove "it"
Thank you. Removed 

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

Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we
are focusing on allowing ephemeral to be added to any data model.  I2RS WG
is focused first on the I2RS protocol and protocol independent modules.
After this, I2RS purpose is to simply support other WGs in creating data
modules with ephemeral state. 

  The I2RS  protocol may need to use several underlying transports (TCP,

SCTP

Sue: We indicate that I2RS will use these protocols.  Each protocol we
mention has to be then validated with requirements (see protocol security
requirement and security environment requirements). 

So I2RS will publish a second architecture doc when the requirements are
validated and the protocols (transport, config, notifications) are finally
selected?

Sue:  See top comment for this one. 

Regards, Benoit

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Apr 2016 00:10:17 -0400

Benoit and Joel: 

I have altered the abstract in version 14 as indicated in my earlier email,
and addressed all of Benoit's comments.    Please review the diff between:
draft-ietf-i2rs-architecture-13 and draft-ietf-i2rs-architecture-14.   Let
me know if you have any additional comments. 

Sue 

From: Benoit Claise [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 9:03 AM
To: Joel M. Halpern; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)

Joel,

Thanks, that's helpful.

The I2RS working group works to develop a high-level architecture that 
describes the basic building-blocks necessary to enable the specific use 
cases, and that will lead to an understanding of the abstract
informational models and requirements for encodings and protocols for the
I2RS interfaces.

   routing system.  It describes the basic architecture, the components,

Reading 1., I understand your point of view.
However, I read 2. as this draft is about "we are using pieces X, Y, and Z,
in ways A, B, and C, to solve the I2RS problem."
I reviewed the draft content looking for 1., and could not find it.

Regards, Benoit 

Yours, 
Joel 

Sue, 

reused /re-used). 

notification) 

existing protocols which the which may _be re-used_ are NETCONF 

The I2RS requirements documents and 
protocol strawman will state is if any other protocols will be used for a 
particular version of I2RS with a particular scope for data modules. 

notifications. 

- editorial: 

to be to be 

remove "it" 

follows." 

SCTP 

So I2RS will publish a second architecture doc when the requirements are 
validated and the protocols (transport, config, notifications) are 
finally selected? 

Regards, Benoit 

.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Apr 2016 00:28:20 -0400

Benoit: 

I've released a version 14 which hopefully answers all your questions.
Immediately below, is my copy of the resolutions I made.   After I made
these resolutions, I reviewed the resulting text for clarity, and made some
final tweaks.  Let me know if version 14 is closer to what you want to see. 

I'm working on making sure all requirements documents are revised so that
you can view those as well. 

Sue 

----------------------------------------------------------------------

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

[Since this document and the op-state discussion is still fluid, I am
concerned about utilizing these terms in this document going toward RFC.   I
have encountered lots of problems utilizing these at IETF 95. 

I agree in the need to align to the NETMOD op-state, but I do not think this
statement is the appropriate place. 

   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"

Yang 1.1, I've removed YANG 1.0. 

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

Changed to: 

As can be seen in Figure 1, the I2RS client can communicate with multiple
I2RS agents.  

   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.

Wow.. You are right. 

New /

There are several key benefits for I2RS in using model-driven

architecture and protocol(s).  First, it allows for data-model focused 

processing of management data that provides modular implication in 

I2RS Clients and I2RS Agents.  The I2RS client only needs to implement

the models the I2RS client is able to access. The I2RS Agent only needs

to implement the data models the I2RS Agent supports.   

/

"may be reused". What does it mean? I was hoping that an architecture
documents would at least tell me which protocols are used.

New/

As an architecture, I2RS has

been designed to reuse existing protocols that carry network

management information. Two of the existing protocols which the

which are being reused are NETCONF [RFC6241] and RESTCONF 

[draft-ietf-netconf-restconf]. 

/

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)

Comment: Hopefully, I have specified NETCONF/RESTCONF and YANG 1.1 carefully
in -14.txt

To handle I2RS Agent failure, the I2RS Agent must

       use two different notifications.

the

- editorial changed to: 

(Note: This notification will on be sent by the I2RS Agent to 

I2RS Clients which are known by the I2RS agent after a reboot. How the 

I2RS Agent retains the knowledge of these I2RS clients is out of scope

of this architecture. )

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

Comment to Benoit: 

These are features of the routing system as the charter says. 

   The I2RS

   protocol may need to use several underlying transports (TCP, SCTP

   protection mechanisms

Comment to Benoit: 

For some streams, we will need to define both mandatory and optional
transports.  For the first revision, we will only define the transports that
are acceptable to NETCONF and RESTCONF. 

Text added: 

The transports that the I2RS protocol can run over will be specified in the 

I2RS protocol, and in the I2RS protocol each transport protocol

as either mandatory to implement or optional to implement.

Fred Baker's review done in earlier protocol. 

Sue, 

reused /re-used). 

notification)

 

notifications.

 

- editorial:

 

to be to be

 

remove "it"

follows."

SCTP

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 22 Apr 2016 11:54:08 +0200

On 4/22/2016 4:02 AM, Susan Hares wrote:
> 2) It provides only general ideas on we are using "X, Y, and Z" in 
> ways "A, B, and C" to
>
> 3) detailed requirements on what the I2RS protocol and interface 
> should be are contained in
>
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>) 
> – which has formed the basis for most of the I2RS, TEAS and CCAMP 
> ideas on models.
>
That's an improvement.
At least, it removes the discrepancy between the charter description and 
the previous draft abstract.

Regards, Benoit