Subject: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 18 Jan 2017 18:43:41 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-l3-topology-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's comment that the YANG module security consideration
section guidelines need to be followed and this shouldn't go forward
until that is corrected.  I'm told it will be, thanks.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jan 2017 09:28:14 -0500

Kathleen: 

I have written a draft suggesting a template for the I2RS YANG modules which are designed to exist in the I2RS Ephemeral Control Plane data store (configuration and operational state).    

Draft location: 
https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/

I would appreciate an email discussion with the security ADs, OPS/NM ADs, and Routing AD (Alia Atlas).  I agree that this I2RS YANG data model (L3) and the base I2RS topology model should both provide updated YANG Security Considerations sections. I would appreciate if Benoit or you hold a discuss until we sort out these issues. 

Thank you, 

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, January 18, 2017 9:44 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected.  I'm told it will be, thanks.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Jan 2017 10:12:52 -0500

Thank you, Susan.

It looks like Benoit has included this in a discuss comment.  We can
discuss and make sure we reach a good result.

Best regards,
Kathleen

On Thu, Jan 19, 2017 at 9:28 AM, Susan Hares <[email-masked]> wrote:

> Kathleen:
>
> I have written a draft suggesting a template for the I2RS YANG modules
> which are designed to exist in the I2RS Ephemeral Control Plane data store
> (configuration and operational state).
>
> Draft location:
> I would appreciate an email discussion with the security ADs, OPS/NM ADs,
> and Routing AD (Alia Atlas).  I agree that this I2RS YANG data model (L3)
> and the base I2RS topology model should both provide updated YANG Security
> Considerations sections. I would appreciate if Benoit or you hold a discuss
> until we sort out these issues.
>
> Thank you,
>
> Sue
>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> section guidelines need to be followed and this shouldn't go forward until
> that is corrected.  I'm told it will be, thanks.
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 16:34:02 +0100

For what it is worth, I find the notion that data models may be
written for a specific non-secure transport plain broken. There is
hardly any content of a data model I can think of which is generally
suitable for insecure transports.

Can we please kill this idea of _standardizing_ information that is
suitable to send over non-secure transports? I really do not see how
the IETF can make a claim that a given piece of information is never
worth protecting (= suitable for non-secure transports).

Note that I am fine if in a certain trusted tightly-coupled deployment
information is shipped in whatever way but this is then a property of
the _deployment_ and not a property of the _information_.

/js

On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

-- 
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: Thu, 19 Jan 2017 13:15:15 -0500

Juergen: 

I recognize that dislike insecure communication.  You made a similar comment
during the WG LC and IETF review of
draft-ietf-i2rs-protocol-security-requirements.  However, the
draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG
and approved by the IESG for RFC publication and it contains the non-secure
communication.  The mandate from the I2RS WG for this shepherd/co-chair is
clear.  

As the shepherd for the topology drafts, I try to write-up something that
might address Kathleen's Moriarty's concerns about the topology draft's
security issues about privacy and the I2RS ephemeral control plane data
store.   I welcome an open discussion on my ideas
(https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider).   The
yang doctor's YANG  security consideration template
(https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the
privacy related RFCs (RFC6973) note that some information is sensitive.
Hopefully, this document extends these guidelines to a new data store. 

Cheerily, 
Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

For what it is worth, I find the notion that data models may be written for
a specific non-secure transport plain broken. There is hardly any content of
a data model I can think of which is generally suitable for insecure
transports.

Can we please kill this idea of _standardizing_ information that is suitable
to send over non-secure transports? I really do not see how the IETF can
make a claim that a given piece of information is never worth protecting (=
suitable for non-secure transports).

Note that I am fine if in a certain trusted tightly-coupled deployment
information is shipped in whatever way but this is then a property of the
_deployment_ and not a property of the _information_.

/js

> Subject: Kathleen Moriarty's No Objection on 
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2017 10:30:52 -0800

Hi,

I strongly agree with Juergen on this issue.
But you can easily design a YANG extension that indicates a data node
is OK for insecure transport.

I trust that the IESG will evaluate every object of this type and
decide whether it is really OK for disclosure in every possible
usage scenario.

The flip-side of this extension is that any node not properly tagged
MUST NOT be sent without the proper security protocols.
This rule will likely be ignored, since (as Juergen pointed out)
this is a deployment decision, not a modeling decision.

Andy

On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares <[email-masked]> wrote:

> suitable

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jan 2017 13:47:12 -0500

Andy: 

You are right to comment that – the “flip side of this extensions is that any node not properly tagged must not be SENT”.   The purpose of tagging is devices which test protocol conformation can test these portions of the model.  If buyers demand that these restrictions are followed, then these restrictions will not be ignored.  Like you and Juergen, I really hope that the IESG will very carefully evaluate any I2RS YANG Model that suggest sending data over non-secure transport.  

Sue Hares 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 1:31 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; The IESG; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi,

usage scenario. 

 

Andy

Juergen:

Cheerily,
Sue Hares

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2017 10:56:22 -0800

Hi,

I realized that the NACM "default-deny-write" and "default-deny-all" tags
are
very similar.  We are deciding (in the data model) that the data node
can never be sent without an explicit NACM rule allowing it.
(I have never heard from a customer that they want this NACM rule ignored).
We do not abuse these NACM tags. They are rarely used.
I think the same will be true for the I2RS extension.

Andy

On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> You are right to comment that – the “flip side of this extensions is that
> any node not properly tagged must not be SENT”.   The purpose of tagging is
> devices which test protocol conformation can test these portions of the
> model.  If buyers demand that these restrictions are followed, then these
> restrictions will not be ignored.  Like you and Juergen, I really hope that
> the IESG will very carefully evaluate any I2RS YANG Model that suggest
> sending data over non-secure transport.
>
>
>
> Sue Hares
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 1:31 PM
> *To:* Susan Hares
> *Cc:* Juergen Schoenwaelder; [email-masked];
> [email-masked]; Kathleen Moriarty; The IESG; [email-masked]
> *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jan 2017 13:57:37 -0500

Andy: 

This is probably a good idea.  Does the NACM apply equally to NETCONF and RESTCONF? 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 1:56 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; The IESG; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi,

I realized that the NACM "default-deny-write" and "default-deny-all" tags are

 

Andy

Andy: 

Sue Hares 

Hi,

usage scenario. 

 

Andy

Juergen:

Cheerily,
Sue Hares

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2017 11:52:41 -0800

> This is probably a good idea.  Does the NACM apply equally to NETCONF and

Yes -- well, soon - there is a 6536bis draft to add RESTCONF and YANG 1.1
support to NACM.

Andy

> *Sent:* Thursday, January 19, 2017 1:56 PM
> *To:* Susan Hares

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 09:39:04 +0100

Susan,

I consider tagging a YANG object statically and universally in the
data model as "does not need secure communication" fundamentally
flawed; I am not having an issue with insecure communication in
certain deployment contexts.

The topology drafts are regular generic YANG models that just happen
to be done in I2RS - I believe that using the generic YANG security
guidelines we have is good enough to progress these drafts.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 06:04:28 -0500

Juergen: 

Let's focus on your second point.  The topology drafts are I2RS drafts
designed for the I2RS ephemeral control plane data store.   How can these be
generic YANG modules when the following is true: 

1) I2RS Data models do not utilize the configuration data store, 
2) I2RS Data Models do not require the same validation as configuration data
store, 
3) I2RS Data models require the use of priority to handle the multi-write
contention problem into the I2RS Control Plane data store, 
4) I2RS require TLS with X.509v3 over TCP for the mandatory-to-implement
transport, 

Do you disagree with draft-ietf-netmod-revised-datastores?  If so,  the
discussion should be taken up with netmod WG list.  
Do you disagree with i2rs-protocol-security-requirements?  That issue is
closed based on IESG approval. 

Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 3:39 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';

Susan,

I consider tagging a YANG object statically and universally in the data
model as "does not need secure communication" fundamentally flawed; I am not
having an issue with insecure communication in certain deployment contexts.

The topology drafts are regular generic YANG models that just happen to be
done in I2RS - I believe that using the generic YANG security guidelines we
have is good enough to progress these drafts.

/js

On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote:
> Juergen: 
> 
> I recognize that dislike insecure communication.  You made a similar 
> comment during the WG LC and IETF review of 
> draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS 
> WG and approved by the IESG for RFC publication and it contains the 
> non-secure communication.  The mandate from the I2RS WG for this 
> shepherd/co-chair is clear.
> 
> As the shepherd for the topology drafts, I try to write-up something 
> that might address Kathleen's Moriarty's concerns about the topology 
> draft's security issues about privacy and the I2RS ephemeral control plane
data
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> and Routing AD (Alia Atlas).  I agree that this I2RS YANG data model 
> (L3) and the base I2RS topology model should both provide updated YANG 
> Security Considerations sections. I would appreciate if Benoit or you 
> hold a discuss until we sort out these issues.
> > 
> > Thank you,
> > 
> > Sue
> > 
> > When responding, please keep the subject line intact and reply to 
> > all email addresses included in the To and CC lines. (Feel free to 
> > cut this introductory paragraph, however.)
> > 
> > 
> > Please refer to

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 12:29:05 +0100

I thought the topology models are coming more or less from
OpenDaylight. If so, is ODL and I2RS implementation?

/js

---

From: Giles Heron <[email-masked]>
Date: Mon, 23 Jan 2017 11:45:13 +0000

ODL does, indeed, implement the topology models, but generally the data in the topology model is operational data, so I’m not sure how that fits with “designed for the I2RS ephemeral control plane data store” - since users don’t write to the models directly (making validation, priority etc. non-issues).

> On 23 Jan 2017, at 11:29, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 12:46:52 +0100 (CET)

Hi,

> 1) I2RS Data models do not utilize the configuration data store, 

This was not clear to me.  I note that the data model's nodes are
"config true", and that "The YANG module defined in this memo is
designed to be accessed via the NETCONF protocol".

If it is true that these data models do not utilize the configuration
data stores, what does the "server-provided" leaf, and the text about
"client-configured" in section 4.4.10 of
draft-ietf-i2rs-yang-network-topo refer to?

If in fact this is correct, I think it would be helpful if a note was
added to the YANG modules, that explains that these models are not
supposed to be implemented in the same way as other "config true" data
models.  In the best of worlds it would also describe how they are
supposed to be implemented (but I assume that this is up to each
vendor for now).

I also note that it is not clear how such models would be advertised
by a NETCONF server.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 12:49:27 +0100 (CET)

Giles Heron <[email-masked]> wrote:
> ODL does, indeed, implement the topology models, but generally the
> data in the topology model is operational data

Hmm, almost the entire tree is defined as "config true".  There are
just a few "config false" leafs.

>, so I’m not sure how
> that fits with “designed for the I2RS ephemeral control plane data
> store” - since users don’t write to the models directly (making
> validation, priority etc. non-issues).

/martin

> 
> > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> >> to be

---

From: Giles Heron <[email-masked]>
Date: Mon, 23 Jan 2017 11:59:15 +0000

Hi Martin,

> On 23 Jan 2017, at 11:49, Martin Bjorklund <[email-masked]> wrote:
> 

hence my use of the word “generally”.

there are cases where you might want to create a config topology.  But in general the topology is operational data and is created by the protocol plugin, or a “topology builder” associated with the plugin (e.g. the BGP linkstate topology builder creates the linkstate topology from the linkstate RIB).

If the model was config false then surely that would unnecessarily constrain its use?

Giles

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 09:40:43 -0500

Giles:

Thank you for your comments on ODL and your implementation within ODL.   There are two different issues in discussion:  guidelines for I2RS Yang modules and the application of these guidelines to the I2RS Yang Topology model.   The guidelines for the I2RS Yang Module have three security considerations: a)  basic yang considerations,  b) I2RS ephemeral state considerations, and c) insecure considerations.   Since the topology model does not operate over an insecure transport, the only thing that I believe you are questioning is the "I2RS Yang Models for Secure-Only transports".     Let's walk through the draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and the draft-ietf-i2rs-yang-network-topo models (ietf-network, ietf-network-topology).

The topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the network, link and termination point.  Please see the copy of the YHL diagrams below. Therefore, the basic topology model is read-write.  The L3 model  (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please see a copy of the YHL diagrams below.  Therefore, although your implementation is read-only, the approved YANG modules are read-write.  This must be considered in the Security considerations section.  The basic requirements for I2RS are: 

1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, 

2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as a permissible implementation alternative. 

3) write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID) 

If the ODL model does not support writes to these data models, then it would not have to support the priority mechanism to resolve two clients writing one data node.   

A) Basic Yang considerations 

1) readable nodes with sensitive data:  Kathleen Moriarty and Stephen indicate that the topology data could be considered sensitive read data.  A paragraph needs to be added to each draft indicating risks involved in providing this information, and how deployments can keep this data safe.   Privacy issues are involved if the topologies are within homes or indicate user's personal devices.   

If the I2RS mandatory transport is utilized, the data streams utilize mutual authentication, confidentiality, data integrity, and [practical] replay protection for I2RS messages" and support "mechanism that mitigate DoS attacks" and "DDos prevention".  This level of security is useful when protecting sensitive data.  

2) writeable nodes with sensitive data:  Since the topology nodes are writeable,  a security considerations needs to consider how these sensitive data nodes will be protected.   While ODL does not support writes to any data node, the base models do. Therefore, security considerations must be written here. 

3) RPCs: No new RPCs are considered, but providing information on the notification data may be also useful. 

I2RS YANG Model Security Considerations

The requirement for this section is the following information: 

1) Indication of deployment requirement for mandatory-to-implement NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), 

2) Discussion of RPCs specific to I2RS control plane data store,   

3) NACM policy impacts the read-write state and augmentation of NACM by access control for read/writing of routing protocols (RACM),  system information (SACM), and between datastores (config to/from ephemeral state). 

