Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-07.txt

From: [email-masked]
Date: Wed, 25 May 2016 18:39:21 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System of the IETF.

        Title           : I2RS Ephemeral State Requirements
        Authors         : Jeff Haas
                          Susan Hares
	Filename        : draft-ietf-i2rs-ephemeral-state-07.txt
	Pages           : 14
	Date            : 2016-05-25

Abstract:
   This document covers requests to the NETMOD and NETCONF Working
   Groups for functionality to support the ephemeral state requirements
   to implement the I2RS architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joel Halpern <[email-masked]>
Date: Wed, 25 May 2016 22:04:25 -0400

Mostly, this looks very good.

I find it odd and overspecified that the first requirement for netConf 
and Restconf is described as indicating I2RS support via the protocol 
version.

It seems unlikely that the protocol version is the right way to 
represent this.  And it seems that the I2RS WG should specify the need, 
not the mechanism used to represent it.

Yours,
Joel

On 5/25/16 9:39 PM, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
I2RS

---

From: Joel Halpern <[email-masked]>
Date: Wed, 25 May 2016 23:17:01 -0400

While I agree with the overall requirement that I2RS support both 
secured and unsecured communication,
I find Ephemeral-REQ-06 rather odd.  Trying to have the module designer 
specify whether the usage of a node (get, set, ...?) must be via a 
secure or unsecure transport seems a very odd placement of the control.

Why are we mandating this on a per-node level?

Thank you,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 May 2016 12:55:39 -0400

Joel: 

I2RS protocol as a re-use protocol is specifying a set of changes to NETCONF
or RESTCONF.  We have two ways it can be identified: 

1) Implementations can "value" (I2RS protocol version) to query that
indicates the NETCONF implementation or the RESTCONF implementation provides
all the features requested by I2RS protocol requirements.  

2) Implementations query the NETCONF implementation or the RESTCONF
implementation supports all the features required for the I2RS protocol.  

It seemed reasonable to me to specify that NETCONF or RESTCONF set-up a
value that implementations can query to indicate it supports I2RS protocol
requirements. 

