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 protected]]
Sent: Monday, January 23, 2017 6:47 AM
To: [email protected]
Cc: [email protected];
[email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
Hi,
"Susan Hares" < <mailto:[email protected]> [email protected]> wrote:
> 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,
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
> 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 protected]>
mailto:[email protected]]
> Sent: Monday, January 23, 2017 3:39 AM
> To: Susan Hares
> Cc: 'Kathleen Moriarty'; 'The IESG';
> <mailto:[email protected]>
[email protected]; <mailto:[email protected]>
[email protected];
> <mailto:[email protected]> [email protected]
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> 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. 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>
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>
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 protected]>
mailto:[email protected]]
> > Sent: Thursday, January 19, 2017 10:34 AM
> > To: Susan Hares
> > Cc: 'Kathleen Moriarty'; 'The IESG';
> > <mailto:[email protected]>
[email protected]; <mailto:[email protected]>
[email protected];
> > <mailto:[email protected]> [email protected]
> > 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
> >
> > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares 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:
> > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside>
https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside
> > > r/
> > >
> > > 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 protected]>
mailto:[email protected]]
> > > Sent: Wednesday, January 18, 2017 9:44 PM
> > > To: The IESG
> > > Cc: <mailto:[email protected]>
[email protected]; <mailto:[email protected]>
[email protected];
> > > <mailto:[email protected]> [email protected];
<mailto:[email protected]> [email protected]; <mailto:[email protected]>
[email protected]
> > > Subject: Kathleen Moriarty's No Objection on
> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> > >
> > > 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>
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/>
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.
> > >
> > >
> > >
> > > _______________________________________________
> > > i2rs mailing list
> > > <mailto:[email protected]> [email protected]
> > > <https://www.ietf.org/mailman/listinfo/i2rs>
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/>
http://www.jacobs-university.de/>
> >
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>
>
> _______________________________________________
> i2rs mailing list
> <mailto:[email protected]> [email protected]
> <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