4) Discussion of data retrieved from routing protocols, system information, dynamic configuration (dhcp) 

5) Any suggestion for operational knobs that control overlay of I2RS configuration over normal configuration and I2RS operational state over other operational state. 

For the topology data models (ietf-network, ietf-network-topology),  the paragraph could be: 

“The I2RS topology data models (ietf-network, ietf-network-topology) require mutual authentication, confidentiality, data integrity, and [practical] replay protection for I2RS messages. Therefore, there is a mandatory-to-implement transport protocol of TLS (see RFC7589), or an optional transport support of RESTCONF (draft-ietf-netconf-restconf).     This data model does not implement any additional RPCs specific to this data model or any notifications.   

NACM policies may restrict exterior access to this YANG model to simply read-only.  For those NACM policies allowing write-access, there is a risk that a write to a topology may create a looping topology or overload a particular node.  NACM policies may be augment by routing protocol access control methods (RACM), system data access control methods (SACM), and inter-data store access control mechanisms (DACM).  The engagement of this policy should also be control by user policy switches (on/of).  

For the topology mode, the access to information on interfaces may be control by SACM related to the interface model.  Any I2RS topology model termination point configuration which takes augments must take care not to cause fluctuation in the interface state.   Dynamic configuration protocols such as DHCP or DHCPv6 may also alter the IP Addresses associated with an interface.  DACM related to the inter-datastore policy on the precedence between configuration of interface IP addresses, DHCP/DHCPv6 configuration, or Topology configuration will need to make sure the interface IP address does not cause fluctuations in the system.  Deployments may provide general configuration knobs that set the default state for NACM, RACM, SACM and DACM for the topology database. “

For the L3 topology data models (ietf-l3-unicast-topology),  the paragraph could be: 

“The I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require mutual authentication, confidentiality, data integrity, and [practical] replay protection for I2RS messages. Therefore, there is a mandatory-to-implement transport protocol of NETCONF over TLS with X.509v3 mutual authentication (RFC7589), or an optional transport support of RESTCONF (draft-ietf-netconf-restconf).     This data model does not implement any additional RPCs specific to this data model.  This data model does support the following new notifications: l3-node-event, l3-link-event, l3-prefix-event, and termination-point-event.   These events provide the information about the changing L3 topology which may provide information regarding key nodes.  Since these events are only transported over secure transports that support mutual authentication, confidentiality, data integrity, and [practice] replay protection, the use of this information for DoS of an I2RS agent (aka NETCONF server) requires the mutual authenticated client to be suborned.  

NACM policies may restrict exterior access to this YANG model to simply read-only.  For those NACM policies allowing write-access, there is a risk that a write to a topology may create a looping topology or overload a particular node.  NACM policies may be augment by routing protocol access control methods (RACM), system data access control methods (SACM), and inter-data store access control mechanisms (DACM).  The engagement of this policy should also be control by user policy switches (on/of).  

For the L3 topology mode, the access to information on interfaces may be control by SACM related to the interface model.  Any I2RS topology model termination point configuration which takes augments must take care not to cause fluctuation in the interface state.   Dynamic configuration protocols such as DHCP or DHCPv6 may also alter the IP Addresses associated with an interface.  DACM related to the inter-datastore policy on the precedence between configuration of interface IP addresses, DHCP/DHCPv6 configuration, or Topology configuration will need to make sure the interface IP address does not cause fluctuations in the system.   The L3 Topology model may also read information from the routing protocols (ospf, isis or others), or write data to the routing protocol.  RACM policy should be carefully set so that the routing protocols do not form a place to launch a DoS attack.  Deployments may provide general configuration knobs that set the default state for NACM, RACM, SACM and DACM for the topology database. “

Hopefully, this makes the suggestion for I2RS security policy a bit more concrete.  

Sue Hares 

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

High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt 

      +--rw networks

         +--rw network* [network-id]

            +--rw network-types

            +--rw network-id            network-id

            +--ro server-provided?      boolean

            +--rw supporting-network* [network-ref]

            |  +--rw network-ref    -> /networks/network/network-id

            +--rw node* [node-id]

               +--rw node-id            node-id

               +--rw supporting-node* [network-ref node-ref]

                  +--rw network-ref    -> ../../../supporting-network/ +

                  |                    network-ref

                  +--rw node-ref       -> /networks/network/node/node-id

module: ietf-network-topology

augment /nd:networks/nd:network:

   +--rw link* [link-id]

      +--rw source

      |  +--rw source-node?   -> ../../../nd:node/node-id

      |  +--rw source-tp?     -> ../../../nd:node[nd:node-id=current()/+

      |                       ../source-node]/termination-point/tp-id

      +--rw destination

      |  +--rw dest-node?   -> ../../../nd:node/node-id

      |  +--rw dest-tp?     -> ../../../nd:node[nd:node-id=current()/+

      |                     ../dest-node]/termination-point/tp-id

      +--rw link-id            link-id

      +--rw supporting-link* [network-ref link-ref]

         +--rw network-ref    -> ../../../nd:supporting-network/+

         |                    network-ref

         +--rw link-ref       -> /nd:networks/network+

                              [nd:network-id=current()/../network-ref]/+

                              link/link-id

augment /nd:networks/nd:network/nd:node:

   +--rw termination-point* [tp-id]

      +--rw tp-id                           tp-id

      +--rw supporting-termination-point* [network-ref node-ref tp-ref]

         +--rw network-ref    -> ../../../nd:supporting-node/network-ref

         +--rw node-ref       -> ../../../nd:supporting-node/node-ref

         +--rw tp-ref         -> /nd:networks/network[nd:network-id=+

                              current()/../network-ref]/node+

                              [nd:node-id=current()/../node-ref]/+

                              termination-point/tp-id

   module: ietf-l3-unicast-topology

   augment /nd:networks/nd:network/nd:network-types:

      +--rw l3-unicast-topology!

   augment /nd:networks/nd:network:

      +--rw l3-topology-attributes

         +--rw name?   string

         +--rw flag*   l3-flag-type

   augment /nd:networks/nd:network/nd:node:

      +--rw l3-node-attributes

         +--rw name?        inet:domain-name

         +--rw flag*        node-flag-type

         +--rw router-id*   inet:ip-address

         +--rw prefix* [prefix]

            +--rw prefix    inet:ip-prefix

            +--rw metric?   uint32

            +--rw flag*     prefix-flag-type

   augment /nd:networks/nd:network/lnk:link:

      +--rw l3-link-attributes

         +--rw name?     string

         +--rw flag*     link-flag-type

         +--rw metric?   uint32

   augment /nd:networks/nd:network/nd:node/lnk:termination-point:

      +--rw l3-termination-point-attributes

         +--rw (termination-point-type)?

            +--:(ip)

            |  +--rw ip-address*      inet:ip-address

            +--:(unnumbered)

            |  +--rw unnumbered-id?   uint32

            +--:(interface-name)

               +--ro interface-name?  string

 

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 6:45 AM
To: Juergen Schoenwaelder
Cc: Susan Hares; [email-masked]; [email-masked]; Kathleen Moriarty; The IESG; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

>> 2) I2RS Data Models do not require the same validation as 

>> configuration data store,

>> 3) I2RS Data models require the use of priority to handle the 

>> multi-write contention problem into the I2RS Control Plane data 

>> 4) I2RS require TLS with X.509v3 over TCP for the 

>> mandatory-to-implement transport,

>> Do you disagree with draft-ietf-netmod-revised-datastores?  If so,  

>> the discussion should be taken up with netmod WG list.

>> Do you disagree with i2rs-protocol-security-requirements?  That issue 

>> is closed based on IESG approval.

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

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

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

>> flawed; I am not having an issue with insecure communication in certain deployment contexts.

>>> draft-ietf-i2rs-protocol-security-requirements were passed by the 

>>> I2RS WG and approved by the IESG for RFC publication and it contains 

>>> the non-secure communication.  The mandate from the I2RS WG for this 

>>> draft's security issues about privacy and the I2RS ephemeral control 

>>> plane

>>> ( <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider).

>> The

>>> ( <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and 

>>> the privacy related RFCs (RFC6973) note that some information is sensitive.

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

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

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

>>> Note that I am fine if in a certain trusted tightly-coupled 

>>> deployment information is shipped in whatever way but this is then a 

>>> property of the _deployment_ and not a property of the _information_.

>>>> I have written a draft suggesting a template for the I2RS YANG 

>>>> modules

>>>>  <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider

>>>> /

>>>> I would appreciate an email discussion with the security ADs, 

>>>> OPS/NM ADs,

>>> (L3) and the base I2RS topology model should both provide updated 

>>> YANG Security Considerations sections. I would appreciate if Benoit 

>>> or you hold a discuss until we sort out these issues.

>>>> From: Kathleen Moriarty [ <mailto:[email-masked]> mailto:[email-masked]]

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

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

>>>>  <https://www.ietf.org/iesg/statement/discuss-criteria.html> https://www.ietf.org/iesg/statement/discuss-criteria.html

>>>>  <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

>>>> -------------------------------------------------------------------

>>>> -

>>>> -------------------------------------------------------------------

>>>> -

>>>> I agree with Alissa's comment that the YANG module security 

>>>> consideration

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

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

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

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

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

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 10:11:37 -0500

Martin: 

Thank you for your insightful questions.  My answer to your questions come
from my understanding of the draft-ietf-netmod-revised-datastores-00 and
discussions with that design team at IETF 97.   We have been moving many
things in parallel at the IETF rather than do single threaded work.   The
Topoology work was completed 1 year in advance of the
draft-ietf-netmod-revised-datastores-00.txt.  

#1) model's nodes are "config true", and that "The YANG module defined in
this memo is designed to be accessed via the NETCONF protocol".  If it is
true that these data models do not utilize the configuration data stores,
what does the "server-provided" leaf, and the text about "client-configured"
in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to?

If the server-provided leaf is true, it indicates that the data is populated
by the I2RS Agent (aka netconf server) rather than the I2RS Client (aka
netconf client).    The I2RS architecture has aligned the two architecture
concepts so the  I2RS protocol is designed to be a re-use protocol for the
NETCONF protocol and the RESTCONF protocols as its message transport
protocols.  

draft-ietf-netmod-revised-datastores-00 states the following three
suggestions for supporting different datastores:  

   o  For systems supporting <intended> or <applied> configuration

      datastores, the <get-config/> operation may be used to retrieve

      data stored in these new datastores.

   o  A new operation should be added to retrieve the operational state

      data store (e.g., <get-state/>).  An alternative is to define a

      new operation to retrieve data from any datastore (e.g.,

      <get-data> with the name of the datastore as a parameter).  In

      principle <get-config/> could work but it would be a confusing

      name.

   o  The <get/> operation will be deprecated since it returns data from

      two datastores that may overlap in the revised datastore model.

Based on this input, the I2RS ephemeral control plane data store should use
a "get-data I2RS-ephemeral" to get data from the I2RS ephemeral data store
(CT, RW).   To retrieve information from the applied configuration data
store, the "get-config" may be used.  To retrieve state from the operational
state "get-state" should be used.  

2) Your suggestion to add another note about configuration true 

The config "true" is being implemented as the
draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see diagram).
It is just in a different data store.   Where and how the data store
information is stored, is unclear to me at this time.  Where do you think it
belongs?  

3) implementations 

Right now, the ODL implementation can utilize "get-config" to obtain the
I2RS topology model since the I2RS topology database has no equivalent in
the intended config.  After the draft-ietf-netmod-revised-datastore is
implemented, the "get-config" will return from the applied configuration the
Topology model with an indication that it is dynamic (see
draft-ietf-netmod-revised-datastores-00.txt section 8.   The ODL
implementation can simply augment its current get-config with an indication
that the topology model is a "dynamic" data store.    

As another example, my understanding is that a change to the ConfD
implementation would be to allow a "get-data" and "write-data" that allows
the specification of a data store such as the I2RS data store.   A
get-config of the applied data store should have a "dynamic" flag for the
topology database. 

4) Notifications - I am unclear how these are tagged to a datastore, but I
am behind on event email. 

Cheerily, 

Sue   

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 6:47 AM
To: [email-masked]
Cc: [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi,

> 1) I2RS Data models do not utilize the configuration data store,

This was not clear to me.  I note that the data model's nodes are "config
true", and that "The YANG module defined in this memo is designed to be
accessed via the NETCONF protocol".

If it is true that these data models do not utilize the configuration data
stores, what does the "server-provided" leaf, and the text about
"client-configured" in section 4.4.10 of draft-ietf-i2rs-yang-network-topo
refer to?

If in fact this is correct, I think it would be helpful if a note was added
to the YANG modules, that explains that these models are not supposed to be
implemented in the same way as other "config true" data models.  In the best
of worlds it would also describe how they are supposed to be implemented
(but I assume that this is up to each vendor for now).

I also note that it is not clear how such models would be advertised by a
NETCONF server.

/martin

 

> multi-write contention problem into the I2RS Control Plane data store,

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

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

> > ( <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>
https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider).