Did you have a better way to do this? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 10:04 PM
To: [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification

I find it odd and overspecified that the first requirement for netConf and
Restconf is described as indicating I2RS support via the protocol version.

It seems unlikely that the protocol version is the right way to represent
this.  And it seems that the I2RS WG should specify the need, not the
mechanism used to represent it.

Yours,
Joel

On 5/25/16 9:39 PM, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at
tools.ietf.org.
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
I2RS

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 May 2016 13:08:57 -0400

Joel: 

The purpose of allowing a non-security transport was to report status or
telemetry information.   This information may be in a specific model, or a
portion of a model.    While nodes may be too small an area, can you suggest
alternate wording here? 

Please look at Ephemeral-REQ-05 for context of the use of "object"

Sue 

-----------

   Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model
   that nodes have the following properties: ephemeral, writable/not-
   writable, status/configuration, and secure/non-secure transport.  (If
   you desire examples, please see [I-D.hares-i2rs-protocol-strawman]
   for potential yang syntax).

  Ephemeral-REQ-05: The ability to augment an object with appropriate
   YANG structures that have the property of being ephemeral.  An object
   defined as Yang module, schema tree, a schema node, submodule or
   components of a submodule (derived types, groupings, data node, RPCs,
   actions, and notifications".

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 11:17 PM
To: [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security

While I agree with the overall requirement that I2RS support both secured
and unsecured communication, I find Ephemeral-REQ-06 rather odd.  Trying to
have the module designer specify whether the usage of a node (get, set,
...?) must be via a secure or unsecure transport seems a very odd placement
of the control.

Thank you,
Joel

tools.ietf.org.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 May 2016 13:42:19 -0400

First, I would prefer that we express our requirements, and let the 
protocol developers determine what is the best way of meeting those 
requirements.  That is what I want when I receive requirements, so I try 
to meet that standard when I send them.

As for a proposed mechanism, I would again separate pieces.  The I12RS 
Client needs to know if certain capabilities are present.  These include 
support for specific models (already present in netConf), support for 
specific additional capabilities such as Ephemeral handling, and support 
for the attribution mechanisms.  There may be others.  Depending upon 
how these needs are met, there are multiple ways to indicate these 
capabilities within the NetConf and YANG framework.

Further, and part of the reason for my concerns, is that I would want to 
know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a 
future YANG 1.2 or 2.0.  Without having to change the I2RS "protocol" 
indication.

If we were really in a situation where I2RS support was a fork from the 
base protocols, then a protocol version would be appropriate.  That 
situation would be extremely unfortunate.  I believe we are avoiding that.

yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 May 2016 13:47:10 -0400

We could take the view that all nodes in a model being used by I2RS had 
to have the potential to be ephemeral.  While that would be attractive 
for consistency, it puts a massive burden on the routing system 
implemention.  So we agreed that ephemeral marking was on a per-node 
basis.  Yes, that means that the model designer has to look at the 
usage.  Unfortunate, but a tradeoff.

When it comes to securing the transfer, the situation is very different. 
  Most importantly, the cost for supporting sending whatever the client 
requests over an unsecure transport is small.  And trying to guess which 
information will be needed by monitoring or telemetry seems like to end 
up with "all".  Yes, there is a security risk with saying that telemetry 
information may be send unencrypted.  But either wwe accept that or we 
don't.  Trying to do node based marking does not seem to help the 
situation, and it creates operational restrictions and complications.

Yours,
joel

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 May 2016 14:03:48 -0400

Joel: 

<wg chair hat off> 

This requirement is not about forking I2RS protocol off the NETCONF/RESTCONF
stream.  

My requirement is to have a parameter in some NETCONF model (? Extension to
draft-ietf-netconf-yang-library) that that indicates I2RS protocol version 1
(with all its requirements) are supported (true/false). 

Otherwise, as a developer of an implementation - you must go to check all
the different types of netconf.  It would seem to me that causing the
implementation to check all of the specific NETCONF and model support would
be much more work that indicating a I2RS protocol version support.   I think
your mechanism is a lot more work for the I2RS client querying 1 variable. 

Sue 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, May 26, 2016 1:42 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification

First, I would prefer that we express our requirements, and let the protocol
developers determine what is the best way of meeting those requirements.
That is what I want when I receive requirements, so I try to meet that
standard when I send them.

As for a proposed mechanism, I would again separate pieces.  The I12RS
Client needs to know if certain capabilities are present.  These include
support for specific models (already present in netConf), support for
specific additional capabilities such as Ephemeral handling, and support for
the attribution mechanisms.  There may be others.  Depending upon how these
needs are met, there are multiple ways to indicate these capabilities within
the NetConf and YANG framework.

Further, and part of the reason for my concerns, is that I would want to
know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future
YANG 1.2 or 2.0.  Without having to change the I2RS "protocol" 
indication.

If we were really in a situation where I2RS support was a fork from the base
protocols, then a protocol version would be appropriate.  That situation
would be extremely unfortunate.  I believe we are avoiding that.

yours,
Joel

On 5/26/16 12:55 PM, Susan Hares wrote:
> Joel:
>
> I2RS protocol as a re-use protocol is specifying a set of changes to 
> NETCONF or RESTCONF.  We have two ways it can be identified:
>
> indicates the NETCONF implementation or the RESTCONF implementation 
> provides all the features requested by I2RS protocol requirements.
>
> It seemed reasonable to me to specify that NETCONF or RESTCONF set-up 
> a value that implementations can query to indicate it supports I2RS 
> protocol requirements.
>
version.
> represent this.  And it seems that the I2RS WG should specify the 
> need, not the mechanism used to represent it.
>
> Yours,
> Joel
>
>> This draft is a work item of the Interface to the Routing System of 
>> the
> IETF.
>>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 May 2016 14:16:52 -0400

Joel:
<wg chair hat off>
<author hat on> 

Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says: 

SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
   secure transport and optionally MAY be able to transfer data over a
   non-secure transport.  A secure transport MUST provide data
   confidentiality, data integrity, and replay prevention.

   The default I2RS transport is a secure transport.

   A non-secure transport can be can be used for publishing telemetry
   data or other operational state that was specifically indicated to
   non-confidential in the data model in the Yang syntax.

   The configuration of ephemeral data in the I2RS Agent by the I2RS
   client SHOULD be done over a secure transport.  It is anticipated
   that the passing of most I2RS ephemeral state operational status
   SHOULD be done over a secure transport.  As
   [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate
   whether the transport exchanging the data between I2RS client and
   I2RS agent is secure or insecure.  The default mode of transport is
   secure so data models SHOULD clearly annotate what data nodes can be
   passed over an insecure connection.
=============

Are you trying to suggest that the ability to do secure transports should be
at the data model level? If so, does this text change work for you: 

Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that
nodes have the following properties: ephemeral, writable/not-writable and
status/configuration.  Yang MUST have a way to indicate  
whether data models can be passed over secure or non-secure transport.  
(If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for
potential yang syntax).

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, May 26, 2016 1:47 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security

We could take the view that all nodes in a model being used by I2RS had to
have the potential to be ephemeral.  While that would be attractive for
consistency, it puts a massive burden on the routing system implemention.
So we agreed that ephemeral marking was on a per-node basis.  Yes, that
means that the model designer has to look at the usage.  Unfortunate, but a
tradeoff.

When it comes to securing the transfer, the situation is very different. 
  Most importantly, the cost for supporting sending whatever the client
requests over an unsecure transport is small.  And trying to guess which
information will be needed by monitoring or telemetry seems like to end up
with "all".  Yes, there is a security risk with saying that telemetry
information may be send unencrypted.  But either wwe accept that or we
don't.  Trying to do node based marking does not seem to help the situation,
and it creates operational restrictions and complications.

Yours,
joel

On 5/26/16 1:08 PM, Susan Hares wrote:
> secured and unsecured communication, I find Ephemeral-REQ-06 rather 
> odd.  Trying to have the module designer specify whether the usage of 
> a node (get, set,
> ...?) must be via a secure or unsecure transport seems a very odd 
> placement of the control.
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 26 May 2016 14:29:59 -0400

As far as I can tell, there is no such thing as i2RS protocol version 1.
Rather there are (or more accurately) will be, a package of features the 
I2RS uses.

Asking of identification as a singular thing is an efficiency gain, but 
not a requirement.

And masking the YANG version is an extremely undesirable side-effect.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 11:32:32 -0700

> your mechanism is a lot more work for the I2RS client querying 1 variable.

The protocol identification was removed from the YANG library.
It was decided that each protocol would return the view of the library
that is supported in the protocol.  Only NETCONF and RESTCONF
were considered, but if I2RS uses these protocols then it is covered.
IMO there should be an optional capability for "ephemeral" that
indicates the I2RS extensions (to NETCONF or RESTCONF) are supported.
There really isn't a separate I2RS protocol (e.g., entry points are the
same)

> Sue
Andy

> protocol
> for
> base

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 May 2016 14:35:09 -0400

Hmmm.
I tend to assume that the ability to support non-secure transport is at 
a device level.  That is, and I2RS Agent supports both, or it doesn't.

If we want enforceable controls over which data can be sent over which 
channels, we are opening a very large additional can of worms.  No, the 
Module is not the right basis, since a module typically includes 
writeable, readable, and notification related information.

The Node seems equally bad, since trying to guess at Module design team 
which nodes will be needed by which monitoring and telemetry operations, 
or will be provided by which kinds of devices, or will be used within vs 
across organizational boundaries, seems unknowable.

Given that the I2RS approach is to let the operator use the tools in the 
way he wants, I think the only practical solution is to let him use the 
channels the way he wants.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 11:52:18 -0700

On Thu, May 26, 2016 at 11:35 AM, Joel M. Halpern <[email-masked]>
wrote:

> Hmmm.
> I tend to assume that the ability to support non-secure transport is at a
> device level.  That is, and I2RS Agent supports both, or it doesn't.
>
> Module is not the right basis, since a module typically includes writeable,
> readable, and notification related information.
>
> which nodes will be needed by which monitoring and telemetry operations, or
> will be provided by which kinds of devices, or will be used within vs

I think I agree with you.
Take SNMP no-auth/no-priv as an example.
It is a deployment decision whether or not to allow that.
NETCONF and RESTCONF do not support non-secure transports
so I assume a new document standardizing new transports
would be needed.  The RFCs actually say the protocol MUST NOT
be used over a non-secure transport, so maybe a different protocol
has to be used for this purpose.

The NACM extensions make sense for subtree-level tagging.
These alter the default NACM behavior for the subtree.
The I2RS tag could be useful it there was agreement
the node was non-secure in every possible application and no
operator could ever disagree with this WG decision for any reason.
IMO that will never happen.

It is fairly easy in the server implementation to check whether the node
being sent on a non-secure stream is tagged as "nonsecure OK".
It is harder on readers and writers than tool makers.

Andy

>> situation,
>>> portion of a model.    While nodes may be too small an area, can you
>>>
>> suggest
>>
>>> alternate wording here?
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>
>>> directories.
>>>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 May 2016 15:49:22 -0400

Andy and Joel: 

<draft author hat on> 

On Ephemeral-REQ-07.1 - draft-ietf-i2rs-ephemeral-state-07 - I2RS Ephemeral State Requirements

I think the efficiency gain for a single place to check I2RS protocol support is useful.  How about if I propose in the protocol-strawman a specific set of support that can be implemented in open source?   And we can take this to the rest of the list. 

I do not intend to masking the NETCONF/RESTCONF version.  If implementations want to go through all the checking, this is fine for the implementations.  However, this is a simple place to store the checking.  As Andy notes, we will need to indicate the ephemeral support in the  draft-ietf-netconf-yang-library.   

On Ephemeral-REQ-06: ]  - did you like this revision? 

Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not-writable and status/configuration.  Yang MUST have a way to indicate whether data models can be passed over secure or non-secure transport.  

(If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for potential yang syntax).

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 26, 2016 2:33 PM
To: Susan Hares
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification

Joel:

<wg chair hat off>

 

There really isn't a separate I2RS protocol (e.g., entry points are the same)

Sue

Andy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, May 26, 2016 1:42 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification

yours,
Joel

version.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 May 2016 18:02:42 -0400

That text change seems good.
Moving specific mechanism protocol proposals to the protocol strawman 
also seems appropriate.

Yours,
Joel

On 5/26/16 3:49 PM, Susan Hares wrote:
> I think the efficiency gain for a single place to check I2RS protocol
> support is useful.  How about if I propose in the protocol-strawman a
> specific set of support that can be implemented in open source?   And we
> can take this to the rest of the list.
>
>
>
> I do not intend to masking the NETCONF/RESTCONF version.  If
> implementations want to go through all the checking, this is fine for
> the implementations.  However, this is a simple place to store the
> checking.  As Andy notes, we will need to indicate the ephemeral support
> in the  draft-ietf-netconf-yang-library.
>
>
>
> nodes have the following properties: ephemeral, writable/not-writable
> and status/configuration.  Yang MUST have a way to indicate whether data
> models can be passed over secure or non-secure transport.
>
> *From:*Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, May 26, 2016 2:33 PM
> *To:* Susan Hares
> *Cc:* Joel M. Halpern; [email-masked]
> *Subject:* Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> identification
>
>
>
>
>
>
>
> On Thu, May 26, 2016 at 11:03 AM, Susan Hares <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Joel:
>
> <wg chair hat off>
>
>     From: Joel M. Halpern [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     To: Susan Hares; [email-masked] <mailto:[email-masked]>
>     future
>     > From: i2rs [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel Halpern
>     > To: [email-masked] <mailto:[email-masked]>
>     > On 5/25/16 9:39 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     >>
>     > tools.ietf.org <http://tools.ietf.org>.
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>