Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --

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

Andy: 

On Ephemeral-REQ-05/06:  You are correct, the ephemeral indication in Yang could be an extension.   Do you have a suggestion to revise the text for Ephemeral-REQ-05? 

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

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

Sue 

From: i2rs [mailto:[e-mail]] On Behalf Of Andy Bierman
Sent: Wednesday, May 25, 2016 10:13 PM
To: Juergen Schoenwaelder; Susan Hares; Jeffrey Haas; [e-mail]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --


On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder <[e-mail]> wrote:
On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote:
>> Juergen:
>> Thank you for your comments on the ephemeral state\
>> On Ephemeral-REQ-05, does this clarify the requirement:
>> Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of
>> objects) 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).

> [Juergen]: I have no clue what the above sentence is trying to say. Please try to
use YANG terminology.

>> Any ephemeral object must be able to be identified by a yang key word.

>[Andy]: Why does there have to be a YANG keyword?
>This could be an extension and not a keyword, depending on how it is done. The 
> extension vs. keyword debate will not be rehashed here, but there is an issue wrt/ >how the data definition is interpreted by tools/protocols that do not understand the >extension and just ignore it.

>Shared:
>
> list foo {
>    i2rs:ephemeral true;
 >    ....
> }

I2RS-only:

>  i2rs:ephemeral {
>    list foo {  ... }
> }

Sue: This works for me. 

>> On Ephemeral-REQ-06, does this text restrict the definition to just
>> requirements:
>> "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 draft-hares-i2rs-protocol-strawman for
>> potential yang syntax).  

> [Andy]: We do have config true/false this implies writable/not-writable. I
> find the idea strange that a data model defines secure/non-secure
> transport as a property of an data model definition since it usually
> depends on the deployment context whether it is acceptable to carry
> data over a non-secure transport.

Sue:  You are correct that config true/false implies that writable/non-writeable.  
Sue:  On Secure/non-secure: The data model defines information that must be passed over secure or non-secure transport.   The type of transport is left to the protocol. 

>This is a very expensive feature wrt/ standards resources.
> First the WG has to agree that all the subtree data is OK to send in the clear  under all circumstances. (Including augmenting nodes?)  
> Then this needs to be carefully reviewed by the SECDIR and IESG.  
> Both steps will require lots of IETF time.

Sue: Agreed.  However, the WG set this in its architecture and its initial requirements.   

> I agree that operators need to have the final say.

Sue: Ok, then we should design it and see if the operators use it. 

>This extension is the opposite of the nacm:default-deny-all extension.
>But it is designed to allow operators to configure access through NACM.
>How does an operator override the extension?
>And if the operator can override, why is an extension even needed?
>If not, then what criteria is used to decide the data is universally non-secure?

Sue:  I do not see how this extension is the opposite of "nacm:default-deny-all" extension or relates to the operators access through NACM.   The purpose is not to change who can connect, only what type of transport the messages go over. 
  
>>Andy

Thanks for commenting.

Sue  
=
[snip]