> > ( <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and 

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

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

> > >  <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside>
https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside

> > > r/

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

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

> > >  <https://www.ietf.org/iesg/statement/discuss-criteria.html>

> > >  <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/>

> > > ------------------------------------------------------------------

> > > ------------------------------------------------------------------

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 16:32:15 +0100 (CET)

> draft-ietf-netmod-revised-datastores-00.txt.  

Right; this is why I think an additional note in these modules are
necessary.  If you just read these topoly drafts, you will find a
normal YANG module that has a "config true" subtree.  Without
additional guidance, it is not clear that these data models "do not
utilize the configuration data store" (if this is true).

> by the I2RS Agent (aka netconf server)

Doesn't this procedure involve the normal configuration data stores?

If it does, I think we're good.  If it doesn't, I think the additional
note should be added.

> rather than the I2RS Client (aka

I always thought that the topology models could be written to through
the normal configuration data stores, in which case the server would
set the "server-provided" leaf to "false".  It seems that you have
some other mechanism in mind?

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 11:17:13 -0500

Martin: 

Answers inline. 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Monday, January 23, 2017 10:32 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

"Susan Hares" <[email-masked]> wrote:
>> Martin: 
>> 
>>  
>> 
>> Thank you for your insightful questions.  My answer to your questions 
>> come from my understanding of the draft-ietf-netmod-revised-datastores-00
and

>Right; this is why I think an additional note in these modules are
necessary.  If you just read these topoly drafts, you will find a normal
YANG module that has a "config true" subtree.  
>Without additional guidance, it is not clear that these data models "do not

Sue: Sounds like a good idea.  I'll suggest this to the authors as the
document shepherd. 

>> #1) model's nodes are "config true", and that "The YANG module defined 
>> in this memo is designed to be accessed via the NETCONF protocol".  If 
>> it is true that these data models do not utilize the configuration 
"client-configured"
>> If the server-provided leaf is true, it indicates that the data is 
>> populated by the I2RS Agent (aka netconf server)

>If it does, I think we're good.  If it doesn't, I think the additional note
should be added.

Sue:  The model is in the I2RS control plane data store. According to
draft-ietf-netmod-revised-datatstores-00.txt this is note the normal
configuration data store.  Does a note in the text plus a note at the
beginning of the data model suffice? 

>> concepts so the  I2RS protocol is designed to be a re-use protocol for 
>> the NETCONF protocol and the RESTCONF protocols as its message 
>> transport protocols.
>>
>> Based on this input, the I2RS ephemeral control plane data store 
>> should use a "get-data I2RS-ephemeral" to get data from the I2RS
ephemeral data store
>> store, the "get-config" may be used.  To retrieve state from the 
>> operational state "get-state" should be used.
>>  
>>
>> information is stored, is unclear to me at this time.  Where do you 
>> think it belongs?

> I always thought that the topology models could be written to through the
normal configuration data stores, in which case the server would set the
"server-provided" leaf to "false".  It seems that you have some other
mechanism in mind?

The design team for drat-ietf-netmod-revised-datastores-00.txt indicated
that the client written topology with "server-provided" leaf set to "false"
is written in the I2RS Control Plane data store.  An I2RS implementation
then combines the I2RS Control Plane data store with the intended
configuration data store (based on internal configuration knobs) and
installs this in a node.  A client can query the topology data nodes in the
applied configuration data store.  The response giving the topology nodes
will indicate that a dynamic control plane protocol inserted these nodes. 

I am only trying to interpret the netmod design and align the I2RS data
models (topology, RIB, FB-RIB) to this design.  

Thank you for your suggestions on the data model. 

Sue Hares  

/martin

> 3) implementations
> 
>  
> 
> Right now, the ODL implementation can utilize "get-config" to obtain 
> the I2RS topology model since the I2RS topology database has no 
> equivalent in the intended config.  After the 
> draft-ietf-netmod-revised-datastore is implemented, the "get-config" 
> will return from the applied configuration the Topology model with an
indication that it is dynamic (see
> get-config of the applied data store should have a "dynamic" flag for 
> the topology database.
> 
>  
> 
> 4) Notifications - I am unclear how these are tagged to a datastore, 
> but I am behind on event email.
> 
>  
> 
> Cheerily,
> 
>  
> 
> Sue   
> 
>  
> 
> > designed for the I2RS ephemeral control plane data store.   How can
these
> be
> supposed to be implemented (but I assume that this is up to each vendor
for now).
> > > ( 
> > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid
> > > er>

> > > which are designed to exist in the I2RS Ephemeral Control Plane 
> > > data
> store
> 
> > > > From: Kathleen Moriarty [ 
> > > > <mailto:[email-masked]>
> mailto:[email-masked]]
>

---

From: Giles Heron <[email-masked]>
Date: Mon, 23 Jan 2017 16:25:54 +0000

Hi Sue,

> On 23 Jan 2017, at 14:40, Susan Hares <[email-masked]> wrote:
> 
> Giles:
>  

i wasn’t the implementer of those models in ODL.   But I’ve used them a fair bit.

at any rate applying the I2RS security guidelines to the I2RS YANG topology model is a bit tricky IMHO as the topology model doesn’t really “fit” with the original goal of I2RS (ephemeral configuration of RIBs, ACLs etc. on network elements)

> The topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the network, link and termination point.  Please see the copy of the YHL diagrams below. Therefor…

Sure - the models are read/write but ODL’s implementation is generally read-only (as I understand it, it’s down to each individual protocol or application that leverages the models to decide whether to use them in read-write or read-only mode).

> 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, 

most NETCONF implementations I’m aware of use ssh.

And this is mandatory only per an individual ID, right?   Or is it in a WG draft now?  And do we have WG consensus that this applies to read-only data as well as to read-write?

> 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as a permissible implementation alternative. 

again isn’t that only specified as mandatory in an individual ID?

> 3) write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID) 

so that one isn’t an issue for read-only implementations…

> If the ODL model does not support writes to these data models, then it would not have to support the priority mechanism to resolve two clients writing one data node.   

indeed.

Giles

> From: Giles Heron [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Susan Hares; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Kathleen Moriarty; The IESG; [email-masked] <mailto:[email-masked]>
> > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> [mailto:[email-masked] <mailto:[email-masked]>]
> >> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> >> [email-masked] <mailto:[email-masked]>
> >>> (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>).
> >> The
> >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>) and 
> >>> [mailto:[email-masked] <mailto:[email-masked]>]
> >>> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> >>> [email-masked] <mailto:[email-masked]>
> >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>
> >>>> /
> >>>> 
> >>>> From: Kathleen Moriarty [mailto:[email-masked] <mailto:[email-masked]>]
> >>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> >>>> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/>
> >>>> 
> >>>> 
> >>>> 
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/i2rs <https://www.ietf.org/mailman/listinfo/i2rs>
> >>> 
> >>> -- 
> >>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> >>> 
> >> 
> >> -- 
> >> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> >> 
> > 
> > -- 
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/i2rs <https://www.ietf.org/mailman/listinfo/i2rs>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 23 Jan 2017 11:30:05 -0500

> On Jan 23, 2017:11:25 AM, at 11:25 AM, Giles Heron <[email-masked]> wrote:
> 
> Hi Sue,
> 
>> On 23 Jan 2017, at 14:40, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Giles:
>>  

	I totally agree. The model was and is currently used as just that and without any of the I2RS semantics.  There are examples other than ODL too.

> most NETCONF implementations I’m aware of use ssh.

	+1.  Again this is a model. Trying to hoist semantics from I2RS is ill advised as the model is used in many places that are absent of anything I2RS.

	—Tom

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 11:54:41 -0500

Giles: 

I disagree – the I2RS Topology model does fit within the original goals.  It is a protocol independent model with information on topology.   This was in the original use cases and has been a focus for I2RS WG.   See rest of the responses below. 

The real change for RFC compliance for ODL’s read-only Topology model would be:  a) use of NETCONF over TLS with X.509v3 authentication, b) denoting the “dynamic control plane data store” in the get applied (whenever that gets implemented), and support of the opaque secondary identity in tracing (if you support tracing).  The change for the RFC compliance for the ODL’s read-write would be the utilizing priority to resolve contention if multiple clients try to write the topology database.  The priority could be set per user identifier (passed in X.509v3) in a pre-configuration set-up stored.   Ideally this pre-configuration would be stored in a key store or something that is secure.

Sue 

Fr  om: Giles Heron [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 11:26 AM
To: Susan Hares
Cc: Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; The IESG; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi Sue,

Giles:

at any rate applying the I2RS security guidelines to the I2RS YANG topology model is a bit tricky IMHO as the topology model doesn’t really “fit” with the original goal of I2RS (ephemeral configuration of RIBs, ACLs etc. on network elements) .

[Sue]:  No, the topology model was part of the original I2RS YANG modules, and the Topology models (L2, L3, Base) fit its ue. 

[Sue]: This fits the I2RS Yang module. 

Giles:  most NETCONF implementations I’m aware of use ssh. And this is mandatory only per an individual ID, right?   Or is it in a WG draft now?  And do we have WG consensus that this applies to read-only data as well as to read-write?

Sue:  NETCONF over TLS with X.509v3 is an RFC 7589.  I2RS is requiring this to get mutual authentication, confidentiality, data integrity, [practical] reply protection for I2RS messages, and support DoS mitigation.  This mandatory-to-implement status is a change from the basic NETCONF over SSH. 

Giles: again isn’t that only specified as mandatory in an individual ID?

Sue: The I2RS requires mutual authentication, confidentiality, data integrity, [practical] reply protection for I2RS messages, and support DoS mitigation.   Therefore, the RESTCONF protocol is an alternative since it supports this with its basic work. 

Giles: so that one isn’t an issue for read-only implementations…

Sue: Yes.  You are correct. 

Sue: If the ODL model does not support writes to these data models, then it would not have to support the priority mechanism to resolve two clients writing one data node.   

Giles: indeed.

Sue: No other responses are below 

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

 

Sue Hares 

      +--rw networks

            +--rw network-types

            +--rw node* [node-id]

               +--rw node-id            node-id

                  |                    network-ref

   +--rw link* [link-id]

      +--rw source

      +--rw destination

      +--rw link-id            link-id

         |                    network-ref

                              link/link-id

      +--rw tp-id                           tp-id

                              termination-point/tp-id

         +--rw name?   string

         +--rw flag*   l3-flag-type

      +--rw l3-node-attributes

         +--rw prefix* [prefix]

            +--rw metric?   uint32

      +--rw l3-link-attributes

         +--rw name?     string

         +--rw metric?   uint32

            +--:(ip)

            +--:(unnumbered)

            +--:(interface-name)

 

-----Original Message-----
From: Giles Heron [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, January 23, 2017 6:45 AM
To: Juergen Schoenwaelder
Cc: Susan Hares;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Kathleen Moriarty; The IESG;  <mailto:[email-masked]> [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> On 23 Jan 2017, at 11:29, Juergen Schoenwaelder < <mailto:[email-masked]> [email-masked]> wrote:

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 23 Jan 2017 13:11:53 -0500

> On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares <[email-masked]> wrote:
> 
> Giles: 
>  

	Sue, 

	I am still totally confused as to why any of what that last sentence says has to do with the topology model other than it is as you say, protocol independent.  That was the original goal.
Why we are complicating things with transport or data store things is not making sense to me at all.

	—Tom

>  
>  
> Fr  om: Giles Heron [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Juergen Schoenwaelder; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Kathleen Moriarty; The IESG; [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 19:34:01 +0100

There are no I2RS security guidelines. We should not confuse an individual
I-D with guidelines.

I believe the regular YANG security guidelines do the work.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 19:47:21 +0100 (CET)

"Susan Hares" <[email-masked]> wrote:
> configuration data store.

Ok.  Just to make sure I understand this correctly - these topology
models are intended to be I2RS-specific, and they cannot be used for
any other purpose.  If anyone needs a general topology model outside
of the I2RS protocol, they will have to design their own model.  Is
this correct?

> Does a note in the text plus a note at the

To me, it feels weird that a model that is designed solely for the
I2RS protocol is published *before* the details of the I2RS protocol
are defined.  But it this is what the WG wants, then a note that
explains this would be useful.  I assume that the idea is that vendors
will use some proprietary mechanism for now.

> is written in the I2RS Control Plane data store.

Ok.  As you might know, I am the editor for
drat-ietf-netmod-revised-datastores-00, and thus part of the design
team, and I haven't seen any discussion about this.  Was it discussed
on the I2RS ML?

/martin

> An I2RS implementation

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 14:04:58 -0500

Juergen: 

There are two I2RS drafts related to security:  draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environment-reqs-02.  The draft-ietf-i2rs-protocol-security-requirements has pass IESG review and is waiting for the RFC editor. The draft-i2rs-security-environment-reqs-02.txt has not passed WG LC.  You are correct that draft-hares-i2rs-yang-sec-consider-00.txt is an individual draft.  This individual draft is also based on draft-ietf-netmod-ietf-revised-datastores-00.txt.  

The impetus for this individual draft (draft-hares-i2rs-yang-sec-consider) was the DISCUSS by the security ADs regarding security consideration section in two drafts: draft-ietf-i2rs-yang-network-topology and draft-ietf-i2rs-yang-l3-topology-08.txt.   The draft indicates the following 6 areas where the I2RS protocol and environment security requirements differ:  1) mandatory-to-implement transport layer, 2) priority and secondary opaque identifier, 3) different data store,  4) different validations in I2RS control plane data store, 5) different NACM policy, and 6) optional insecure protocol.   None of these are handled in the current YANG security considerations template.   Items 1, 2, and 5 are specified in  draft-ietf-protocol-security-requirements plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the draft-i2rs-security-environment-reqs-02.txt.  Item 5 arises out of SEC-ENV-REQ-05 and SEC-ENV-REQ-06 in the draft-ietf-i2rs-security-environment-reqs-02.txt.  Items 3 and 4 arise out of the draft-ietf-netmod-revised-datastores-00.txt.   I welcome a discussion on whether this individual draft truly represents the content of these 3 drafts.    

The individual draft tries to provide the information from the draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environment-reqs-02.txt in a format consistent with the current Yang Considerations model.   I welcome comments on whether this draft provides a format consistent with the current yang considerations model formats.  The purpose behind this draft is to establish a template for security considerations that the netmod/netconf experts, I2RS protocol experts, and the security ADs would accept.  The urgency for this discussion is to resolve the valid points made in the security AD's DISCUSS on these two YANG modules which are key to other YANG modules.  

