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

From: "Susan Hares" <[email-masked]>
Date: Wed, 25 May 2016 17:59:54 -0400

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

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

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

On Ephemeral-REQ-07,  NETCONF chairs asked for conceptual changes to NETCONF
and RESTCONF.  Does change to Ephemeral-REQ-07 requirement set work for you?
If it does, I will create a similar reduction for Ephemeral-REQ-08: 

---------

Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to required to
support the I2RS protocol are the following: 

 1) protocol version support for I2RS protocol modifications -  (e.g. I2RS
version 1);

2) support ephemeral model scope indication - which indicates whether a
module is ephemeral only, mixed config module (config with ephemeral), mixed
derived state (ephemeral and config), 

3) multiple message support - uses the I2RS "all or none"
(ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF
"roll-back-on-error".

4) Support for the following  NETCONF protocol specifications: 

     NETCONF [RFC6241], 

     yang pub-sub push [draft-ietf-netconf-yang-push], 

     Yang module library [draft-ietf-netconf-yang-library], 

     call-home support [draft-ietf-netconf-call-home], 

     zero-touch support [draft-ietf-netconf-zero-touch], and

     server model [draft-ietf-netconf-server-module]  with 

     server module must be augmented to support mutual authentication

     (see details in [draft-ietf-i2rs-protocol-security-requirements]
section 3.1 

      in requirements: SEC-REQ-01 to SEC-REQ-08)), 

5) Support the following encodings   XML and JSON; 

6) support the following transports : "TCP", "SSH", TLS", and non-secure.  

(See ietf-i2rs-protocol-security-requirements in section 3.2 in requirements
SEC-REQ-09 and SEC-REQ-11 for details).  NETCONF should be able to 

Expand for I2RS transport support is requirement as future I2RS protocol
versions will support other transports. 

7) The ability to restrict insecure transports to specific portions of a
data model marked as valid to transfer via an insecure protocol,  

8) ephemeral overwriting of ephemeral MUST be controlled by the following
two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1): 

   * Policy Knob 1: ephemeral configuration overwrites local configuration
(normal value: true) 

   *Policy Knob 2: update of local configuration value supersedes and
overwrites the ephemeral configuration value (normal value: false) 

9)   The ephemeral state overwriting a local configuration described in 8)
above  is considered to be the composite of all ephemeral state values by
all clients.  Some may consider this a single "pane of glass" for the
ephemeral values.

10) The ephemeral state must support notification of write conflicts using
the priority requirements (see section 3.7 below, specifically requirements
Ephemeral-REQ-09 through Ephemeral-REQ-14).  

11) Ephemeral data stores SHOULD not require support for interactions with
writeable-running, candidate data stores, confirmed commit, and a distinct
start-up capability. 

==========                                                          

On Ephemeral-09, this is covered in SEC-REQ-01.  Section 3.7.1 was added as
explanation.  It will be moved to the protocol-security-strawman. 

On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and
SEC-REQ-08.   Will this change to Ephemeral-09 work for you? 

"Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and not the
effective priority at the time the data node is stored.  Per SEC-REQ-07 in
section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an
identifier must have just one priority.  Therefore, the data nodes MAY store
I2RS client identity and not the effective priority at the time the data
node is stored.  Priority MAY be dynamically changed by AAA protocols and
how the protocol handles the revision of a client's priority SHOULD be
defined by the protocol specification as long as the collisions are handled
as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12." 

To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11,
Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which
defines that an identifier MUST have only one priority.  Ephemeral write
collisions are related to role-based data model security
(draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only
SEC-REQ-19 underscores the use of "one identifier with one priority" in the
use of a I2RS client by multiple applications.   You may be recalling input
from the I2RS-architecture document.  

On Ephemeral-REQ-13: This requirement has an explanation that I would like
to keep because the requirement has been misunderstood repeatedly in both
groups.  Since this requirement represents to summation of the NETCONF/I2RS
sessions,  I prefer to keep this requirement – and ask the WG for input. 

On the Pub-sub requirements: 

I will remove all pub-sub-requirements and add the following:

1)      Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions
against ephemeral data in operational data stores, configuration data stores
or both. 

2)      Pub-Sub-REQ-02: The Subscription Service MUST support filtering so
that subscribed updates under a target node might publish only ephemeral
data in operational data or configuration data, or publish both ephemeral
and operational data. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 17, 2016 2:24 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt

On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote:

> Jürgen,

