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:[email protected]] On Behalf Of Andy Bierman
Sent: Wednesday, May 25, 2016 10:13 PM
To: Juergen Schoenwaelder; Susan Hares; Jeffrey Haas; [email protected]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --
On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder
<[email protected]> 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]
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