Cheerily, 
Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 1:34 PM
To: Susan Hares
Cc: 'Giles Heron'; [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG'; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

There are no I2RS security guidelines. We should not confuse an individual I-D with guidelines.

/js

On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote:
> 1) Indication of deployment requirement for mandatory-to-implement 
> NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),
> 
> 4) Discussion of data retrieved from routing protocols, system 
> information, dynamic configuration (dhcp)
> 
> Cc: Susan Hares; [email-masked]; 
> >>> data store
> >>>> <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consi
> >>>> der> 
> >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid
> >>>> er
> 
> >>>> /
> 
> >>>> 
> 
> >>>> [email-masked];  
> >>>> <mailto:[email-masked]> [email-masked];
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 20:15:14 +0100

I suggest to use the YANG security guidelines.

Or, as Martin said, there needs to be a clear statement that these
YANG models only apply to I2RS agents and nothing else.

In any case, I think you can't post an individual I-D and simply
declare it guidelines others are expected to follow.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 14:12:42 -0500

Tom: 

Just to makes sure I understand your comment.  My context was “security considerations” for I2RS Topology model.   Your comment is on the sentences ““Ideally this pre-configuration would be stored in a key store or something that is secure.”   Perhaps my rephrase would be “For ideal security, the pre-configuration of the “priority match to User ID” would be contained in a data repository that is secure”.  

Is that better? 

Sue 

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 1:12 PM
To: Susan Hares
Cc: Giles Heron; [email-masked]; [email-masked]; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; The IESG
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Giles: 

Sue 

            Sue, 

            —Tom

Fr  om: Giles Heron [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, January 23, 2017 11:26 AM
To: Susan Hares
Cc: Juergen Schoenwaelder;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Kathleen Moriarty; The IESG;  <mailto:[email-masked]> [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi Sue,

On 23 Jan 2017, at 14:40, Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

Giles:

Giles: indeed.

 

Sue Hares 

      +--rw networks

            +--rw network-types

            +--rw node* [node-id]

               +--rw node-id            node-id

                  |                    network-ref

   +--rw link* [link-id]

      +--rw source

      +--rw destination

      +--rw link-id            link-id

         |                    network-ref

                              link/link-id

      +--rw tp-id                           tp-id

                              termination-point/tp-id

         +--rw name?   string

         +--rw flag*   l3-flag-type

      +--rw l3-node-attributes

         +--rw prefix* [prefix]

            +--rw metric?   uint32

      +--rw l3-link-attributes

         +--rw name?     string

         +--rw metric?   uint32

            +--:(ip)

            +--:(unnumbered)

            +--:(interface-name)

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 14:37:11 -0500

Martin: 

I'm pulling your questions to the top of this email. 

Question 1: Ok.  Just to make sure I understand this correctly - these
topology models are intended to be I2RS-specific, and they cannot be used
for any other purpose.  If anyone needs a general topology model outside of
the I2RS protocol, they will have to design their own model.  Is this
correct?

Response 1:  Not really.  

Most of the topology models I have seen abide by the concepts found in the
I2RS topology model.   See the diagram below.    The 6 differences for
security listed in my draft are:  1) different mandatory transport for
NETCONF (use RFC7895), 2) support for priority for write conflicts plus
secondary opaque identifier for tracing,   3) optional insecure protocol, 4)
different data store,  5) different validations for data store(optional),
and 6) different NACM policy (optional) plus backend policy (to/from routing
protocols, to/from system).   Using RESTCONF (which is fine as is) is an
option that I suspect most Topology models will use. 

The current topology models implemented tend to 1) use RESTCONF,  2) use
read-only and do not support tracing,  3) do not allow insecure protocols,
and 4) operate as a different data store (that is they load from internal
protocols), and 6) may use different NACM policy (for nodes) and provide
some logic for back-end policy.    What needs to be refined is the
client-write Topology models based on the I2RS Control Plane datastore (e.g.
or read-data datastore or  write data datastore) .  This concept is coming
from the netmod working group
draft-ietf-netmod-ietf-revised-datastores-00.txt.   The netmod WG has cycled
on many different ways to handle I2RS ephemeral data store, and settled on
this proposal.   

Questions 2: To me, it feels weird that a model that is designed solely for
the I2RS protocol is published *before* the details of the I2RS protocol are
defined.  But it this is what the WG wants, then a note that explains this
would be useful.  I assume that the idea is that vendors will use some
proprietary mechanism for now.

Response:  Due to the wide spread use of the topology models, the I2RS WG
passed WG LC on these YANG models and Benoit Claise review felt it was ok.
The benefit in this approach is that the main structures are stable.  The
deficit is that adding the I2RS protocol definitions could cause changes.
The I2RS protocol depends on the revised data store model
(draft-ietf-netmod-revised-datastores, the revised NACM
(draft-ietf-netconf-rfc6536bis-00.txt, the advances in the notification and
pub/sub solutions, and proposals for I2RS protocol implementation in NETCONF
and RESTCONF.    I have individual proposal for the I2RS protocol (get-data
datastore and write-data datastore) that I would like some private review of
these proposals prior to sending them to NETCONF.   

Cheerily, 

Sue Hares 

part4

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 1:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];

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

> Bjorklund

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

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

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

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

> >> Thank you for your insightful questions.  My answer to your 

> >> questions come from my understanding of the 

> >> draft-ietf-netmod-revised-datastores-00

> normal YANG module that has a "config true" subtree.

> >Without additional guidance, it is not clear that these data models 

> >"do not

> >> #1) model's nodes are "config true", and that "The YANG module 

> >> defined in this memo is designed to be accessed via the NETCONF 

> >> protocol".  If it is true that these data models do not utilize the 

> >> configuration data stores, what does the "server-provided" leaf, 

> >> and the text about

> >If it does, I think we're good.  If it doesn't, I think the 

> >additional note

> configuration data store.

Ok.  Just to make sure I understand this correctly - these topology models
are intended to be I2RS-specific, and they cannot be used for any other
purpose.  If anyone needs a general topology model outside of the I2RS
protocol, they will have to design their own model.  Is this correct?

> Does a note in the text plus a note at the beginning of the data model 

> suffice?

To me, it feels weird that a model that is designed solely for the I2RS
protocol is published *before* the details of the I2RS protocol are defined.
But it this is what the WG wants, then a note that explains this would be
useful.  I assume that the idea is that vendors will use some proprietary
mechanism for now.

> >> netconf client).    The I2RS architecture has aligned the two

> architecture

> >> concepts so the  I2RS protocol is designed to be a re-use protocol 

> >> for the NETCONF protocol and the RESTCONF protocols as its message 

> >>      datastores, the <get-config/> operation may be used to 

> >> retrieve

> >>   o  A new operation should be added to retrieve the operational 

> >> state

> >>       data store (e.g., <get-state/>).  An alternative is to define 

> >> a

> >>       <get-data> with the name of the datastore as a parameter).  

> >> In

> >>       principle <get-config/> could work but it would be a 

> >> confusing

> >>    o  The <get/> operation will be deprecated since it returns data 

> >> from

> >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see

> diagram).

> > I always thought that the topology models could be written to 

> > through the

> normal configuration data stores, in which case the server would set 

> the "server-provided" leaf to "false".  It seems that you have some 

> other mechanism in mind?

> The design team for drat-ietf-netmod-revised-datastores-00.txt 

> indicated that the client written topology with "server-provided" leaf set
to "false"

Ok.  As you might know, I am the editor for
drat-ietf-netmod-revised-datastores-00, and thus part of the design team,
and I haven't seen any discussion about this.  Was it discussed on the I2RS
ML?

/martin

> installs this in a node.  A client can query the topology data nodes 

> in the applied configuration data store.  The response giving the 

> topology nodes will indicate that a dynamic control plane protocol
inserted these nodes.

> I am only trying to interpret the netmod design and align the I2RS 

> data models (topology, RIB, FB-RIB) to this design.

> > will return from the applied configuration the Topology model with 

> > an

> > implementation can simply augment its current get-config with an

> indication

> > get-config of the applied data store should have a "dynamic" flag 

> > for the topology database.

> > From: Martin Bjorklund [ <mailto:[email-masked]> mailto:[email-masked]]

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

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

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

> > "Susan Hares" < < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> [email-masked]> wrote:

> > > Let's focus on your second point.  The topology drafts are I2RS 

> > > drafts

> > If it is true that these data models do not utilize the 

> > configuration data stores, what does the "server-provided" leaf, and 

> > the text about "client-configured" in section 4.4.10 of 

> > If in fact this is correct, I think it would be helpful if a note 

> > was added to the YANG modules, that explains that these models are 

> > not supposed to be implemented in the same way as other "config 

> > true" data models.  In the best of worlds it would also describe how 