> On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote:

> > I have a hard time with this document. Section 3 is labelled 

> > requirements but it actually details solution and I disagree with a 

> > significant number of the solution elements.

> If you were to restrict your comments to the requirements labeled
variously:

> Ephemeral-REQ-XX

> PubSub-REQ-X

> do you consider the items sufficiently well described to be a 

> requirements document?

Mostly:

- I do not understand what Ephemeral-REQ-05 is trying to say.

- I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like

  solution attempts (to which I do not agree).

- I disagree with Ephemeral-REQ-07 and all of section 3.5 and

  subsections; this is not a requirement but an attempt to describe a

  solution.

- I disagree with Ephemeral-REQ-08 and all of section 3.5 and

  subsections; this is not a requirement but an attempt to describe a

  solution.

- Has Ephemeral-REQ-09 (the first one) not been stated elsewhere

  already?

- Ephemeral-REQ-xx with xx >= 09 and xx <= 13 seem repetitions from

  requirements already stated elsewhere?

- I did not understand section 3.7.3 and I am unsure what

  Ephemeral-REQ-13 or more specifically whether it is different from

  what is already stated in the requirements. I have trouble parsing

  some of the sentences, e.g.

   [...] I2RS notes multiple operations in one or

   more messages handling can handle errors within the set of operations

   in many ways.

- I do not understand PubSub-REQ-1; what is the difference between

  synchronous and asynchronous push?

- I may disagree with PubSub-REQ-2 but then I do not know what 'real

  time for notifications' means.

- I may disagree with PubSub-REQ-3.

- I do not understand what PubSub-REQ-4 means; what is a 'critical

  node event'? How do I decide this requirement has been met?

- PubSub-REQ-5 seems to mix up different issues. I do not know what a

  hierarchy of filters of XPATHs is.

- PubSub-REQ-6 is likely underspecified.

Overall, I do not understand why we need these additional requirements given
that we have draft-ietf-i2rs-pub-sub-requirements-08.txt.

> As Sue mentioned, we can migrate solution-space discussion wholly into 

> the strawman document.

In general, it would help me if you make an effort to reduce the number of
documents and if you make an effort to avoid document overlaps. Sometimes
less is more.

/js

-- 

Juergen Schoenwaelder           Jacobs University Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

_______________________________________________

i2rs mailing list

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2016 00:33:47 +0200

> types, groupings, data node, RPCs, actions, and notifications).

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. 

Why does there have to be a YANG keyword?

> potential yang syntax).  "

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.

>  1) protocol version support for I2RS protocol modifications -  (e.g. I2RS

I do not understand what this is supposed to mean since NETCONF
extensions usually are identified by a capability URN. So why is
there a need for something else?

> derived state (ephemeral and config), 

Not sure what this means.  

> (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF

So what is the requirement here?    
 
>      server model [draft-ietf-netconf-server-module]  with 

Why do you list this under changes to NETCONF? 
  
> data model marked as valid to transfer via an insecure protocol,  
 
See above.
 
> overwrites the ephemeral configuration value (normal value: false)

And if I set both to true we run into a race?

I am stopping here. I do not even understand why we need yet another
list of requirements that just rephrase requirements already written
down in other documents. What is the goal of this exercise?

/js
 
> all clients.  Some may consider this a single "pane of glass" for the

You seem to assume a certain architectural model and it is unclear whether
there is agreement on this model. There is ongoing discussion about this,
see for example draft-schoenw-netmod-revised-datastores-00.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 25 May 2016 21:40:03 -0400

Juergen: 

Thank you for your comments and questions.   I have answered the
point-by-point comments below. 

The goal of the exercise was to make one more attempt to resolve your
comments at the request of Alia Atlas and Benoit Claise.   You are a
brilliant person who has worked in NETCONF and NETMOD for several years.  I
hope to continue to resolve your concerns, but perhaps you are missing some
context from I2RS work.  

At this point, I find the following things in your response: 

1) Request for clarity on requirements (Ephemeral-REQ-05, Ephemeral-REQ-06) 

that were reviewed in 3 IETF meetings (IETF-93, IETF-94, and IETF-95) in
which you or other NETCONF/RESTCONF/YANG individuals did not comment. Also
there were no additional questions.  I welcome further discussion with you,
but I am copying the NETCONF chairs to determine if they can help you
understand these requirements or provide me suggestion on a resolution for
your comments. 

2) A disconnect from the charter that of I2RS.  The charter specifies
protocol-independent ephemeral state only document will be done in I2RS, and
protocol-dependent ephemeral state models (or augmentations) will be done in
other WGs.  This charter defines the ephemeral-only data models, and two
types of mixed data models (draft-ietf-bgp-model example given below). 