> > they are supposed to be implemented (but I assume that this is up to 

> > each vendor

> > > Do you disagree with i2rs-protocol-security-requirements?  That 

> > > issue

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

> >  <mailto:[email-masked]>

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

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

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

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

> > > certain

> > deployment contexts.

> > > The topology drafts are regular generic YANG models that just 

> > > happen

> > > to be done in I2RS - I believe that using the generic YANG 

> > > security

> > > > I recognize that dislike insecure communication.  You made a 

> > > > similar

> > > > draft-ietf-i2rs-protocol-security-requirements were passed by 

> > > > the

> > > > I2RS WG and approved by the IESG for RFC publication and it 

> > > > contains

> > > > the non-secure communication.  The mandate from the I2RS WG for 

> > > > this

> > > > As the shepherd for the topology drafts, I try to write-up 

> > > > something

> > > > that might address Kathleen's Moriarty's concerns about the 

> > > > topology

> > > > draft's security issues about privacy and the I2RS ephemeral 

> > > > control

> > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons

> > > > id

> >  <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>

> > > > ( < <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>

> >  <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>

> > > > the privacy related RFCs (RFC6973) note that some information is

> > sensitive.

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

> >  <mailto:[email-masked]>

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

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

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

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

> > > > written for a specific non-secure transport plain broken. There 

> > > > is

> > > > hardly any content of a data model I can think of which is 

> > > > generally

> > > > Can we please kill this idea of _standardizing_ information that 

> > > > is

> > > > suitable to send over non-secure transports? I really do not see 

> > > > how

> > > > the IETF can make a claim that a given piece of information is 

> > > > never

> > > > deployment information is shipped in whatever way but this is 

> > > > then a

> > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-co

> > > > > ns

> > > > > ide>

> > > > and Routing AD (Alia Atlas).  I agree that this I2RS YANG data 

> > > > model

> > > > (L3) and the base I2RS topology model should both provide 

> > > > updated

> > > > YANG Security Considerations sections. I would appreciate if 

> > > > Benoit

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

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

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

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

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

> > > > > Kathleen Moriarty has entered the following ballot position 

> > > > > for

> > > > > When responding, please keep the subject line intact and reply 

> > > > > to

> > > > > all email addresses included in the To and CC lines. (Feel 

> > > > > free to

> > > > >  < <https://www.ietf.org/iesg/statement/discuss-criteria.html>
https://www.ietf.org/iesg/statement/discuss-criteria.html>

> > > > > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topo

> > > > > lo

> > > > > gy/>

> > > > > --------------------------------------------------------------

> > > > > --------------------------------------------------------------

> > > > section guidelines need to be followed and this shouldn't go 

> > > > forward

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

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

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

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

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

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

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 14:45:57 -0500

Juergen: 

First of all, I posted an individual I-D to start a discussion.  I indicated to Benoit Claise that this was my personal recommendation as shepherd after looking at the problem.  I have not mandated anything.  

Second, I hear that you want to use the YANG security guidelines, but there are 6 differences between the Yang security considerations and the references in the I2RS security documents and the draft-ietf-nemod-ietf-revised-datastore-00.txt.  If you want to debate these 6 differences or the suggestions for the yang security considerations, I am still willing to continue this discussion. 

My understanding from this email messages  is that you do not want to discuss these differences and how to craft a security considerations section that addresses these differences.  

Cheerily,  Sue Hares  

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 2:15 PM
To: Susan Hares
Cc: 'Giles Heron'; [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG'; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Or, as Martin said, there needs to be a clear statement that these YANG models only apply to I2RS agents and nothing else.

In any case, I think you can't post an individual I-D and simply declare it guidelines others are expected to follow.

/js

On Mon, Jan 23, 2017 at 02:04:58PM -0500, Susan Hares wrote:
> Cc: 'Giles Heron'; [email-masked]; 
> [email-masked]; 'Kathleen Moriarty'; 'The IESG'; [email-masked]
> > >>>> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topol
> > >>>> og
> > >>>> y/>
> > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo
> > >>>> gy
> > >>>> /
> > 
> > >>>> 
> > 
> > >>>> 
> > 
> > >>>> 
> > 
> > >>>> ---------------------------------------------------------------
> > >>>> --
> > >>>> --
> > 
> > >>>> -
> > 
> > >>>> --
> > 
> > >>>> COMMENT:
> > 
> > >>>> ---------------------------------------------------------------
> > >>>> --
> > >>>> --
> > 
> > >>>> -
> > 
> > >>>> --
> > 
> > >>>> 
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 20:56:52 +0100

In case the modules are indeed only for I2RS agents and this is
clearly stated in the document and the module, then feel free to do
whatever you think needs to be done. Well, actually, it would be nice
to do whatever the I2RS WG wants to be done (which is remarkably
silent anyway).

I was under the impression that these YANG models are applicable in
other contexts as well (e.g. OpenDaylight). If this perception is
wrong, then I apologize. And then Benoit probably needs to think about
where we get generic topology models defined - but this is then a
different problem (and not specifically yours).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 21:26:21 +0100 (CET)

> the I2RS protocol, they will have to design their own model.  Is this

Ok, so are you saying that the models are in fact generic, and can be
used outside of I2RS?  I.e., they *can* be used with the normal
configuration datastores?

> on many different ways to handle I2RS ephemeral data store, and settled on

Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly
work-in-progress, and (2) none of the topology drafts reference
draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a
solution in that draft, it is not very clear to the reader.

> passed WG LC on these YANG models and Benoit Claise review felt it was ok.

Since the documents don't mention it, I think that some people might
have missed the fact that these models are intended to be used solely
for the I2RS protocol - if that is correct; I must admit that I am a
bit confused at this point.

/martin

---

From: Robert Varga <[email-masked]>
Date: Mon, 23 Jan 2017 22:10:41 +0100

> configuration datastores?

From implementation experience, yes, they can be used for storing
configuration. OpenDaylight uses (an ancient predecessor of)
yang-network-topo to store configure details about devices in its
managed networks.

Regards,
Robert

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 22:19:51 +0100 (CET)

> yang-network-topo to store configure details about devices in its

Robert, this sub-thread started with Susan's statement:

i.e., despite the fact that the data model is config true, it cannot
be edited via running etc in NETCONF (or normal edit in RESTCONF).

My comment on this was that *if* this is true, it should be noted in
the document.  At this point, I am not sure if it is true or not.

/martin

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jan 2017 16:36:08 -0500

The discussion on my no objection is very lengthy as there does not seem to
be agreement on a few things from the WG.  Does this document need to go
back to the working group?

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Jan 2017 13:40:25 -0800

> the document.  At this point, I am not sure if it is true or not.
Agreed.

But a larger issue is the balkanization of YANG.
To every YANG reader, the YANG data-def-stmts look exactly
like those that would be interpreted as configuration and state data nodes.

I little note that says "This is not regular YANG that is intended for
NETCONF or RESTCONF servers" is not really a solution.
RFC 7950 says YANG is for NETCONF, which is extra confusing.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Jan 2017 17:06:04 -0500

Robert and Martin: 

I agree with Robert that the current implementations of the ODL topology
models are handled as part of the configuration data store with ephemeral
state.   I will point out that these implementation are pre-standards
implementations of the I2RS YANG Data model.  

While standardizing the topology data models, the I2RS WG have been asked to
align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG
document.  This NETMOD WG document moves the I2RS ephemeral data store from
configuration data store to a Control Plane data store.   If we follow this
draft, the I2RS Topology models are part of the I2RS ephemeral data store.
If you disagree with the placement of the Topology data models, please
indicate this to the NETMOD WG and to Benoit.  Could you propose a way that
you would see the ephemeral state working with the configuration data store
to the NETMOD WG?   

Quite frankly, I feel a bit of whip-lash on this topic.   NETMOD WG asks for
Control Plane Data store.  You ask for configuration data store (which was
the I2RS initial proposal).   It is possible for either one to work for I2RS
Topology models - if the right details are taken care of.   How do we make
progress on choosing one method so we can write the I2RS Topology Models
security considerations.? 

Sue 
  
-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: Monday, January 23, 2017 4:11 PM
To: Martin Bjorklund; [email-masked]
Cc: [email-masked]; [email-masked];

On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
>> Question 1: Ok.  Just to make sure I understand this correctly - 
>> these topology models are intended to be I2RS-specific, and they 
>> cannot be used for any other purpose.  If anyone needs a general 
>> topology model outside of the I2RS protocol, they will have to design 
>> their own model.  Is this correct?
>>
>>  
>>
>> Response 1:  Not really.  

configuration. OpenDaylight uses (an ancient predecessor of)
yang-network-topo to store configure details about devices in its managed
networks.

Regards,
Robert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 23:14:58 +0100

Perhaps just adding to the confusion, here is what the WG charter
says:

    o The ability to extract information about topology from the network.
      Injection and creation of topology will not be considered as a work
      item. Such topology-related models will be based on a generic
      topology model to support multiple uses; the generic topology model
      should support topology extension for non-I2RS uses.

And as a milestone:

  Dec 2016 - Request Publication of Protocol Independent Topology Data Models

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 23:25:55 +0100 (CET)

"Susan Hares" <[email-masked]> wrote:
> the I2RS initial proposal).

Not really; I ask for clarification.

> It is possible for either one to work for I2RS

One problem is that relying on the solution in
draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact,
that document does not yet provide any details at all on the I2RS
ephemeral datastore.

So I see two alternatives.  Either wait with these documents, or
publish them with their datamodels as is (i.e., no new additional
notes), for the existing protocols and architecure.  This would allow
them to be implemented just like any other YANG data model.  This
would mean that the normal YANG security considerations guidelines
should be followed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Jan 2017 14:54:21 -0800

> you would see the ephemeral state working with the configuration data store

This was discussed many times, going back to the NYC interim for NETMOD WG.

There are 2 choices that are backward compatible

1) I2RS nodes are config=true
    This is OK if the data nodes represent configuration that can be
overridden
     by the values in the ephemeral datastore.  NETCONF can write the
    configuration datastore. I2RS can write the ephemeral datastore

2) I2RS nodes are config=false
   This is OK if the data nodes represent I2RS-only data that cannot be
written
   to a configuration datastore. I2RS can write to this data in the
ephemeral datastore only

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 06:42:30 -0500

Juergen: 

Yep.  That's the charter.  draft-ietf-i2rs-yang-network-topo-10.txt is a
generic topology model.  draft-ietf-i2rs-yang-l3-topology-08.txt is a
generic topology for L3 unicast.   These support topology extension for
non-I2RS user.  We met the milestone and deliver the YANG Modules to the
IESG.    We discussed the "write" feature during WG LC and in the WG.   We
passed this by AD Benoit Claise who agreed to the reasons present by the
draft authors.  

Kinda' missed your comments in the normal comment period (WG LC, IETF LC). 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, January 23, 2017 5:15 PM
To: Susan Hares
Cc: [email-masked]; 'Martin Bjorklund';
[email-masked]; [email-masked]; 'Robert
Varga'; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

And as a milestone:

  Dec 2016 - Request Publication of Protocol Independent Topology Data
Models

/js

On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote:
> Robert and Martin: 
> 
> I agree with Robert that the current implementations of the ODL 
> topology models are handled as part of the configuration data store with
ephemeral
> While standardizing the topology data models, the I2RS WG have been 
> asked to align with the draft-ietf-netmod-revised-datastores-00.txt 
> NETMOD WG document.  This NETMOD WG document moves the I2RS ephemeral data
store from
> indicate this to the NETMOD WG and to Benoit.  Could you propose a way 
> that you would see the ephemeral state working with the configuration data
store
> progress on choosing one method so we can write the I2RS Topology 
> Models security considerations.?
> 
> Sue
>   
> >> topology model outside of the I2RS protocol, they will have to 
> >> design their own model.  Is this correct?
> >>
> >>  
> >>
> >> Response 1:  Not really.  
> > Ok, so are you saying that the models are in fact generic, and can 
> > be used outside of I2RS?  I.e., they *can* be used with the normal

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2017 12:52:21 +0100

Susan,

so are these YANG models regular YANG models or are these YANG models
specific to the yet to be defined I2RS protocol and yet to be defined
datastores?

I think this is the core of Martin's and my question. A simple clear
and concise answer would be nice.

/js

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 24 Jan 2017 13:30:05 +0000

> and concise answer would be nice.

+1.

A.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 09:25:52 -0500

Juergen and Martin: 

Your question is appropriate at this point.   These Yang Modules are I2RS
Yang Modules.   Knowing whether these are attached to the configuration data
store or a control plane data store is important.   For that answer, I must
await Benoit and the NETMOD Chairs.  

However, the security involved in these data models still has the same
security issues whether it is ephemeral state attached to the configuration
data store or the control plane data store.  The solution is just different.
The 6 issues for I2RS security considerations are:  1) different
mandatory-to-implement transport for NETCONF, 2) priority resolving multiple
client writes,  3) non-secure transport, 4 ) different validations with rpc
actions, 5) different NACM, RACM, and SACM policy, 6) different data store
behavior (ephemeral/configuration or ephemeral/Control Plane data store).
Only #6 would operate different between the two data store choices.   

To recap our discussion:  Any I2RS YANG module MUST have security comments
on #1 and #2 if it contains writes.   The topology modules particular module
does not use #3  and #4 beyond the regular YANG module section.  #5 - The
NACM policy may be the same, but the policy toward the routing system (RACM)
or system information (SACM) is different as the L3 topology models may load
information from routing protocols.   The proposal for I2RS Yang module
security considerations has 3 parts:  A) Basic Yang  Security
considerations,  B) I2RS Security considerations for secure transport, and
C) non-secure security considerations .  A+B are all that is needed for
these drafts.  

Cheerily, 

Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 6:52 AM
To: Susan Hares
Cc: [email-masked]; 'Martin Bjorklund';

Susan,

I think this is the core of Martin's and my question. A simple clear and
concise answer would be nice.

/js

On Tue, Jan 24, 2017 at 06:42:30AM -0500, Susan Hares wrote:
> Juergen: 
> 
> Yep.  That's the charter.  draft-ietf-i2rs-yang-network-topo-10.txt is 
> a generic topology model.  draft-ietf-i2rs-yang-l3-topology-08.txt is a
> passed this by AD Benoit Claise who agreed to the reasons present by 
> the draft authors.
> 

> [email-masked]; [email-masked]; 
> 'Robert Varga'; [email-masked]; [email-masked]
> > If you disagree with the placement of the Topology data models, 
> > please indicate this to the NETMOD WG and to Benoit.  Could you 
> > propose a way that you would see the ephemeral state working with 
> > the configuration data
> store
> > to the NETMOD WG?   
> >

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 14:48:25 +0000

Has it been considered that draft-ietf-teas-yang-te-topo augments draft-ietf-i2rs-yang-network-topo?

Michael

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 10:29:00 -0500

Michael: 

Yes.   Do you want a longer explanation of the details? 

Sue 

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 9:48 AM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Martin Bjorklund';
[email-masked]; [email-masked]; 'Robert
Varga'; [email-masked]; [email-masked]
Subject: RE: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Has it been considered that draft-ietf-teas-yang-te-topo augments
draft-ietf-i2rs-yang-network-topo?

Michael

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 10:48:54 -0500

Tom: 

Original goal = protocol independent yang in ephemeral storage with appropriate security.   YANG drafts on plan and on-time.  For I2RS appropriate security see draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environment-req-02.txt as WG drafts.  All 6 requirements from 2 WG documents.  Only unique question to data store – Ephemeral + config or Ephemeral in Control Plane data store.   NETMOD’s choice on datastore.  Awaiting their comments.  Discussion is long, but fix is short.   Fix to drafts for Security:  1-2 Paragraphs for Yang Basics security considerations, fix is  1 paragraph for YANG I2RS Models.   

Sue 

 

Giles: 

Sue 

            Sue, 

            —Tom

Hi Sue,

Giles:

Giles: indeed.

 

Sue Hares 

      +--rw networks

            +--rw network-types

            +--rw node* [node-id]

               +--rw node-id            node-id

                  |                    network-ref

   +--rw link* [link-id]

      +--rw source

      +--rw destination

      +--rw link-id            link-id

         |                    network-ref

                              link/link-id

      +--rw tp-id                           tp-id

                              termination-point/tp-id

         +--rw name?   string

         +--rw flag*   l3-flag-type

      +--rw l3-node-attributes

         +--rw prefix* [prefix]

            +--rw metric?   uint32

      +--rw l3-link-attributes

         +--rw name?     string

         +--rw metric?   uint32

            +--:(ip)

            +--:(unnumbered)

            +--:(interface-name)

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 24 Jan 2017 17:00:38 +0000

On 24/01/17 14:25, Susan Hares wrote:
> data store or the control plane data store.

No it is not.

If it is the control plane you need a security model for the northbound 
write access.

If that model is not necessary because there is no write access, then 
the question is why do you need it to be in the config in the first place.

A.

>   The solution is just different.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 06:44:49 -0500

Martin: 

Your statement "One problem is that relying on the solution in
draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that
document does not yet provide any details at all on the I2RS ephemeral data
store." This statement is not what I understood from IETF 98 or the netmod
ADs.   I guess your objection to this data model falls into Benoit Claise
(AD) and the NETMOD folks to answer. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Monday, January 23, 2017 5:26 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

ephemeral
store from
store
> Control Plane Data store.  You ask for configuration data store (which 
> was the I2RS initial proposal).

One problem is that relying on the solution in
draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that
document does not yet provide any details at all on the I2RS ephemeral
datastore.

So I see two alternatives.  Either wait with these documents, or publish
them with their datamodels as is (i.e., no new additional notes), for the
existing protocols and architecure.  This would allow them to be implemented
just like any other YANG data model.  This would mean that the normal YANG
security considerations guidelines should be followed.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Jan 2017 13:35:29 +0100 (CET)

> (AD) and the NETMOD folks to answer. 

Why do you think that I have any objection to
draft-ietf-netmod-revised-datastores-00.  Please re-read what I
wrote.

My objection regards your statement:

If this is true it needs to be clarified in the document.

After all these emails back and forth, it is still not clear whether
this statement is true or not.

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 09:41:15 -0500

Martin: 

I'm sorry if misunderstood your comments regarding the
draft-ietf-netmod-revised-datastores-00.txt.  The reason the answer is
unclear is that it depends on the context of the question. 

.         If you ask if the pre-standardization I2RS Yang Topology models
(basic and L3)  implemented are part of the configuration data store, the
answer is yes - AFAIK. 

.         If you ask if the WG LC Topology models are approved to be part of
the configuration data store, my understanding was no.   I2RS WG was to
abide by the decision of NETMOD WG on which data store I2RS modules were
placed in. 

If you are concerned the implementation varies from the standardized, please
express this to Benoit Claise.   Based on your comments on my email thread,
I will be brief in my answers today.  

Sue 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 7:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> ephemeral data store." This statement is not what I understood from IETF
98 or the netmod

Why do you think that I have any objection to
draft-ietf-netmod-revised-datastores-00.  Please re-read what I wrote.

After all these emails back and forth, it is still not clear whether this
statement is true or not.

/martin

 

On Behalf Of Martin 

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

> > topology models are handled as part of the configuration data store 

> > with

> > NETMOD WG document.  This NETMOD WG document moves the I2RS 

> > ephemeral data

> > configuration data store to a Control Plane data store.   If we follow

> > Quite frankly, I feel a bit of whip-lash on this topic.   NETMOD WG asks

> > Control Plane Data store.  You ask for configuration data store 

> > (which was the I2RS initial proposal).

> would mean that the normal YANG security considerations guidelines should
be followed.

> > From: Robert Varga [ <mailto:[email-masked]> mailto:[email-masked]]

> > To: Martin Bjorklund;  <mailto:[email-masked]> [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Jan 2017 16:39:10 +0100 (CET)

> (basic and L3)  implemented are part of the configuration data store, the

This is not my question.

> abide by the decision of NETMOD WG on which data store I2RS modules were

Yes, this is my question.  And my concern is that even if your
understanding is that they are not designed to be part of the
configuration datastores, this fact is not mentioned in the drafts.

> I will be brief in my answers today.  

This is not my concern.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2017 17:26:21 +0100

> abide by the decision of NETMOD WG on which data store I2RS modules were

So you are saying we have to redo topology models elsewhere in order
to have some that can be implemented and used outside an I2RS system?

If so, this is probably important for Benoit to understand.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 11:50:31 -0500

To: Martin: 

You have a reasonable request. If the NETMOD WG Chairs confirm their
decision to make I2RS Yang Modules part of the Control Plane Datastore then
as shepherd/WG-chair I will recommend these get added to the draft. 

Note to authors : 

As we wait for the NETMOD WG Chairs and Benoit to deliver the decision on
Config/Control Plane datastore, the authors should work on:  Basic Yang
security considerations and the other I2RS Yang Module information. 

Sue Hares (Shepherd) 
-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 10:39 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];

"Susan Hares" <[email-masked]> wrote:
> (basic and L3)  implemented are part of the configuration data store, 
> the answer is yes - AFAIK.

This is not my question.

> abide by the decision of NETMOD WG on which data store I2RS modules 
> were placed in.

Yes, this is my question.  And my concern is that even if your understanding
is that they are not designed to be part of the configuration datastores,
this fact is not mentioned in the drafts.

This is not my concern.

/martin

> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > > asked to align with the 
> > > draft-ietf-netmod-revised-datastores-00.txt
> 
> > > draft, the I2RS Topology models are part of the I2RS ephemeral 
> > > data
> store.
> 
> > should

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 12:26:50 -0500

Juergen: 

Per my earlier answer to Martin, No.   Most topology live in the same
ephemeral space as the I2RS Topology drafts.   Whether it is ephemeral state
in configuration data store or ephemeral state for the Control Plane data
store - the topology models seem (AFAIK) to be the same type of information.

Cheerily, Sue   

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 11:26 AM
To: Susan Hares
Cc: 'Martin Bjorklund'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> abide by the decision of NETMOD WG on which data store I2RS modules 

So you are saying we have to redo topology models elsewhere in order to have
some that can be implemented and used outside an I2RS system?

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 12:50:17 -0500

Anton:  
 
See earlier message to Martin.  Topology models are I2RS YANG Models
designed for ephemeral state with specific security concerns.  This is not
your basic YANG model no matter which data store ephemeral gets linked to.
Where is ephemeral state?  By IESG Design of charter, I2RS is not in charge
of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them. 

Do not blame the messenger echoing NETMOD results, 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To: [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on

+1.

A.

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 24 Jan 2017 18:14:49 +0000

I am not blaming the messenger.

I am just noting that from my implementer's viewpoint your security 
concerns seem different if you are presented as config=true or config=false.

These have a different security model by definition and by 
implementation in most cases.

This is in addition to the specific I2RS security concerns.

A.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 13:28:44 -0500

Anton: 
I understand you question.  I2RS YANG Models are mostly config=true.
However, these contain a few nodes of operational state (config=false).
We've been focusing on the config=true nodes in the discussion.  You are
right about the config=false nodes. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 1:15 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on

I am just noting that from my implementer's viewpoint your security concerns
seem different if you are presented as config=true or config=false.

These have a different security model by definition and by implementation in
most cases.

A.

On 24/01/17 17:50, Susan Hares wrote:
> designed for ephemeral state with specific security concerns.  This is 
> not your basic YANG model no matter which data store ephemeral gets linked
to.
> Where is ephemeral state?  By IESG Design of charter, I2RS is not in 
> charge of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask
them.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 24 Jan 2017 15:01:49 -0500

Sue: 

	The implication of that statement is that actual implementations (like ODL etc) now 
need to copy/paste this model without the I2RS text to use them in other ways. This seems
strange and just about the most inefficient way to use these that I can think of.

	—Tom

> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares <[email-masked]> wrote:
> 
> Anton:  
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 24 Jan 2017 23:04:56 +0100

Dear all,

The thread that grows faster than you can read...

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
    This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
    Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is 
equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a 
data model usage to a particular protocol. These topology documents are 
not I2RS YANG models, these are YANG models, which can be used in 
different contexts. I'm very concerned if we start having per-WG or per 
context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the 
requirements.
We can't modify the current generic YANG security considerations for an 
I2RS control plane and a new datastore that are not yet specified. If 
you want to describe how I2RS will be using those topology YANG models 
(and any YANG models btw), then it's suitable to include this part of 
the I2RS protocol spec or part of an I2RS applicability statement. This 
is typically where you would describe some protocol specific information 
such as "write contention for two clients writing a node using I2RS 
priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS 
needs to use the IETF interface YANG model, does it mean that you will 
require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it 
relates to IETF specified protocols NETCONF and RESTCONF. Addition of 
some generic information about the data model (not I2RS protocol) might 
be useful though. For example, text around "there is a risk that a write 
to a topology may create a looping topology or overload a particular 
node". Note that I don't think the the security considerations is the 
best section for this though.

Regards, Benoit

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 19:10:57 -0500

Tom:

Unclear what you are saying.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, January 24, 2017 3:02 PM
To: Susan Hares
Cc: [email-masked]; Anton Ivanov
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

	Sue: 

	The implication of that statement is that actual implementations (like ODL etc) now need to copy/paste this model without the I2RS text to use them in other ways. This seems strange and just about the most inefficient way to use these that I can think of.

	—Tom

> not your basic YANG model no matter which data store ephemeral gets linked to.
> charge of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 24 Jan 2017 19:16:36 -0500

Please refer to what Benoit just said.

	—Tom

> On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares <[email-masked]> wrote:
> 
> Tom:
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Jan 2017 19:21:42 -0500

Thank you for your comment.   I will follow-up with Benoit. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, January 24, 2017 7:17 PM
To: Susan Hares
Cc: [email-masked]; Anton Ivanov
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

	—Tom

>> designed for ephemeral state with specific security concerns.  This 
>> is not your basic YANG model no matter which data store ephemeral gets linked to.
>>> so are these YANG models regular YANG models or are these YANG 
>>> models specific to the yet to be defined I2RS protocol and yet to be 
>>> defined datastores?
>>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 24 Jan 2017 21:51:03 -0500

Tom,

Let me be absolutely clear - and this is not just directed at you,
obviously.

The IESG shares the various balloting positions for transparency.
They are supposed to be handling specific technical concerns and objections.

I am extremely disappointed in the quality of the discussion, the efforts
to reopen
topics that have been closed and approved for publication, and the shocking
and
appalling unwillingness to listen or discuss the actual issues involved.

I2RS uses feature extensions that were not available in basic YANG and
NetConf.
Those features are used in I2RS models.   Unsurprisingly, this can and does
carry
security implications depending on the details of the feature.

IF several of you have not been thinking through the implications of the
work, it
is not for lack of effort on the part of the I2RS WG or its chairs, in the
past and present.

It would be fascinating to see conversation delving into the technical
questions instead
of trying to assert how things should be without doing the detailed work of
understanding
the implications.

I have excellent technical conversations with most of you across many years.

I am extremely disappointed.

Alia

On Tue, Jan 24, 2017 at 7:16 PM, Thomas Nadeau <[email-masked]>
wrote:

> >       The implication of that statement is that actual implementations
> (like ODL etc) now need to copy/paste this model without the I2RS text to
> use them in other ways. This seems strange and just about the most
> inefficient way to use these that I can think of.
> >
> >       —Tom
> >
> >
> >

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 25 Jan 2017 06:46:55 +0000

> 	Please refer to what Benoit just said.

Concur.

+1.

A.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jan 2017 10:02:07 +0100

+1

/js

On Tue, Jan 24, 2017 at 11:04:56PM +0100, Benoit Claise wrote:
> This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally
> applicable to this draft-ietf-i2rs-yang-l3-topology draft.
> I still maintain this point of view: it would be a mistake to limit a data
> model usage to a particular protocol. These topology documents are not I2RS
> YANG models, these are YANG models, which can be used in different contexts.
> I'm very concerned if we start having per-WG or per context data models in
> the IETF.
> We can't modify the current generic YANG security considerations for an I2RS
> control plane and a new datastore that are not yet specified. If you want to
> describe how I2RS will be using those topology YANG models (and any YANG
> models btw), then it's suitable to include this part of the I2RS protocol
> spec or part of an I2RS applicability statement. This is typically where you
> would describe some protocol specific information such as "write contention
> for two clients writing a node using I2RS priority (linked to I2RS
> User-ID)".
> 
> Let me make my point differently. Let's assume for a moment that I2RS needs
> to use the IETF interface YANG model, does it mean that you will require RFC
> 7223bis with an updated security considerations? This can't be.
> 
> relates to IETF specified protocols NETCONF and RESTCONF. Addition of some
> generic information about the data model (not I2RS protocol) might be useful
> though. For example, text around "there is a risk that a write to a topology
> may create a looping topology or overload a particular node". Note that I
> don't think the the security considerations is the best section for this
> though.
> 
> Regards, Benoit
> > 	Sue:
> >

---

From: Giles Heron <[email-masked]>
Date: Wed, 25 Jan 2017 09:30:36 +0000

Hi Benoit

agreed - the model should be independent of the protocol used to access it.

As mentioned earlier on the thread, OpenDaylight has implemented older versions of the model.  Over time I’d expect each service in OpenDaylight that uses the models to upgrade to the upcoming RFC.  In general OpenDaylight implements the models as read-only (i.e. in its operational data-store), though as Robert Varga has noted there’s a case where we use the config data-store for device inventory (longer term that will move to the ietf-network model but not ietf-network-topology - though there might be use cases where you’d have read-write access to ietf-network-topology, e.g when using it to express intent.)

OpenDaylight enables access to topology data using NETCONF and RESTCONF as the north-bound protocoIs are independent of the models accessed.  I believe there has also been some work on using AMQP as a north-bound protocol, and that the Kafka plug-in could be used to send data change notifications for the operational models (so you’d get a message when a link went up or down etc.)   South-bound we have also used ODL to read topology data from a device using NETCONF/YANG (IIRC we showed a demo of this using Homenet running on OpenWrt at IETF a couple of years back).

I’m also working with other groups such as MEF and OpenROADM to leverage the I2RS topology models for their YANG efforts.    So clearly the models need to be used in a non-I2RS environment.

Giles

> On 24 Jan 2017, at 22:04, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
> Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>, and that they don't go in the I2RS protocol specific details.
> This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
> I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
> Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
> We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)". 
> 
> Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.
> 
> I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though. 
> 
> Regards, Benoit
>> 	Sue: 
>> 
>>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> Anton:  
>>> 
>>> From: i2rs [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Anton Ivanov
>>> To: [email-masked] <mailto:[email-masked]>

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 25 Jan 2017 09:36:56 +0000

On 25/01/17 09:30, Giles Heron wrote:
> As mentioned earlier on the thread, OpenDaylight has implemented older 
> versions of the model.  Over time I’d expect each service in 
> OpenDaylight that uses the models to upgrade to the upcoming RFC.  In 
> general OpenDaylight implements the models as read-only (i.e. in its 
> operational data-store), though as Robert Varga has noted there’s a 
> case where we use the config data-store for device inventory (longer 
> term that will move to the ietf-network model but not 
> ietf-network-topology - though there might be use cases where you’d 
> have read-write access to ietf-network-topology, e.g when using it to 
> express intent.)
>
> OpenDaylight enables access to topology data using NETCONF and 
> RESTCONF as the north-bound protocoIs are independent of the models 
> accessed.  I believe there has also been some work on using AMQP as a 
> north-bound protocol, and that the Kafka plug-in could be used to send 
> data change notifications for the operational models (so you’d get a 
> message when a link went up or down etc.)   South-bound we have also 
> used ODL to read topology data from a device using NETCONF/YANG (IIRC 
> we showed a demo of this using Homenet running on OpenWrt at IETF a 
> couple of years back).
>
> I’m also working with other groups such as MEF and OpenROADM to 
> leverage the I2RS topology models for their YANG efforts.    So 
> clearly the models need to be used in a non-I2RS environment.

+1.

I am working on JSON RPC ODL southbound into non-ODL systems. For some 
of the use cases you may need to build topologies out of the information 
you receive from it.

So from my extremely selfish implementer perspective having topology 
models which is stapled to a particular protocol and are not allowed to 
be used in a more generic way, namely in a non-I2RS environment, is a 
definitive NO GO.

A.

>
> Giles
>
>> On 24 Jan 2017, at 22:04, Benoit Claise <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear all,
>>
>> data model usage to a particular protocol. These topology documents 
>> are not I2RS YANG models, these are YANG models, which can be used in 
>> different contexts. I'm very concerned if we start having per-WG or 
>> per context data models in the IETF.
>> We can't modify the current generic YANG security considerations for 
>> an I2RS control plane and a new datastore that are not yet specified. 
>> If you want to describe how I2RS will be using those topology YANG 
>> models (and any YANG models btw), then it's suitable to include this 
>> part of the I2RS protocol spec or part of an I2RS applicability 
>> statement. This is typically where you would describe some protocol 
>> specific information such as "write contention for two clients 
>> writing a node using I2RS priority (linked to I2RS User-ID)".
>>
>> needs to use the IETF interface YANG model, does it mean that you 
>> will require RFC 7223bis with an updated security considerations? 
>> This can't be.
>>
>> some generic information about the data model (not I2RS protocol) 
>> might be useful though. For example, text around "there is a risk 
>> that a write to a topology may create a looping topology or overload 
>> a particular node". Note that I don't think the the security 
>> considerations is the best section for this though.
>>
>> Regards, Benoit
>>> 	Sue:
>>>
>>>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares<[email-masked]>  wrote:
>>>>
>>>> Anton:
>>>>
>>>> To:[email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 25 Jan 2017 12:29:11 -0500

Lou: 

I am happy to receive your email as it demonstrates misconceptions about
what I stated.   The original topic of this thread was the security
considerations section regarding an I2RS Topology model.  Due to my respect
for you, I am going to provide you a technical response on list.   I have
labeled my responses to respond to your points.  I have responded on l but I
will not follow-up on this thread.   I encourage you to contact me directly
via phone or email.   

Cheerily, 

Sue 

----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2017 7:27 AM
To: Susan Hares
Cc: 'Martin Bjorklund'; [email-masked];
[email-masked]; [email-masked]; [email-masked]

Sue,

In short, I'm going to agree with Benoit - but for slightly different
reasons as I also co-chair TEAS, a group that is basing some of its work on
I2RS developed models.

>Lou 1:  As a WG chair, I have always viewed the models being developed by
I2RS as typical models that are generally useful, and being defined by I2RS
simply because they were ahead of other groups that might otherwise define
the >models -- and I view this as a fine thing that has benefit for YANG
users and other WGs. As TEAS chair, this is what lead me to ensure that the
models being defined in TEAS built on the I2RS YANG modules vs their
original path of redefining >parallel function.

Sue 1: I am pleased that TEAS WG and other WG find the Topology models
useful.   The topology model design encompasses ephemeral state and security
for ephemeral state.  It was built to be a platform for topology models, and
to had early experimentation in the ODL models.   Perhaps you missed the
email on this thread where an insightful Martin asked "Does this mean I2RS
models cannot be used by Topology models in other WGs?"

I responded "not really" and more specifically " Most of the topology models
I have seen abide by the concepts found in the I2RS topology model."  

Please see the mail at:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04231.html.  

The Topology models really operate best in an ephemeral state environment.
Ephemeral state is not a I2RS-only functionality.  Starting 4 years ago with
discussions with NETCONF/NETMOD at the NYC interim, 

It was indicated that ephemeral state would be used by other WGs.  One of
these key uses is the use for Topology models.  Topology model's ephemeral
state allow operational state learned from the routing system to be altered
with writes from the I2RS Client.    (Please note the security
considerations occur once read sensitive information or write sensitive
information).   This mixture of state does not really match the definition
of the 

   o  configuration datastore: The datastore holding the complete set of

      configuration data that is required to get a device from its

      initial default state into a desired operational state.

Let's look at how this applies to the draft-ietf-teas-yang-te-topo-06.txt in
section 3.1: 

" TE topology is a traffic engineering representation of one or more

   layers of network topologies. TE topology is comprised of TE nodes

   (TE graph vertices) interconnected via TE links (TE graph edges). A

   TE topology is mapped to a TE graph." 

TE topology model defines: underlay TE topology, overlay TE topology, and
Abstract TE topology.    The model in draft-ietf-teas-yang-te-topo-06.txt
(ietf-te-topology) is technology agnostic blending learned topology
(underlay TE topology) and configured topology to create an abstract TE
topology.   This is a wonderful use of the I2RS Topology model.  

Let's look what additional security is needed for Topology Models in
Ephemeral state: 

Transport: 

Ephemeral state with topology models has security risks which include
topology information may be sensitive or allow DoS attacks.  Based on this
point, the I2RS WG spent time looking at what protocol security and
environment security is needed.  To protect this information, I2RS WG decide
the NETCONF/RESTCONF must run over a transport that provide mutual
authentication, data confidentiality, data integrity and practical replay
protections which had structure to limit DoS attacks.  Mutual authentication
requires a key management system and the definition of what an I2RS
identifier is.   The security environment would need policy that determine
the interaction with other data stores, control plane protocols, and dynamic
configuration protocols.  These are additions to the basic yang security
considerations (sensitive/privacy read nodes,  sensitive/privacy in write
nodes, or sensitive/privacy in rpc commands).  

I2RS allowed the security association to exist without transport
connections, or to have multiple transport connections.  This mechanism
provide better bandwidth for accessing topology models. 

AFAIK - the NETCONF over SSH does not provide this level of security but
NETCONF over TLS with X.509v3 does and RESTCONF do.  If I NETCONF over SSH
(RFC4722) does provide this level of security, then please let me know.   

Any data store must solve the problem of multiple clients writing a data
node. I2RS decided multiple I2RS clients might want to write the topology in
the I2RS Agent, but defined the simultaneous write as an error (with
priority system as resolution).   This write contention is an alternative to
the configuration data store lock or the RESTCONF lock for a single actions.
I2RS felt the speed choices on priority (similar to BGP choices) were better
for ephemeral state.   If the priority system is used, then one priority
must be assigned per user identifier.  If TEAS or NETMOD wants to define
another mechanism, then this is a change from the I2RS protocol/ephemeral
store definitions.   It would be wonderful to have a discussion of this in
NETMOD since the ephemeral state requirement require it.  It would be nice
to have one multiple-write mechanism for a generalize ephemeral state. 

I2RS felt tracing, better notification and pub/sub was necessary for I2RS.
TEAS can refuse to import the trace, better notification or pub/sub work.  

>Lou 2:  As part of my view of the I2RS models being generally applicable to
uses beyond I2RS together with I2RS choosing YANG for modeling ephemeral
data, I have always expected that the I2RS WG would at some (perhaps as part
of 

>the I2RS protocol definition) define how any YANG model can be used to
support I2RS. This view certainly lead me to conclude that having the I2RS
models move forward, just like any other YANG model, makes sense and would
benefit the 

> other models and WGs that reference this core work. This view also allows
for the relationship to the revised-data store work, as well as the
specification of which data

> store(s) I2RS uses, to be separately defined -- and to not gate
publication of these models. This separate specification would be the
location for any I2RS-specific transport and security considers, so such
would not belong in the 

> generally reusable models developed by I2RS.

>Essentially, As NETMOD co-chair, I concluded that the revised data store
work provided the direction on how ephemeral would be supported in a general
YANG context and, therefore, the major open issue / gating impediment to
>progressing I2RS models had been removed and publication of these models
were unblocked. This also motivated my comments in the related discussions
at the last meeting.

Sue 2:   Is the direction for the ephemeral state concepts agreed upon?  The
real test is if we are able to define ephemeral state within the control
plane data store.  

You and I both thought that the adoption of
draft-ietf-netmod-ietf-revised-datastores-00.txt completed this work on
getting ephemeral data store concepts completed.   You, I, Alia, Benoit
thought progressing these key models based on these concepts of ephemeral
state in this document seemed reasonable.   However, this discussion seems
to be stuck on what is ephemeral state and why is it different.  If so,
NETMOD does not have a clear ephemeral data store definition.  

Let's try 2 tests:  a) did we get stuck on the security considerations
section?  (yes),   b) Is there general agreement and a proposal for Yang
modifications for ephemeral state? (no) 

Draft-ietf-netmod-ietf-revised-datastores-00.txt suggest the Control Plane
Data stores but there has been confusion on this being an ephemeral data
store with config=true nodes and operational state.  There document suggests
a "<get-data datastore>, but does not suggest a "write-data datastore>
command for ephemeral data store.  Perhaps based on the feedback from
Juergen and Martin, means we need to create: a) an I2RS ephemeral Control
Plane data store description, and b) create a document or a section in these
documents on the assumptions of data stores. 