3) A disconnect from the process of I2RS requirements as a re-use protocol 

The re-use  methodology requires I2RS protocol to:  

a) require support for I2RS protocol version number identifier that 

identifies the support of a set of YANG, NETCONF, and RESTCONF features;

b) specifying the existing Yang, NETCONF, and RESTCONF features needed for
I2RS protocol version 1 (ephemeral state, protocol security, pub/sub, and
traceability) and its security environment; and 

c) specifying the additions to YANG, NETCONF, and RESTCONF needed for I2RS 

support of ephemeral state, protocol security, pub/sub and traceability). 

To try to clarify these points, I have uploaded a -07.txt with clarifying
comments. 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 25, 2016 6:34 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --

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

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

Let me try again: 

Ephemeral-REQ-05: The ability to augment an object with  appropriate 

Yang structures that have the property of being ephemeral.  An object is
defined as being one of the following:  yang module, schema tree, schema
node, 

Submodule, components of a submodule (derived types, groupings, 

data nod, RPCs, actions, and notifications).

The following are definitions in draft-ietf-netmod-rfc6020bis-09.txt 

1) Yang module (p. 12) - A Yang module defines a hierarchy of schema nodes. 

With its definitions and the definitions it imports or includes from
elsewhere,

A module is self-contained and "compilable". 

2) schema tree (p. 13) - The definition hierarchy specified within a module.

3) schema node (p. 12) - a node in the schema tree. 

4)  submodule (p. 13) - partial module definition that contributes derived
types, groupings, data modules, RPCs, actions, and notifications to a
module. 

The term "object" is defined to allow the data to augment each of these
structures.  Is this clearer? 

> Why does there have to be a YANG keyword?

Answer: There MUST be a way to writers of a data  model to define sections
of a data model that are ephemeral configuration and derived state.   No one
has suggested any other reasonable way to accomplish this in the last 2
years. 

>> (If you desire examples, please see draft-hares-i2rs-protocol-strawman 

>> for potential yang syntax).  "

>We do have config true/false this implies writable/not-writable. 

Sue: I am glad we agree: 

>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: The ability to utilize a non-secure transport requires:

a) support for non-secure transport in protocol, 

b) data-model definition that indicates a portion of the data model may be
passed over non-secure, and 

c) deployment context (via local node's policy on supporting this portion of
a data model).  

If you do not have a and b and c - then you should not send the data over
insecure channels. 

>> On Ephemeral-REQ-07,  NETCONF chairs asked for conceptual changes to 

>> NETCONF and RESTCONF.  Does change to Ephemeral-REQ-07 requirement

>> set work for you?

>> Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to 

>> required to support the I2RS protocol are the following:

>>  1) protocol version support for I2RS protocol modifications -  (e.g. 

>> I2RS version 1);

>I do not understand what this is supposed to mean since NETCONF extensions 

> usually are identified by a capability URN. So why is there a need for
something > else?

Sue: Do these capabilities allow for grouping of the NETCONF extensions
supported by a node to a specific set of extensions related to the I2RS
protocol set?   If not, this is the request. 

>> 2) support ephemeral model scope indication - which indicates whether 

>> a module is ephemeral only, mixed config module (config with 

>> ephemeral), mixed derived state (ephemeral and config),

>Not sure what this means.  

Let me give you an example:  

a) ephemeral only data model: draft-i2rs-rib-data-model-05 

b) mixed configuration model:  draft-bgp-model-01  (sections 6.1 - 6.4)
could be augmented to add ephemeral state to the configuration, 

c) mixed derived state: draft-bgp-model-01 section 6.5 defines operational
state, and this could be augmented to add ephemeral operational within this
data model. 

I suspect this reflects back to your misunderstanding Ephemeral-REQ-05. 

>So what is the requirement here?    

Sue: The requirement is to support NETCONF "roll-back-on-error" for
ephemeral state. 

>> 4) Support for the following  NETCONF [RFC6241] protocol specifications:

>Why do you list this under changes to NETCONF? 

Sue:  The Ephemeral Requirements are defining a minimal set of 

NETCONF features to be absolutely required within the I2RS protocol
definition.   