At the very least we should add to this document what Martin's suggests in
the email at:  

https://www.ietf.org/mail-archive/web/i2rs/current/msg04234.html

Which states: 

"Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly
work-in-progress, and (2) none of the topology drafts reference
draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a
solution in that draft, it is not very clear to the reader".

The draft-hares-i2rs-yang-sec-consider-00 suggests security considerations
need to indicate: mandatory transport, 4 features of the ephemeral data
store defined by I2RS, and whether any portion of the YANG model can move
over insecure transport.   Since these 4 features of I2RS ephemeral data
store set by the I2RS ephemeral state requirements
(draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed to in
draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not completed  

Lou 3: If my understanding/view is correct, i.e., that the topology models
are just like any other YANG model, then I think publication can and should
proceed (with the appropriate text for a typical YANG model).

Sue 3: I hope that my explanation above indicates that the I2RS Topology
models are ephemeral models built for Topologies like TEAS.  It is the very
qualities you see in topology models that cause them to be ephemeral in
order to mix the operational state with configuration state in a way that
the configuration data store cannot.   If we have a solid definition of
Ephemeral data stores and Ephemeral Data models, then these data models are
like any other ephemeral YANG model.  Any ephemeral model must choose a
multiple client-write design.   It would be lovely to have a single
ephemeral data store design.    

Lou 4:  If I misunderstood something, and the models produced by I2RS are
limited to ephemeral representations/data stores as well as specific YANG
transport protocols -- then as TEAS chair, I have to hit reset on the TEAS
topology work, and as NETMOD chair I think the NETMOD WG needs to discuss
what it means for a YANG model to be protocol/datastore specific and if any
guidelines or other new NTEMOD documents are need to support such.

Sue 4: Perhaps the TEAS WG Chair needs to discuss with the NETMOD WG Chair
about completing the Ephemeral data store work before coming to a
conclusion.  

Lou 5: Less importantly, as I2RS participant, I'd also ask for the documents
to be sent back to the WG for a new last call once the documents are updated
to reflect their narrow scope -- as I bet I'm not the only person who viewed
this work applicable to non-ephemeral uses.

Sue 5:  As an I2RS Chair, I am not sure you have correctly defined the
narrow scope of the I2RS work or these documents.  Of course, after we
complete the revisions of these documents if the ADs (Alia and Benoit) deem
these need to go back to the WG for another WG LC, then we will send the
drafts for another WG LC.   Right now, the only thing that the drafts have
firmly to revise is the Yang Security considerations define by 

https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

The rest of this list discussion is simply a discussion of IESG members and
people who did not participate in the WG LC or the IETF LC regarding a
proposal for addition security considerations.   As Shepherd, Kathleen's
questions about security consideration found missing piece and I wrote a
discussion document.  Unfortunately, the discussion has not examined the
document (draft-hares-i2rs-yang-sec-consider) or the open issues in
ephemeral stsate. 

Lou 6: I hope this helps.

Sue 6: Was it meant to be helpful?  I really, really hope you are engaging
in a technical discussion about ephemeral state and how we can move forward.

Two comments: 

.         "then as a TEAS chair, I have to hit rest on the TEAS topology
work" or as a

.         "I2RS participant, I'd also ask for the document to be sent to the
WG for a new last call once the documents are updated" 

seem to be making conclusions without discussion.  

Cheerily, 

Sue 

> decision to make I2RS Yang Modules part of the Control Plane Datastore 

> then as shepherd/WG-chair I will recommend these get added to the draft.

> As we wait for the NETMOD WG Chairs and Benoit to deliver the decision 

> on Config/Control Plane datastore, the authors should work on:  Basic 

> Yang security considerations and the other I2RS Yang Module information.

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

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

>> draft-ietf-netmod-revised-datastores-00.txt.  The reason the answer 

>> is unclear is that it depends on the context of the question.

>> .         If you ask if the WG LC Topology models are approved to be part

> of

>> If you are concerned the implementation varies from the standardized,

> please

>> express this to Benoit Claise.   Based on your comments on my email

> thread,

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

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

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

>> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in 

>> > fact,

>> > ephemeral data store." This statement is not what I understood from 

>> > IETF

>> > ADs.   I guess your objection to this data model falls into Benoit

> Claise

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

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

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

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

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

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

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

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

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

>> > > topology models are handled as part of the configuration data 

>> > > While standardizing the topology data models, the I2RS WG have 

>> > > been

>> > > Quite frankly, I feel a bit of whip-lash on this topic.   NETMOD WG

> asks

>> > > Topology models - if the right details are taken care of.   How do we

>> make

>> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in 

>> > fact,

>> > notes), for the existing protocols and architecure.  This would 

>> > allow

>> > > From: Robert Varga [ < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> mailto:[email-masked]]

>> > > To: Martin Bjorklund;  < <mailto:[email-masked]>
mailto:[email-masked]>  <mailto:[email-masked]> [email-masked]

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

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

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

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

>> > > >> Question 1: Ok.  Just to make sure I understand this correctly

>> > > >> these topology models are intended to be I2RS-specific, and 

>> > > >> they

>> > > >> cannot be used for any other purpose.  If anyone needs a 

>> > > >> general

>> > > > Ok, so are you saying that the models are in fact generic, and 

>> > > > can

>> > > > be used outside of I2RS?  I.e., they *can* be used with the 

>> > > > normal

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Jan 2017 13:23:14 -0500

Hi Sue,

On 1/25/2017 12:29 PM, Susan Hares wrote:
>
> Lou:
>
>  
>
> I am happy to receive your email as it demonstrates misconceptions
> about what I stated.   The original topic of this thread was the
> security considerations section regarding an I2RS Topology model. 
>
Understood.
>
> Due to my respect for you, I am going to provide you a technical
> response on list.
>
Thank you (I think).

>  I have labeled my responses to respond to your points.  I have
> responded on l but I will not follow-up on this thread.   I encourage
> you to contact me directly via phone or email.   
>
>  
>
okay - but I'm not sure if you want me to address the comments below
here or wait for an off-line call. I guess I'll wait for a one-on-one
discussion.

> seem to be making conclusions without discussion. 

To be clear my statements on what's next had caveats that were based on
what you/I2RS/the IESG decide - it was not stating a definitive
conclusion or direction, but rather possibilities based on a decision
that I expect to happen in the context of I2RS.  

Lou

> reasons as I also co-chair TEAS, a group that is basing some of its
> work on I2RS developed models.
>
>  
>
> *>Lou 1:*  As a WG chair, I have always viewed the models being
> developed by I2RS as typical models that are generally useful, and
> being defined by I2RS simply because they were ahead of other groups
> that might otherwise define the >models -- and I view this as a fine
> thing that has benefit for YANG users and other WGs. As TEAS chair,
> this is what lead me to ensure that the models being defined in TEAS
> built on the I2RS YANG modules vs their original path of redefining
> >parallel function.
>
>  
>
> *Sue 1:*I am pleased that TEAS WG and other WG find the Topology
> models useful.   The topology model design encompasses ephemeral state
> and security for ephemeral state.  It was built to be a platform for
> topology models, and to had early experimentation in the ODL models.
>   Perhaps you missed the email on this thread where an insightful
> Martin asked "Does this mean I2RS models cannot be used by Topology
> models in other WGs?”
>
> I responded "not really" and more specifically " Most of the topology
> models I have seen abide by the concepts found in the I2RS topology
> model." 
>
> Please see the mail at:
> The Topology models really operate best in an ephemeral state
> environment.  Ephemeral state is not a I2RS-only functionality. 
> Starting 4 years ago with discussions with NETCONF/NETMOD at the NYC
> interim,
>
> It was indicated that ephemeral state would be used by other WGs.  One
> of these key uses is the use for Topology models.  Topology model’s
> ephemeral state allow operational state learned from the routing
> system to be altered with writes from the I2RS Client.    (Please note
> the security considerations occur once read sensitive information or
> write sensitive information).   This mixture of state does not really
> match the definition of the
>
> Let’s look at how this applies to the
> draft-ietf-teas-yang-te-topo-06.txt in section 3.1:
>
>    
>
> TE topology model defines: underlay TE topology, overlay TE topology,
> and Abstract TE topology.    The model in
> draft-ietf-teas-yang-te-topo-06.txt (ietf-te-topology) is technology
> agnostic blending learned topology (underlay TE topology) and
> configured topology to create an abstract TE topology.   This is a
> wonderful use of the I2RS Topology model.  
>
>  
>
> *Let’s look what additional security is needed for Topology Models in
> Ephemeral state: *
>
>  
>
> *Transport: *
>
> topology information may be sensitive or allow DoS attacks.  Based on
> this point, the I2RS WG spent time looking at what protocol security
> and environment security is needed.  To protect this information, I2RS
> WG decide the NETCONF/RESTCONF must run over a transport that provide
> mutual authentication, data confidentiality, data integrity and
> practical replay protections which had structure to limit DoS attacks.
>  Mutual authentication requires a key management system and the
> definition of what an I2RS identifier is.   The security environment
> would need policy that determine the interaction with other data
> stores, control plane protocols, and dynamic configuration protocols.
>  These are additions to the basic yang security considerations
> (sensitive/privacy read nodes,  sensitive/privacy in write nodes, or
> sensitive/privacy in rpc commands).  
>
>  
>
> connections, or to have multiple transport connections.  This
> mechanism provide better bandwidth for accessing topology models.
>
>  
>
> AFAIK – the NETCONF over SSH does not provide this level of security
> but NETCONF over TLS with X.509v3 does and RESTCONF do.  If I NETCONF
> over SSH (RFC4722) does provide this level of security, then please
> let me know.   
>
>  
>
> Any data store must solve the problem of multiple clients writing a
> data node. I2RS decided multiple I2RS clients might want to write the
> topology in the I2RS Agent, but defined the simultaneous write as an
> error (with priority system as resolution).   This write contention is
> an alternative to the configuration data store lock or the RESTCONF
> lock for a single actions.  I2RS felt the speed choices on priority
> (similar to BGP choices) were better for ephemeral state.   If the
> priority system is used, then one priority must be assigned per user
> identifier.  If TEAS or NETMOD wants to define another mechanism, then
> this is a change from the I2RS protocol/ephemeral store definitions. 
>  It would be wonderful to have a discussion of this in NETMOD since
> the ephemeral state requirement require it.  It would be nice to have
> one multiple-write mechanism for a generalize ephemeral state.
>
>  
>
> I2RS felt tracing, better notification and pub/sub was necessary for
> I2RS.   TEAS can refuse to import the trace, better notification or
> pub/sub work.  
>
>   
>
>  
>
> *>Lou 2:*  As part of my view of the I2RS models being generally
> applicable to uses beyond I2RS together with I2RS choosing YANG for
> modeling ephemeral data, I have always expected that the I2RS WG would
> at some (perhaps as part of
>
> >the I2RS protocol definition) define how any YANG model can be used
> to support I2RS. This view certainly lead me to conclude that having
> the I2RS models move forward, just like any other YANG model, makes
> sense and would benefit the
>
> > other models and WGs that reference this core work. This view also
> allows for the relationship to the revised-data store work, as well as
> the specification of which data
>
> location for any I2RS-specific transport and security considers, so
> such would not belong in the
>
> >Essentially, As NETMOD co-chair, I concluded that the revised data
> store work provided the direction on how ephemeral would be supported
> in a general YANG context and, therefore, the major open issue /
> gating impediment to >progressing I2RS models had been removed and
> publication of these models were unblocked. This also motivated my
> comments in the related discussions at the last meeting.
>
>  
>
> *Sue 2:*  Is the direction for the ephemeral state concepts agreed
> upon?  The real test is if we are able to define ephemeral state
> within the control plane data store.  
>
>  
>
> draft-ietf-netmod-ietf-revised-datastores-00.txt completed this work
> on getting ephemeral data store concepts completed.   You, I, Alia,
> Benoit thought progressing these key models based on these concepts of
> ephemeral state in this document seemed reasonable.   However, this
> discussion seems to be stuck on what is ephemeral state and why is it
> different.  If so, NETMOD does not have a clear ephemeral data store
> definition.  
>
>  
>
> Let’s try 2 tests:  a) did we get stuck on the security considerations
> section?  (yes),   b) Is there general agreement and a proposal for
> Yang modifications for ephemeral state? (no)
>
>  
>
> Draft-ietf-netmod-ietf-revised-datastores-00.txt suggest the Control
> Plane Data stores but there has been confusion on this being an
> ephemeral data store with config=true nodes and operational state. 
> There document suggests a “<get-data datastore>, but does not suggest
> a “write-data datastore> command for ephemeral data store.  Perhaps
> based on the feedback from Juergen and Martin, means we need to
> create: a) an I2RS ephemeral Control Plane data store description, and
> b) create a document or a section in these documents on the
> assumptions of data stores.
>
> At the very least we should add to this document what Martin’s
> suggests in the email at:  
>
> /“Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly/
> /work-in-progress, and (2) none of the topology drafts reference/
> /draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a/
> /solution in that draft, it is not very clear to the reader”./
>
>  
>
> The draft-hares-i2rs-yang-sec-consider-00 suggests security
> considerations need to indicate: mandatory transport, 4 features of
> the ephemeral data store defined by I2RS, and whether any portion of
> the YANG model can move over insecure transport.   Since these 4
> features of I2RS ephemeral data store set by the I2RS ephemeral state
> requirements (draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed
> to in draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not
> completed  
>
>  
>
> *Lou 3:* If my understanding/view is correct, i.e., that the topology
> models are just like any other YANG model, then I think publication
> can and should proceed (with the appropriate text for a typical YANG
> model).
>
>  
>
> *Sue 3:* I hope that my explanation above indicates that the I2RS
> Topology models are ephemeral models built for Topologies like TEAS. 
> It is the very qualities you see in topology models that cause them to
> be ephemeral in order to mix the operational state with configuration
> state in a way that the configuration data store cannot.   If we have
> a solid definition of Ephemeral data stores and Ephemeral Data models,
> then these data models are like any other ephemeral YANG model.  Any
> ephemeral model must choose a multiple client-write design.   It would
> be lovely to have a single ephemeral data store design.    
>
>  
>
> *Lou 4*:  If I misunderstood something, and the models produced by
> I2RS are limited to ephemeral representations/data stores as well as
> specific YANG transport protocols -- then as TEAS chair, I have to hit
> reset on the TEAS topology work, and as NETMOD chair I think the
> NETMOD WG needs to discuss what it means for a YANG model to be
> protocol/datastore specific and if any guidelines or other new NTEMOD
> documents are need to support such.
>
>  
>
> *Sue 4:*Perhaps the TEAS WG Chair needs to discuss with the NETMOD WG
> Chair about completing the Ephemeral data store work before coming to
> a conclusion. 
>
>  
>
> *Lou 5:*Less importantly, as I2RS participant, I'd also ask for the
> documents to be sent back to the WG for a new last call once the
> documents are updated to reflect their narrow scope -- as I bet I'm
> not the only person who viewed this work applicable to non-ephemeral uses.
>
>  
>
> *Sue 5:  *As an I2RS Chair, I am not sure you have correctly defined
> the narrow scope of the I2RS work or these documents.  Of course,
> after we complete the revisions of these documents if the ADs (Alia
> and Benoit) deem these need to go back to the WG for another WG LC,
> then we will send the drafts for another WG LC.   Right now, the only
> thing that the drafts have firmly to revise is the Yang Security
> considerations define by
>
>  
>
> The rest of this list discussion is simply a discussion of IESG
> members and people who did not participate in the WG LC or the IETF LC
> regarding a proposal for addition security considerations.   As
> Shepherd, Kathleen’s questions about security consideration found
> missing piece and I wrote a discussion document.  Unfortunately, the
> discussion has not examined the document
> (draft-hares-i2rs-yang-sec-consider) or the open issues in ephemeral
> stsate.
>
>  
>
> *Lou 6:*I hope this helps.
>
>  
>
> *Sue 6:*Was it meant to be helpful?  I really, really hope you are
> engaging in a technical discussion about ephemeral state and how we
> can move forward. 
>
>  
>
> Two comments:
>
> ·         “then as a TEAS chair, I have to hit rest on the TEAS
> topology work” or as a
>
> ·         “I2RS participant, I’d also ask for the document to be sent
> to the WG for a new last call once the documents are updated”
>
>  
>
> On January 24, 2017 11:56:32 AM "Susan Hares" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>  
>
> > To: Martin:
>
> > 
>
> > To: [email-masked] <mailto:[email-masked]>
>
> > Cc: [email-masked] <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>;
>
> > [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>;
>
> > [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>;
>
> > [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>
> > "Susan Hares" <[email-masked] <mailto:[email-masked]>> wrote:
>
> >> Martin:
>
> >> 
>
> >> 
>
> >> 
>
> >> To: [email-masked] <mailto:[email-masked]>
>
> >> Cc: [email-masked] <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>;
>
> >> [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>;
>
> >> [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>;
>
> >> [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>
> >> "Susan Hares" < <mailto:[email-masked]> [email-masked]
> <mailto:[email-masked]>> wrote:
>
> >> 
>
> >> > Martin:
>
> >> 
>
> >> >
>
> >> 
>
> >> > From: i2rs [ <mailto:[email-masked]>
>
> >> > mailto:[email-masked]]
>
> >> On Behalf Of Martin
>
> >> 
>
> >> > Bjorklund
>
> >> 
>
> <mailto:[email-masked]>
> >> > Cc:  <mailto:[email-masked]> [email-masked] <mailto:[email-masked]>;
>
> >> [email-masked]
> <mailto:[email-masked]>;
>
> >> 
>
> >> [email-masked]
> <mailto:[email-masked]>; 
> <mailto:[email-masked]>
>
> >> [email-masked] <mailto:[email-masked]>;
>
> >> 
>
> >> >  <mailto:[email-masked]> [email-masked] <mailto:[email-masked]>;
>
> >> [email-masked]
> <mailto:[email-masked]>; <mailto:[email-masked]>
>
> >> [email-masked] <mailto:[email-masked]>
>
> >> 
>
> >> > "Susan Hares" < <mailto:[email-masked]> [email-masked]
> <mailto:[email-masked]>> wrote:
>
> >> 
>
> >> > > Robert and Martin:
>
> >> 
>
> >> > >
>
> >> 
>
> <mailto:[email-masked]>
> >> > > Cc:  <mailto:[email-masked]> [email-masked] <mailto:[email-masked]>;
>
> >> [email-masked]
> <mailto:[email-masked]>;
>
> >> 
>
> >> [email-masked]
> <mailto:[email-masked]>; 
> <mailto:[email-masked]>
>
> >> [email-masked] <mailto:[email-masked]>;
>
> >> 
>
> >> [email-masked]
> <mailto:[email-masked]>;  <mailto:[email-masked]>
>
> >> [email-masked] <mailto:[email-masked]>
>
> >> 
>
> >> >  <mailto:[email-masked]> [email-masked] <mailto:[email-masked]>
>
> >> 
>