To recreate I2RS as a re-use protocol, we are defining the features that
must be there to support the I2RS work.   

>> 7) The ability to restrict insecure transports to specific portions of 

>> a data model marked as valid to transfer via an insecure protocol,

>See above.

Sue: See above answer. 

>> 8) ephemeral overwriting of ephemeral MUST be controlled by the 

>> following two policy knobs (draft-ietf-i2rs-architecture, section 6.3,
6.3.1):

>>    * Policy Knob 1: ephemeral configuration overwrites local 

>> configuration (normal value: true)

>And if I set both to true we run into a race?

Sue: No, please see draft-ietf-i2rs-architecture, section 6.3.1 with the
full description. 

>I am stopping here. I do not even understand why we need yet another list
of >requirements that just rephrase requirements already written down in
other >documents. What is the goal of this exercise?

Sue: The goal of the exercise was to try to resolve your comments on the
ietf-i2rs-ephemeral-state-06.txt.  I promised Alia Atlas and Benoit Claise
that I would give this discussion one more try.   See above for additional
comments on the "goal of the exercise". 

/js

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

> above  is considered to be the composite of all ephemeral state values 

> by all clients.  Some may consider this a single "pane of glass" for 

> the ephemeral values.

> 10) The ephemeral state must support notification of write conflicts 

> using the priority requirements (see section 3.7 below, specifically 

> requirements

> 11) Ephemeral data stores SHOULD not require support for interactions 

> with writeable-running, candidate data stores, confirmed commit, and a 

> distinct start-up capability.

> On Ephemeral-09, this is covered in SEC-REQ-01.  Section 3.7.1 was 

> added as explanation.  It will be moved to the protocol-security-strawman.

> "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and 

> not the effective priority at the time the data node is stored.  Per 

> SEC-REQ-07 in section 3.1 of 

> [draft-ietf-i2rs-protocol-security-requirements], an identifier must 

> have just one priority.  Therefore, the data nodes MAY store I2RS 

> client identity and not the effective priority at the time the data 

> node is stored.  Priority MAY be dynamically changed by AAA protocols 

> and how the protocol handles the revision of a client's priority 

> SHOULD be defined by the protocol specification as long as the collisions
are handled as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and
Ephemeral-REQ-12."

> defines that an identifier MUST have only one priority.  Ephemeral 

> write collisions are related to role-based data model security 

> (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but 

> only

> On Ephemeral-REQ-13: This requirement has an explanation that I would 

> like to keep because the requirement has been misunderstood repeatedly 

> in both groups.  Since this requirement represents to summation of the 

> NETCONF/I2RS sessions,  I prefer to keep this requirement – and ask the WG
for input.

> against ephemeral data in operational data stores, configuration data 

> stores or both.

> that subscribed updates under a target node might publish only 

> ephemeral data in operational data or configuration data, or publish 

> both ephemeral and operational data.

> From: i2rs [ <mailto:[email-masked]> mailto:[email-masked]]
On Behalf Of Juergen 

> Schoenwaelder

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

> > > requirements but it actually details solution and I disagree with 

> > > a

>    more messages handling can handle errors within the set of 

> operations

> Overall, I do not understand why we need these additional requirements 

> given that we have draft-ietf-i2rs-pub-sub-requirements-08.txt.

> > As Sue mentioned, we can migrate solution-space discussion wholly 

> > into

> In general, it would help me if you make an effort to reduce the 

> number of documents and if you make an effort to avoid document 

> overlaps. Sometimes less is more.

> Fax:   +49 421 200 3103         < < <http://www.jacobs-university.de/>

>  <http://www.jacobs-university.de/> http://www.jacobs-university.de/>

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

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

-- 

i2rs mailing list

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 May 2016 19:12:45 -0700

On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> (derived

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

> for

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.

I agree that operators need to have the final say.
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?

Andy

> NETCONF
> required to
> I2RS
> using
> with
> like
> stores
> given

---

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

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-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, May 25, 2016 10:13 PM
To: Juergen Schoenwaelder; Susan Hares; Jeffrey Haas; [email-masked]
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-masked]> wrote:
On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote:
>> Juergen:
>> Thank you for your comments on the ephemeral state\
> 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.

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

>    list foo {  ... }

Sue: This works for me. 

>> potential yang syntax).  

> [Andy]: We do have config true/false this implies writable/not-writable. I

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. 

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

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