Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

From: t.petch <[email-masked]>
Date: Wed, 1 Mar 2017 09:53:24 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Tuesday, February 28, 2017 8:51 PM

> >> Even updating 7950 I would expect to be resisted given how long it
took
> >> to appear but for me, it is the only logical first step and not
that
> >> difficult one, just tedious to proof-read.
> >
> > I agree.
> >
>
> As a NETMOD co-chair, I plan to start a preliminary 7950bis discussion
in Chicago.  The scope of such an effort would be the key topic, but
hopefully factoring out all the NETCONF and XML specific parts would be
near the top of the list.  I know some think that we should not waste
resources on housekeeping, but I believe that periodic cleanups are
necessary to keep things running smoothly...
>
> Of course, the XML-specific parts factored out of RFC7950 would go
into another NETMOD WG draft (mirroring RFC 7951) and the NETMOD WG
could ensure to run both the 7950bis and draft-ietf-netmod-yang-xml
drafts at the same time (for as clean a cutover as possible).  However,
it would be up to the NETCONF WG to pick-up the NETCONF-specific parts
factored out of RFC7950, and it would be up to the NETCONF WG to decide
to do this work now, or wait to do it in parallel with the NETMOD WG
(whenever that might be), or wait until after 7950bis comes out.
>
> While it seems like the NETCONF WG could kick-off this activity now if
it wanted to, said activity is nowhere near as important as updating
NETCONF WG maintained documents to support the solution defined in the
revised-datastores draft (namely RFCs 6241, 7895, 8040).  Without said
update, there would be no way for clients to access ephemeral
configuration (i2rs requirement) or operational state (open config
requirement).  So, this is clearly a higher priority, though it seems
that the two could be done at the same time, as is captured by work item
#7 in Mehmet's charter proposal.
>
> So, my opinion is that Mehmet's proposal is nearly spot-on with its
work item #7.  Yes, it’s a "monster", but it must be done ASAP or else
we fail to deliver the datastore solution in a timely manner.  The only
thing I hesitate on is that I don't think the WG has enough information
to decide if it's better to work on new standalone drafts or -bis of
existing drafts (this addresses Andy's point).  To the extent the
charter describes changes being made to specific documents, it may be
better to remove this part from the charter until more information is
known.
>
> PS: the next update to the revised datastores draft will contain an
Appendix section for each RFC believed to be impacted, in both the
NETMOD and NETCONF WGs, along with a proposal for how that RFC might be
changed or updated.  The revised datastore authors plan to request a
NETCONF WG presentation timeslot to go over the impact to NETCONF WG
drafts, with the intent of asking the WG how to proceed (e.g.,
standalone NETCONF WG drafts or -bis on existing drafts).  So, we'll be
having this discussion then, can the charter wait that long?

Kent

7 is a monster because of the XML encoding rules, not because of the
revised datastore concepts.  And datastores, as you say, are more
important - revising the XML encoding rules is cosmetic, not needed
technically and, as I said, only make sense when the NETMOD WG has done
its bit; and the revised charter being discussed on the NETMOD list
makes no mention of this work.

So scrap NETCONF XML encoding rules.

Tom Petch

> Kent

---

From: t.petch <[email-masked]>
Date: Wed, 1 Mar 2017 09:58:58 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Mehmet Ersue" <[email-masked]>
Cc: "'Netconf'" <[email-masked]>
Sent: Monday, February 27, 2017 10:14 PM
> On Mon, Feb 27, 2017 at 09:44:06PM +0100, Mehmet Ersue wrote:
>
> > 6. Revise the current NETCONF datastore concept as a protocol- and
modeling
> > language-independent standard as part of the network configuration
> > framework. Use the datastore solution proposal in
> > draft-ietf-netmod-revised-datastores as its basis. Will be used as a
> > normative reference in protocol specifications.
>
> There is no point in dupliating work in WGs that have a common history
> and a common set of active contributors.

Juergen

I am not sure what you are proposing;  Currently, datastores are poorly
described in RFC6241 and RFC7950 and the publication of another
incomplete description in the shape of
draft-ietf-netmod-revised-datastores
will likely make things worse.

I see a need for a datastores RFC, probably separate from the current
specifications, and do see the NETCONF WG as better placed to do it.

I think that the rush to  get
draft-ietf-netmod-revised-datastores
out is militating against the long term health of NETCONF.

Tom Petch

> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Mar 2017 10:45:06 +0000

Hi Tom,

> specifications, and do see the NETCONF WG as better placed to do it.

I see that datastores and YANG are directly linked.  Specifically, I 
think that the "config" statement, and any future I2RS related 
"ephemeral" statement (or extension) give the data nodes in a YANG data 
model particular semantics in the different datastores.

So, I sort of see the document hierarchy should be something like:

    Datastores architecture
             ^
             |                    (NETMOD WG)
        YANG language
        ^          ^
        |          |
        |   Encodings of YANG data trees
        |               (XML, JSON, CBOR)
        |                    ^
   -  - |-  -  -  -  -  -  - |-  -  -  -  -  -
        |                    |    (NETCONF WG)
     Common protocol abstraction
(that all YANG protocols should conform to).
     ^             ^            ^
     |             |            |
  RESTCONF      NETCONF        CoMI

So, for the split of work between NETMOD and NETCONF, my thoughts are 
that basically the work above the dotted line should be done in NETMOD, 
and the work below the line should be done in NETCONF.  Of course, some 
of the work may be done in other WGs (CoMI, I2RS, etc).

> out is militating against the long term health of NETCONF.
Please can you clarify, do you mean long term health of the NETCONF WG, 
or the NETCONF RFC, or the NETCONF protocol?

Thanks,
Rob

> .

---

From: t.petch <[email-masked]>
Date: Wed, 1 Mar 2017 11:04:25 +0000

From: "Robert Wilton" <[email-masked]>
Sent: Wednesday, March 01, 2017 10:45 AM
> > From: "Juergen Schoenwaelder" <[email-masked]

I mean NETCONF the means of doing network configuration, so that
includes the protocol as defined in RFC6241, datastores as defined in
RFC6241 and the existence of a data modelling language and data models
written therein.  Essentially, the problem that the NETCONF WG was set
up to solve.

The weakness I see is the lack of a Standards Track architecture or
framework or some such which would likely have datastores at its heart;
and, unlike you, I see the expertise for that in the NETCONF WG and not
in the NETMOD WG.

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Mar 2017 11:38:12 +0000

> and, unlike you, I see the expertise for that in the NETCONF WG and not
OK.  I had, perhaps incorrectly, assumed that the same experts are 
participating in both WGs, and the split was more for a division of 
labour rather than differing areas of expertise.

Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 Mar 2017 13:01:26 +0100

> On 1 Mar 2017, at 10:58, t.petch <[email-masked]> wrote:
> 
> 

I agree, and I would also add draft-ietf-netmod-schema-mount to it (of which I am a co-author).

Original NETCONF and YANG were limited but (mostly) coherent and, in a way, simple and elegant. The recent developments are afterthoughts and kitchen sinks that will destroy these qualities.

Instead of rushing with these documents, we should step back and think about a new architecture that could consistently support the new requirements.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: t.petch <[email-masked]>
Date: Wed, 1 Mar 2017 13:02:24 +0000

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Wednesday, March 01, 2017 11:38 AM

> >>>>> draft-ietf-netmod-revised-datastores as its basis. Will be used
as
> > a

Robert

There is another practical reason for me.  NETCONF is a 'friendly' list
where I get any e-mail thereon next time I logon, which is most days a
week.  NETMOD is different.  I am currently up-to-date, but only for the
first time in a month; some times I am months behind and thinking I
could have contributed to that if only the topic were not several
hundred e-mails further on by now.  So anything on NETCONF I have the
chance to contribute to; NETMOD de facto I do not.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 Mar 2017 14:13:19 +0100

> On 1 Mar 2017, at 14:02, t.petch <[email-masked]> wrote:
> 

I don't get how this maps to the level of expertise in either WG.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Mar 2017 07:39:47 -0800

> written therein.  Essentially, the problem that the NETCONF WG was set

I think this is getting done.

> and, unlike you, I see the expertise for that in the NETCONF WG and not
If you mean an update to RFC 6244 would be useful, then I agree

> Tom Petch

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Mar 2017 08:00:25 -0800

On Wed, Mar 1, 2017 at 4:01 AM, Ladislav Lhotka <[email-masked]> wrote:

> Original NETCONF and YANG were limited but (mostly) coherent and, in a
> way, simple and elegant. The recent developments are afterthoughts and
> kitchen sinks that will destroy these qualities.
>
> Instead of rushing with these documents, we should step back and think
> about a new architecture that could consistently support the new
> requirements.
>
>
I think the entire approach to virtual servers is too complicated with
schema-mount.
Instead of keeping the protocol fixed and playing tricks with the data tree,
it might be better to keep the current YANG we have, and enhance
the protocols in order to access virtual servers from the 'real' server.

Lada

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Mar 2017 20:14:06 +0000

Hi Tom,

Such changes fall under the "maintaining" clauses in the NETMOD charter:

  a) Maintaining the data modeling language YANG.  This effort entails
     periodically updating the specification to address new requirements
     as they arise.

  d) Maintaining encodings for YANG modeled data.  This effort entails
     updating encodings already defined by the NETMOD working group 
     (XML and JSON) to accommodate changes to the YANG specification,
     and defining new encodings that are needed, and yet do not fall
     under the charter of any other active IETF working group.

Our charter does not call out every little thing so we don't have to
update it all the time.  Note, the Milestones do need to be updated
frequently, but our WG can do that without IESG approval.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Mar 2017 20:33:10 +0000

> described in RFC6241 and RFC7950 and the publication of another incomplete
> description in the shape of draft-ietf-netmod-revised-datastores will
> likely make things worse.

That's an unfair characterization.  The plan is for revised-datastores to
be a complete definition, as I think you'll appreciate when its update is
posted in a couple weeks.

> specifications, and do see the NETCONF WG as better placed to do it.

Agree that a separate RFC is needed.  Disagree that NETCONF WG is the
better WG for it, for reasons mentioned by Rob.

> I think that the rush to get draft-ietf-netmod-revised-datastores

Rush?  It's been almost a full two years since we started the opstate
discussions.  Admittedly, it mostly occurred on the NETMOD list, maybe
you missed it?

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 2 Mar 2017 03:41:23 +0000

From: Andy Bierman, Wednesday, March 1, 2017 11:00 AM

On Wed, Mar 1, 2017 at 4:01 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

> On 1 Mar 2017, at 10:58, t.petch <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> From: "Juergen Schoenwaelder" <[email-masked]<mailto:[email-masked]>>
> To: "Mehmet Ersue" <[email-masked]<mailto:[email-masked]>>
> Cc: "'Netconf'" <[email-masked]<mailto:[email-masked]>>

I think the entire approach to virtual servers is too complicated with schema-mount.
Instead of keeping the protocol fixed and playing tricks with the data tree,
it might be better to keep the current YANG we have, and enhance
the protocols in order to access virtual servers from the 'real' server.

<Eric>  Both Schema Mount and Peer Mount allow local application referencing to remote information.  Life is easier for application developers as underlying transport protocols are abstracted away.  Abstractions similar to Mount have proven themselves in other contexts.  I am hoping YANG mechanisms move more in this direction.

The answer to whether YANG is only for single device abstraction or also for multi-device abstractions is a fairly core proposition worth disambiguating in the NETMOD charter as well.  Per the thread above, I concur that if we continue down the ‘multi’ path, there may be implications to draft-ietf-netmod-revised-datastores.

Eric

Lada

Andy

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

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Mar 2017 09:31:07 +0100

> will likely make things worse.

You need to tell us why draft-ietf-netmod-revised-datastores is
incomplete and you need to tell us why NETMOD (which did RFC7950) is
not able to complete it while NETCONF is able to complete it.  I see
the same people actively contributing in both WGs. As I said before,
if the split of the WGs becomes an issue, we should merge the two WGs
into one.

At the end, we have to do what makes sense for the industry using
NETCONF, YANG, RESTCONF, ... technology and discussions into which WG
pieces of puzzle belong is just distracting us from doing useful work.

> out is militating against the long term health of NETCONF.

If something is wrong with draft-ietf-netmod-revised-datastores then
by all means contribute to the effort. I doubt that replicating this
work in a second WG will giveus better results.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 02 Mar 2017 13:14:32 +0100

> I think the entire approach to virtual servers is too complicated with

As I see it, schema mount is primarily intended as another tool for
constructing the overall data model from YANG modules, along with
augments and YANG library. 

> the protocols in order to access virtual servers from the 'real'

This sounds more like data mount, not schema mount. Actually, I'd argue
that virtual servers, and in general the "inline" method in the
schema-mount draft, are all about instance data, a part of which happens
to be a new instance of YANG library.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 02 Mar 2017 14:38:12 +0100

"Eric Voit (evoit)" <[email-masked]> writes:

> <Eric> Both Schema Mount and Peer Mount allow local application
> referencing to remote information.  Life is easier for application
> developers as underlying transport protocols are abstracted away.
> Abstractions similar to Mount have proven themselves in other
> contexts.  I am hoping YANG mechanisms move more in this direction.

We should distinguish data mount from schema mount. Currently, getting
the content of YANG library and YANG modules listed therein is
sufficient for constructing the entire schema tree, and schema mount
should work the same, i.e. one shouldn't need to get any instance data
in order to construct the schema.

The confusing point here is that YANG library itself is exposed as state
data, but it should IMO be treated more as meta-data rather than regular
data.

>
> The answer to whether YANG is only for single device abstraction or
> also for multi-device abstractions is a fairly core proposition worth
> disambiguating in the NETMOD charter as well.  Per the thread above, I
> concur that if we continue down the ‘multi’ path, there may be
> implications to draft-ietf-netmod-revised-datastores.

I am not sure that I completely understand what you mean by multi-device
abstraction but I think that device-less abstraction is also worth
considering: apart from the particular client-server session context,
there appears to be a need for specifying (and standardizing) more
complex data models consisting of multiple modules, and augments (that
are used for this purpose e.g. in RFC 8022) are sometimes insufficient.

Lada

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 2 Mar 2017 16:36:34 +0100

True. Timing is important.
We might go for a 7950bis first or publish 7950bis and 6241bis at the same
time with consistent content.

Mehmet

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Tuesday, February 28, 2017 2:38 PM
> To: t.petch <[email-masked]>; Mehmet Ersue <[email-masked]>;
> 'Netconf' <[email-masked]>; 'Benoit Claise' <[email-masked]>
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
> 
> "t.petch" <[email-masked]> writes:
> 
> > 7 is the monster, likely to take years rather than months and I think
> > likely to create confusion, perhaps chaos.
> >
> > I think the rational approach would be to create 7950bis first,
> > removing the NETCONF material into a separate I-D alongside 7950bis,
> > and then merging that into 6241bis if it still seems sensible.  Taking
> > the 60+ bits and pieces out of 7950 is not too bad, what is left still
> > makes sense.
> 
> Right, we need to think hard about a sensible separation of concerns and
> remove, as much as possible, circular dependencies of NETCONF and
> NETMOD documents.
> 
> >
> > Creating a 6241bis that overlaps masses of bits and pieces of 7950 -
> > well, chaos is my expectation.  What use is an XML Example without the
> > YANG that it is an example of and what sense does that YANG snippet
> > make in isolation?  Just how much do we put into 6241bis?
> 
> Yes, I believe there is now no point to pretend that NETCONF is
independent
> of YANG. In fact, some NETCONF operations are ill-defined without the
> additional YANG semantics such as list keys.
> 
> >
> > took to appear but for me, it is the only logical first step and not
> > that difficult one, just tedious to proof-read.
> 
> I agree.
> 
> Lada
> 
> 
> >
> > Tom Petch
> >
> >
> > From: "Mehmet Ersue" <[email-masked]>
> > To: "'Netconf'" <[email-masked]>; "'Benoit Claise'"
> > <[email-masked]>
> > Sent: Monday, February 27, 2017 8:44 PM
> >
> >> Dear NETCONF WG,
> >>
> >>
> >>
> >> please find below the draft charter proposal the co-chairs have
> > prepared for
> >> your review.
> >>
> >> Please send your comments to NETCONF maillist by March 10, 2017.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Mehmet & Mahesh
> >>
> >> Draft Charter for NETCONF WG
> >>
> >> Configuration of networks of devices has become a critical
> >> requirement
> > for
> >> operators in today's highly interconnected networks. Large and small
> >> operators alike have developed their own mechanisms or have used
> > vendor
> >> specific mechanisms to transfer configuration data to and from a
> > device and
> >> to examine device state information which may impact the
> > configuration. Each
> >> of these mechanisms may be different in various aspects, such as
> > session
> >> establishment, user authentication, configuration data exchange, and
> > error
> >> responses.
> >>
> >> The NETCONF protocol (RFC 6241) provides mechanisms to install,
> > manipulate,
> >> and delete the configuration of network devices. NETCONF is based on
> > the
> >> secure transport (SSH is mandatory to implement while TLS is an
> > optional
> >> transport). The NETCONF protocol is data modeling language
> > independent, but
> >> YANG (RFC 7950) is the recommended NETCONF modeling language,
> which
> >> introduces advanced language features for configuration management.
> >>
> >> NETCONF WG recently finalized the development of RESTCONF protocol
> > (RFC
> >> 8040) which provides an interface over HTTPs for accessing data
> > defined in
> >> YANG. RESTCONF is based on the capabilities and uses the datastore
> > concepts
> >> defined in the NETCONF protocol specification. In support of RESTCONF
> > the
> >> YANG-Patch (RFC XXYY) mechanism has been provided for applying
> >> patches
> > to
> >> configuration datastores. The YANG Module Library (RFC 7895) provides
> >> information about all YANG modules used by a network management
> > server.
> >>
> >> Last but not least NETCONF (RFC XXYY) and RESTCONF Call Home (RFC
> > XXYY) have
> >> been developed which enable a server to initiate a secure connection
> > to a
> >> NETCONF or RESTCONF client respectively.
> >>
> >>
> >>
> >> In the current phase of NETCONF's incremental development the
> > workgroup will
> >> focus on following items:
> >>
> >> 1. Finalize the YANG data module for a system-level keystore
> > mechanism, that
> >> can be used to hold onto asymmetric private keys and certificates
> >> that
> > are
> >> trusted by the system advertising support for this module. Based on
> > the
> >> known dependencies this draft has the highest priority for the WG.
> >>
> >> 2. Finalize Server and Client Configuration YANG modules for both
> > NETCONF
> >> and RESTCONF as well as the Client and Server Models for SSH and TLS.
> >>
> >> 3. Finalize the Zero-touch provisioning for NETCONF or RESTCONF-based
> >> Management as a technique to establish a secure network management
> >> relationship between a newly delivered network device configured with
> > just
> >> its factory default settings, and the Network Management System)
> >>
> >> 4. Provide a revised version of RFC 6536 (NETCONF Access Control
> > Model) by
> >> adding support for RESTCONF and the YANG 1.1. constructs like "action"
> > and
> >> the "notification" statements.
> >>
> >> 5. Provide a set of documents enabling advanced
> > notification/subscription
> >> capabilities, which gracefully co-exist in a deployment of RFC 5277.
> > The new
> >> capabilities include e.g. transport independence, multiple dynamic
> >> and configured subscriptions in a transport session. RFC 5277 will be
> > obsoleted
> >> in parallel to the publication of the new document set. Following
> >> specifications will be addressed:
> >>
> >> * Protocol-neutral notification framework, i.e., explaining the
> >> concepts of subscriptions, filters, subscription state notifications,
> >> replay, etc. and defining the associated YANG data model, RPCs, etc.
> >> * Definition of notifications sent over NETCONF and how YANG
> >> notifications are encoded in XML and JSON. Include considerations for
> >> parallel support / implementation compatibility with RFC-5277.
> >> * Definition of notifications sent over RESTCONF and HTTP2 and how
> >> YANG notifications are encoded in XML and JSON. Include specifics of
> >> call-home and heartbeat for subscriptions.
> >> * The subscription and push mechanism for YANG datastores allowing
> >> subscriber applications to request updates from a YANG datastore.
> >>
> >> 7. Provide a revision for the NETCONF and RESTCONF protocols building
> > on the
> >> revised NETCONF datastore concept. Bug fixing will be done and
> > potential
> >> extensions will be added. Provide guidance on how to adapt and use
> > YANG with
> >> NETCONF and RESCONF protocols. NETCONF XML Encoding Rules from
> RFC
> > 7950 will
> >> be moved to RFC6241bis.
> >>
> >> Based on the implementation, deployment experience and
> > interoperability
> >> testing, the WG aims to produce a NETCONF status report in a later
> > stage.
> >> The result may be clarifications for NETCONF RFCs and addressing any
> >> reported errata.
> >>
> >> Milestones
> >>
> >> Mar 2017         WGLC for Zero-touch configuration mechanism
> >>
> >> Apr 2017         Submit Zero-touch configuration to AD/IESG for
> >> consideration as Proposed Standard
> >>
> >>
> >>
> >> May 2017        WGLC for system-level keystore mechanism
> >>
> >> June 2017        Submit keystore mechanism to AD/IESG for
> > consideration as
> >> Proposed Standard
> >>
> >>
> >>
> >> May 2017        WGLC for Server and Client models for NETCONF and
> > RESTCONF
> >>
> >> June 2017        Submit Server and Client Configuration models to
> > AD/IESG
> >> for consideration as Proposed Standard
> >>
> >>
> >>
> >> May 2017        WGLC for Client and Server Models for SSH and TLS
> >>
> >> June 2017        Submit Client and Server Models for SSH and TLS to
> > AD/IESG
> >> for consideration as Proposed Standard
> >>
> >>
> >>
> >> June 2017        WGLC for RFC 6536bis (NETCONF Access Control Model)
> >>
> >> July 2017         Submit RFC 6536bis to AD/IESG for consideration as
> >> Proposed Standard
> >>
> >>
> >>
> >> June 2017        WGLC for advanced Notification/Subscription
> > specifications
> >>
> >> July 2017         Submit Notification/Subscription specifications to
> > AD/IESG
> >> for consideration as Proposed Standard
> >>
> >>
> >>
> >> Aug 2017         WGLC for generic NETCONF datastore concept
> >>
> >> Aug 2017         Submit NETCONF datastore concept to AD/IESG for
> >> consideration as Proposed Standard
> >>
> >>
> >>
> >> Sep 2017          WGLC for NETCONF and RESTCONF bis documents
> >>
> >> Oct 2017          Submit to NETCONF and RESTCONF bis documents AD/IESG
> > for
> >> consideration as Proposed Standard
> >>
> >>
> >>
> >>
> >
> >
> > ----------------------------------------------------------------------
> > --
> > --------
> >
> >

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 2 Mar 2017 16:36:53 +0100

Hi Andy,

I also think a new version obsoleting the current RESTCONF document is not needed.

The bis-documents can be prepared as updates. The WG will decide which way to go.

It is true that we need to plan the schedule based on 7950bis timing.

Mehmet

From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, March 1, 2017 2:45 AM
To: Mehmet Ersue <[email-masked]>
Cc: Netconf <[email-masked]>; Benoit Claise <[email-masked]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Tue, Feb 28, 2017 at 9:01 AM, Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:

....

Oct 2017          Submit to NETCONF and RESTCONF bis documents AD/IESG for consideration as Proposed Standard

 

I am opposed to creating new versions of NETCONF or RESTCONF at this time.

I do not see anything in the charter that cannot be defined in RFCs that update (not obsolete)

the existing protocols.  Both are designed to allow new functionality to be

added and advertised as capabilities.

I should clarify this comment.

NETCONF was last published in June 2011 so it is not unreasonable to

do a new version.  But all protocol features should be on the table.

There is a list (in case you have an important feature to add to the list)

https://github.com/netconf-wg/rfc6241bis/issues

If the scope is just support for revised datastores, then than can go in its own RFC.

If the scope is applying the lessons we have learned since June 2011 to make

NETCONF much better, then 6241bis is appropriate.

RESTCONF was published a month ago so a new version should not be in scope.

Andy

Andy

_______________________________________________
Netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 2 Mar 2017 17:23:57 +0000

> From: Ladislav Lhotka, March 2, 2017 8:38 AM
> > On Wed, Mar 1, 2017 at 4:01 AM, Ladislav Lhotka
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >> On 1 Mar 2017, at 10:58, t.petch
> <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >>
> >> From: "Juergen Schoenwaelder"
> >> <[email-masked]<mailto:j.schoenwaelder@jacobs-u
> >> niversity.de>>
> >>>> draft-ietf-netmod-revised-datastores as its basis. Will be used as
> >>>> a normative reference in protocol specifications.
> >>>
> >>> There is no point in dupliating work in WGs that have a common
> >>> history and a common set of active contributors.
> >>
> >> Juergen
> >>
> >> I am not sure what you are proposing;  Currently, datastores are
> >> poorly described in RFC6241 and RFC7950 and the publication of
> >> another incomplete description in the shape of
> > Instead of keeping the protocol fixed and playing tricks with the data
> > tree, it might be better to keep the current YANG we have, and enhance
> We should distinguish data mount from schema mount. Currently, getting the
> content of YANG library and YANG modules listed therein is sufficient for
> constructing the entire schema tree, and schema mount should work the same,
> i.e. one shouldn't need to get any instance data in order to construct the
> schema.
> 
> The confusing point here is that YANG library itself is exposed as state data, but
> it should IMO be treated more as meta-data rather than regular data.
> 
> >
> abstraction 

An example here would be a data plane box (e.g. BNG) which spins up multiple VMs to handle its control plane session establishment.

An operator doesn't want external systems to individually address every control plane VM.  Rather they want a YANG model for this logical+physical combination.  In this case each VM might use Peer (data) Mount to build a multi-device abstraction.  BTW: doing it this way also allows the same mounted YANG object data to be addressably exposed for each VM without requiring another YANG model to be made.

Eric

> but I think that device-less abstraction is also worth
> considering: apart from the particular client-server session context, there
> appears to be a need for specifying (and standardizing) more complex data
> models consisting of multiple modules, and augments (that are used for this
> purpose e.g. in RFC 8022) are sometimes insufficient.
>
> Lada
> 
> >
> > Eric
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> >
> >> Tom Petch
> >>
> >>> /js
> >>>
> >>> --

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Mar 2017 09:41:30 -0800

On Thu, Mar 2, 2017 at 9:23 AM, Eric Voit (evoit) <[email-masked]> wrote:

> > > I agree, and I would also add draft-ietf-netmod-schema-mount to it (of
> which
> > I am a co-author).
> > >
> schema-
> > mount.
> data, but
> An example here would be a data plane box (e.g. BNG) which spins up
> multiple VMs to handle its control plane session establishment.
>
> An operator doesn't want external systems to individually address every
> control plane VM.  Rather they want a YANG model for this logical+physical
> combination.  In this case each VM might use Peer (data) Mount to build a
> multi-device abstraction.  BTW: doing it this way also allows the same
> mounted YANG object data to be addressably exposed for each VM without
> requiring another YANG model to be made.
>
>
There are plenty of distributed server implementations out there.
Why is the software partitioning of the server implementation interesting
at the modeling level at all?  This is plain old master-agent/sub-agent
stuff.

IMO accessing virtual servers is a protocol issue, similar to named virtual
hosts
in an Apache server. (i.e., lots of entry-points all sharing 1 IP address).

Eric

Andy

> there

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 3 Mar 2017 01:01:10 +0000

<ALEX>, inline

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, March 02, 2017 9:42 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Thu, Mar 2, 2017 at 9:23 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
> "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> writes:
>
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >>
> >>
> >> <[email-masked]<mailto:[email-masked]><mailto:j.schoenwaelder@jacobs-u<mailto:j.schoenwaelder@jacobs-u>
> >> niversity.de<http://niversity.de>>>
> >> To: "Mehmet Ersue" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> >> Cc: "'Netconf'" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>

There are plenty of distributed server implementations out there.
Why is the software partitioning of the server implementation interesting
at the modeling level at all?  This is plain old master-agent/sub-agent stuff.

IMO accessing virtual servers is a protocol issue, similar to named virtual hosts
in an Apache server. (i.e., lots of entry-points all sharing 1 IP address).

Eric

Andy

<ALEX>

First, +1 regarding the need to distinguish schema mount and data mount.  To me, schema mount is fundamentally about definition reuse.  Really, it is about the ability to reuse definitions that would have been ideally defined as a grouping, but weren’t.

Data mount / Peer Mount basically provides an ability to federate a datastore.  For this reason, I think it is very timely to consider data mount while the WG is looking at revising the overall datastore architecture.  This is a lot more than master-agent/sub-agent stuff.  With a sub-agent, the sub-agent is a slave of the master.  This is different here, and there are use cases that will benefit from such a capability – including but not limited to the use case mentioned by Eric.  The current architecture reflects a very “box-centric” view of the world.  The question is if we want to move beyond those constraints.

</ALEX>

> >>> [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]<mailto:[email-masked]>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Mar 2017 10:24:06 +0100

> An operator doesn't want external systems to individually address every control plane VM.  Rather they want a YANG model for this logical+physical combination.  In this case each VM might use Peer…

My question since the very beginning is: Is the idea to run
configuration editing transactions across mount points?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 3 Mar 2017 11:05:53 +0000

> From: Juergen Schoenwaelder, March 3, 2017 4:24 AM
> 
> multi-device abstraction.  BTW: doing it this way also allows the same mounted
> YANG object data to be addressably exposed for each VM without requiring
> another YANG model to be made.
> >
> 
> My question since the very beginning is: Is the idea to run configuration editing
> transactions across mount points?

My position is that there is huge value in read only access.  I have no desire to champion edit operations. 

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Mar 2017 12:52:16 +0100

> My position is that there is huge value in read only access.  I have no desire to champion edit operations. 

Reading data of course has value but then NETCONF has this little
'CONF' in its name...

Anyway, if the peer mount is designed as a read-only access mechanism,
how are the VMs then configured? I suppose there then needs to be a
different addressing mechanism to access the VM's configuration data,
e.g., something Andy was hinting at. Or how does this work?

/js

---

From: t.petch <[email-masked]>
Date: Fri, 3 Mar 2017 12:24:34 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Wednesday, March 01, 2017 8:14 PM

Kent

I was going to be sarcastic but resisted the temptation:-)

I am unable to reconcile those paragraphs with

'NETCONF XML Encoding Rules from RFC 7950 will
be moved to RFC6241bis.'

To me, they are on different planets; one puts XML encoding rules in the
NETCONF WG and the NETCONF RFC, the other places them in the NETMOD WG
and the NETMOD RFC.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Fri, 3 Mar 2017 12:34:20 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Wednesday, March 01, 2017 8:33 PM

> > I am not sure what you are proposing;  Currently, datastores are
poorly
> > described in RFC6241 and RFC7950 and the publication of another
incomplete

Kent

All I have to go on is the published I-D and the comments on the WG list
e.g. last month "templates?  um we don't know what they are!"  (I have
followed URI struggling with templates - it took them years)

So I think you are agreeing with me that based on all I have to go on,
the current description is incomplete and likely to make things worse -
I can but hope things improve:-)

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Mar 2017 14:34:48 +0100

> NETCONF WG and the NETCONF RFC, the other places them in the NETMOD WG

YANG today defines the language plus its data encoding rules into XML
plus NETCONF protocol details that NETCONF did not define (and the
reason is simply that YANG was done after NETCONF and nothing else).

I think the goal is to move the NETCONF protocol details that NETCONF
did not define to the NETCONF specification. Some may want to factor
out the XML encoding out of the YANG specification as well, similar to
how we have JSON as a separate document. On the hand hand this makes
sense, on the other hand it makes it a bit more difficult to write
examples down in the YANG specification (since the examples then
depend on another external specification - or one would have to create
yet another ad-hoc notation (YAAN).

Back to your question, it seems obvious to me that YANG and the XML
encoding rules naturally belong to NETMOD, the 'NETCONF protocol
details that NETCONF did not define' naturally belong to NETCONF.

/js

---

From: "Mehmet Ersue" <[email-masked]>
Date: Fri, 3 Mar 2017 15:33:58 +0100

> Back to your question, it seems obvious to me that YANG and the XML
encoding rules naturally belong to NETMOD, the 'NETCONF protocol details
that NETCONF 
> did not define' naturally belong to NETCONF.

Basically it is our aim to make the YANG language specification generally
applicable to all protocols and to put protocol-specific details into the
protocol specifications.

Mehmet

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, March 3, 2017 2:35 PM
> To: t.petch <[email-masked]>
> Cc: Kent Watsen <[email-masked]>; Mehmet Ersue
> <[email-masked]>; 'Netconf' <[email-masked]>; 'Benoit Claise'
> <[email-masked]>
> > > > 7 is a monster because of the XML encoding rules, not because of
> > > > the revised datastore concepts.  And datastores, as you say, are
> > > > more important - revising the XML encoding rules is cosmetic, not
> > > > needed technically and, as I said, only make sense when the NETMOD
> > > > WG has
> > done
> > > > its bit; and the revised charter being discussed on the NETMOD
> > > > list makes no mention of this work.
> > > >
> > 'NETCONF XML Encoding Rules from RFC 7950 will be moved to
> > RFC6241bis.'
> >
> > To me, they are on different planets; one puts XML encoding rules in
> > the NETCONF WG and the NETCONF RFC, the other places them in the
> > NETMOD WG and the NETMOD RFC.
> >
> 
> YANG today defines the language plus its data encoding rules into XML plus
> NETCONF protocol details that NETCONF did not define (and the reason is
> simply that YANG was done after NETCONF and nothing else).
> 
> I think the goal is to move the NETCONF protocol details that NETCONF did
> not define to the NETCONF specification. Some may want to factor out the
> XML encoding out of the YANG specification as well, similar to how we have
> JSON as a separate document. On the hand hand this makes sense, on the
> other hand it makes it a bit more difficult to write examples down in the
> YANG specification (since the examples then depend on another external
> specification - or one would have to create yet another ad-hoc notation
> (YAAN).
> 
> encoding rules naturally belong to NETMOD, the 'NETCONF protocol details
> that NETCONF did not define' naturally belong to NETCONF.
> 
> /js
> 
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Mar 2017 17:39:30 +0100

"Eric Voit (evoit)" <[email-masked]> writes:

> An operator doesn't want external systems to individually address
> every control plane VM.  Rather they want a YANG model for this
> logical+physical combination.  In this case each VM might use Peer
> (data) Mount to build a multi-device abstraction.  BTW: doing it this
> way also allows the same mounted YANG object data to be addressably
> exposed for each VM without requiring another YANG model to be made.

I think this can be mostly accomplished with the "inline" approach of
schema mount (which in fact is a data mount and probably very similar to
the concept of peer mount).

IMO, what we are missing in terms of data modelling is really something
like "device-less abstraction". I'd like to have a data modelling
language or framework that would allow for saying: this is the complete
data model, go and implement it (or let tools generate some code from
it). Paradoxically, YANG isn't very good at this: we can write YANG
modules but in order to combine them into coherent wholes we need to
rely on some device to provide state data. Even with augments we have to
assume that any device implementing an augmenting module will also
implement the augmented module.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Mar 2017 17:54:48 +0100

> configuration editing transactions across mount points?

I believe the general answer has to be yes. For example, the
NI model requires it because there will be only one server for
configuration data of the LNE and all NIs.

That's why Martin proposed not to use any data as mount points.

In some cases though it may be useful to mount config=true data as
read-only, and schema-mount-04 will provide some means for doing so.

Lada

---

From: t.petch <[email-masked]>
Date: Fri, 3 Mar 2017 17:14:13 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, March 03, 2017 1:34 PM

the
> > > > technically and, as I said, only make sense when the NETMOD WG
has
> > > > its bit; and the revised charter being discussed on the NETMOD
list
the
> details that NETCONF did not define' naturally belong to NETCONF.

Makes sense.

I am reminded that in the latter days of 6020bis the point was made that
the terminology therein was inconsistent, sometimes NETCONF XML and
sometimes XML, an inconsistency which has been carried across to
RFC7950.

Really, the use of XML has nothing to do with NETCONF and I am not sure
that it is even an encoding, more a translation from DDL to GML, which
could be used by any transport.

So the word NETCONF should be expunged from RFC7950 and where it conveys
meaning, and I am suggesting that it often does not, then that part
should become part of a NETCONF I-D.  If I understand Juergen aright,
then this covers the NETCONF protocol details, such as

5.6.4.  Announcing Conformance Information in NETCONF

7.5.8.  NETCONF <edit-config> Operations

8.3.  NETCONF Constraint Enforcement Model

15.  NETCONF Error Responses for YANG-Related Errors

but not

urn ....netconf

which 7950bis would still need.

I would like 7950bis to still cover the create/delete/update issues,
that is I am assuming that the structures defined by 7950bis would still
be accessed by a protocol with those capabilities, just that it may not
be NETCONF, but I see that as more debatable although given such as
'ordered-by-user' I think it hard to eliminate that discussion entirely

This is not what I had in mind when this thread started.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Fri, 3 Mar 2017 17:18:54 +0000

----- Original Message -----
From: "Mehmet Ersue" <[email-masked]>
Sent: Friday, March 03, 2017 2:33 PM

> encoding rules naturally belong to NETMOD, the 'NETCONF protocol
details
> applicable to all protocols and to put protocol-specific details into
the

See my response to Juergen; I agree with you but I define XML as not
being a protocol and so XML would remain; and I think that YANG will
have to say something about operations on the data it defines, just that
they are defined as an abstract 'create', 'delete' etc and not as the
set that NETCONF currently offers.

Tom Petch

> > Cc: Kent Watsen <[email-masked]>; Mehmet Ersue

<snip>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 3 Mar 2017 17:41:58 +0000

> set that NETCONF currently offers.
FWIW, this is the block
"      Common protocol abstraction
(that all YANG protocols should conform to). "

That I was referring to in the diagram that I gave previously, although 
I was suggesting that should belong in NETCONF WG rather than in YANG.

Rob

---

From: Robert Wilton <[email-masked]>
Date: Fri, 3 Mar 2017 17:45:13 +0000

> implement the augmented module.
Could this be solved with YANG packages?  I.e. not only listing a set of 
modules, but also listing the set of modules that would be expected to 
be implemented for each of the mount points specified in those modules?

Rob

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 3 Mar 2017 18:27:29 +0000

Hi Jurgen,

I responded to the earlier message without seeing this. 

Quick comment below, <ALEX>

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 03, 2017 3:52 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; Andy Bierman <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Fri, Mar 03, 2017 at 11:05:53AM +0000, Eric Voit (evoit) wrote:
> > > every
> > control plane VM.  Rather they want a YANG model for this 
> > (data) Mount to build a multi-device abstraction.  BTW: doing it 
> > this way also allows the same mounted YANG object data to be 
> > addressably exposed for each VM without requiring another YANG model to be made.
> > >
> > 

Reading data of course has value but then NETCONF has this little 'CONF' in its name...

<ALEX>This does not prevent network to have operational state (and applied datastore) in its scope... </ALEX>

Anyway, if the peer mount is designed as a read-only access mechanism, how are the VMs then configured? I suppose there then needs to be a different addressing mechanism to access the VM's configuration data, e.g., something Andy was hinting at. Or how does this work?

<ALEX> The authoritative owner is still the mount server, i.e. the system from which information is mounted.  I agree with Eric, no desire to champion cross-network edit operations/transaction, and still a lot of value in having read access from other systems.  </ALEX>

/js

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 3 Mar 2017 18:20:51 +0000

The use cases we have in mind are related to providing a view.  So, no, it would not be required to provide edit transaction support across mount points.  Clearly the attempt to do so would be challenging and raise issues that will be challenging to address in generality.   

A solution that stops short of such generality will still be useful.  Clearly, clients will be aware what information is mounted - that definition is part of the model, so it is feasible to define and treat mounted information as read-only and excluded from locks.  

Quite possibly it makes sense to treat it akin to the revised datastores concept of the applied datastore.  Come to think of it, it may be a good idea to tie it to that - e.g. allow mount in the context of an applied datastore, but not for a candidate/startup/running.  

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 03, 2017 1:24 AM
To: Alexander Clemm <[email-masked]>
Cc: Andy Bierman <[email-masked]>; Eric Voit (evoit) <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

> An operator doesn't want external systems to individually address every control plane VM.  Rather they want a YANG model for this logical+physical combination.  In this case each VM might use Peer…

My question since the very beginning is: Is the idea to run configuration editing transactions across mount points?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 3 Mar 2017 18:41:06 +0000

> From: Juergen Schoenwaelder, March 3, 2017 6:52 AM
> 
> Anyway, if the peer mount is designed as a read-only access mechanism, how
> are the VMs then configured? I suppose there then needs to be a different
> addressing mechanism to access the VM's configuration data, e.g., something
> Andy was hinting at. Or how does this work?

There are lots of ways to approach this problem, but for this particular use case often it is unnecessary.   Configuration attempts from outside the box are often supposed to be global or VM agnostic across the box.  So each of the VMs then simply Peer Mount the global configuration data.  This eliminates lots of error-cases as it becomes very hard to push configuration data out of synch as you aren't exposing ways to do this.

Eric

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 3 Mar 2017 18:44:06 +0000

-----Original Message-----
...
> exposed for each VM without requiring another YANG model to be made.

I think this can be mostly accomplished with the "inline" approach of schema mount (which in fact is a data mount and probably very similar to the concept of peer mount).

<ALEX> While schema mount was triggered by and in some way originated from earlier discussions surrounding peer mount, they are not the same.  They accomplish something different.  With schema mount, you can reuse / incorporate earlier definitions.  It is about extending definitions and being able to reuse models defined earlier, but how to implement and populate the data is up to the implementation.  With peer-mount, the population of the data is very much part of the concept and can be inherently provided by the framework (as the mount target and authoritative source of the data will be managed as part of the mountpoint).  
</ALEX>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Mar 2017 23:51:39 +0100

> There are lots of ways to approach this problem, but for this particular use case often it is unnecessary.   Configuration attempts from outside the box are often supposed to be global or VM agnost…

Which particular use case are we providing a solution for?

I understand edit transactions crossing mount points is not needed for
the particular use case. Does your particular use case support editing
transactions within a mount point? Or is your particular use case a
completely read-only mount and applications have to use an entirely
different access mechanism to make any changes? Or is the particular
use case applications that never change anything?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 4 Mar 2017 16:41:24 +0000

Hi Juergen,

On your editing question below: all use cases I have been involved with read remote data, and as a result change local data.

If you want more specifics, requirements and some use cases are in Section 4 of the draft:  
https://tools.ietf.org/html/draft-voit-netmod-yang-mount-requirements-00
the particular BNG hosting of multiple VM are not represented in this draft though, but I am happy to rev this draft to add it if WG members are interested in evolving the requirements further.

Eric

> Sent: Friday, March 3, 2017 5:52 PM
> To: Eric Voit (evoit) <[email-masked]>> Cc: Alexander Clemm <[email-masked]>; ierman
> <[email-masked]>; Netconf <[email-masked]>
> > > > > logical+physical combination.  In this case each VM might use
> > > > > logical+Peer
> > > > > addressably exposed for each VM without requiring another YANG
> > > > > model to
> > > be made.
> > > > > >
> > > > >
> > > > My position is that there is huge value in read only access.  I
> > > > have no desire to
> > > champion edit operations.
> > > >
> > >
> > > Anyway, if the peer mount is designed as a read-only access
> > > mechanism, how are the VMs then configured? I suppose there then
> > > needs to be a different addressing mechanism to access the VM's
> > > configuration data, e.g., something Andy was hinting at. Or how does this
> work?
> >
> > There are lots of ways to approach this problem, but for this particular use
> case often it is unnecessary.   Configuration attempts from outside the box are
> often supposed to be global or VM agnostic across the box.  So each of the VMs
> then simply Peer Mount the global configuration data.  This eliminates lots of
> error-cases as it becomes very hard to push configuration data out of synch as
> you aren't exposing ways to do this.
> >
> 
> I understand edit transactions crossing mount points is not needed for the
> particular use case. Does your particular use case support editing transactions
> within a mount point? Or is your particular use case a completely read-only
> mount and applications have to use an entirely different access mechanism to
> make any changes? Or is the particular use case applications that never change
> anything?
> 
> /js
> 
> --

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 10:01:42 -0500

Mehmet: 

These are clarifying question - not requests. 

Do the items #6 and #7 on the charter include revising the NETCONF and
RESTCONF to serve as a control plane protocol that interacts with the I2RS
control plane data store supporting the ephemeral datastore?   If so, based
on the WGs comments it seems key players (Andy Bierman for RESTCONF and a
group of players for NETCONF) do not want this work to be done in the
NETCONF WG.   Do I understand the sense of the mail list?  

Sue Hares 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

> > > > more important - revising the XML encoding rules is cosmetic, 
> > > > not needed technically and, as I said, only make sense when the 
> > > > NETMOD WG has
> > done

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 10:09:53 -0500

Alex and Juergen: 

Clarifying question - Do I understand that Juergen does not want
RESTCONF/NETCONF to be querying anything but: 
a) the applied configuration part of the applied data store, and 
b) the operational state resulting from schema's that configuration work on?

Sue Hares

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Friday, March 3, 2017 1:27 PM
To: Juergen Schoenwaelder; Eric Voit (evoit)
Cc: Netconf
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Hi Jurgen,

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Friday, March 03, 2017 3:52 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; Andy Bierman

> My position is that there is huge value in read only access.  I have no
desire to champion edit operations. 

Reading data of course has value but then NETCONF has this little 'CONF' in
its name...

<ALEX>This does not prevent network to have operational state (and applied
datastore) in its scope... </ALEX>

<ALEX> The authoritative owner is still the mount server, i.e. the system
from which information is mounted.  I agree with Eric, no desire to champion
cross-network edit operations/transaction, and still a lot of value in
having read access from other systems.  </ALEX>

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Mar 2017 08:24:53 -0800

> NETCONF WG.   Do I understand the sense of the mail list?
My position is that I2RS features can be done in its own RFC without
republishing the RESTCONF RFC.  Since this functionality is
optional-to-implement, a new protocol version is not required.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 11:27:14 -0500

Andy: 

Thank you for the clarification.  Since this is an Add-on and not focused on the base specification, where should the Add-on specification be worked on?  I2RS WG with final cross-review in NETCONF?   It seems that NETCONF has lots of other work on the list.  

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 11:25 AM
To: Susan Hares
Cc: Mehmet Ersue; Juergen Schoenwaelder; t.petch; Netconf
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 7 Mar 2017 18:34:20 +0100

Hi Sue,

providing add-ons which don’t require republishing of RESTCONF-8040 would be indeed important.

I don’t mind if add-ons to RESTCONF specific to I2RS are done in I2RS.

However forcing serious reviews early and publishing them in NETCONF would be my preference. 

In any case we need I2RS people working on it.

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[email-masked]>
Cc: 'Mehmet Ersue' <[email-masked]>; 'Juergen Schoenwaelder' <[email-masked]>; 't.petch' <[email-masked]>; 'Netconf' <[email-masked]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Andy: 

Sue 

 

On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[email-masked] <mailto:[email-masked]> > wrote:

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- <mailto:j.schoenwaelder@jacobs-> 
> university.de <http://university.de> ]
> To: t.petch <[email-masked] <mailto:[email-masked]> >
> Cc: Kent Watsen <[email-masked] <mailto:[email-masked]> >; Mehmet Ersue
> <[email-masked] <mailto:[email-masked]> >; 'Netconf' <[email-masked] <mailto:[email-masked]> >; 'Benoit Claise'
> <[email-masked] <mailto:[email-masked]> >
> > From: "Kent Watsen" <[email-masked] <mailto:[email-masked]> >

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 13:35:47 -0500

Mehmet:

Sounds like a good plan to do the RESTCONF additions for I2RS in I2RS.  

How do we make this official?   Should we do the same for NETCONF additions for I2RS?  

Sue 

From: Mehmet Ersue [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 12:34 PM
To: 'Susan Hares'; 'Andy Bierman'
Cc: 'Juergen Schoenwaelder'; 't.petch'; 'Netconf'
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Hi Sue,

BR,

Mehmet

Andy: 

Sue 

 

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 7 Mar 2017 21:15:22 +0100

Hi Sue,

I personally prefer to publish such NC/RC add-ons in NETCONF WG as they belong together.

I would like to suggest to discuss on the maillist and let NETCONF WG decide in Chicago.

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 7:36 PM
To: 'Mehmet Ersue' <[email-masked]>; 'Andy Bierman' <[email-masked]>
Cc: 'Juergen Schoenwaelder' <[email-masked]>; 't.petch' <[email-masked]>; 'Netconf' <[email-masked]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet:

Sue 

Hi Sue,

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[email-masked] <mailto:[email-masked]> >
Cc: 'Mehmet Ersue' <[email-masked] <mailto:[email-masked]> >; 'Juergen Schoenwaelder' <[email-masked] <mailto:[email-masked]> >; 't.petch' <[email-masked] <mailto:[email-masked]> >; 'Netconf' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Andy: 

Sue 

 

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

---

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Mar 2017 23:57:48 +0000

I agree with Mehmet, any changes to the NC/RC protocols should be done in the NETCONF WG.

K.

On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Sue,

BR,
Mehmet

Mehmet:

Sue

Hi Sue,

BR,
Mehmet

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
Cc: 'Mehmet Ersue' <[email-masked]<mailto:[email-masked]>>; 'Juergen Schoenwaelder' <[email-masked]<mailto:[email-masked]>>; 't.petch' <[email-masked]<mailto:[email-masked]>>; 'Netconf' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Andy:

Sue

On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Mehmet:

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-<mailto:j.schoenwaelder@jacobs->
> university.de<http://university.de>]
> To: t.petch <[email-masked]<mailto:[email-masked]>>
> Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>; Mehmet Ersue
> <[email-masked]<mailto:[email-masked]>>; 'Netconf' <[email-masked]<mailto:[email-masked]>>; 'Benoit Claise'
> <[email-masked]<mailto:[email-masked]>>
> > From: "Kent Watsen" <[email-masked]<mailto:[email-masked]>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Mar 2017 13:40:48 +0100

Sue:

I do not understand your question. Neither a) nor b) make sense to me
nor do I see how any of these relate to the discussion about mounts.

/js

---

From: t.petch <[email-masked]>
Date: Thu, 9 Mar 2017 12:12:32 +0000

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Friday, March 03, 2017 5:41 PM

> >> applicable to all protocols and to put protocol-specific details
into

Robert

It has taken me a while to work out what you mean but now I have, I
disagree!

You seem to place data(stores) at the heart of things, the root from
which all else flows.  I think that this can work with application
software in a stable, secure, delay-less environment where nothing ever
goes wrong (a mobile phone app perhaps!).

Network management is different;  the failing network is both the
subject under consideration and an integral part of the solution.  The
operator has to use the failing network to find out what is failing and
what might be done about it and then use the failing network to convey
changes to the failing component of the network.  SNMP recognised this
but I am not sure the NETCONF/YANG do - after all, their focus is on
configuration, before things start going wrong.

I see revised-datastores as an attempt to fix this but one that will
fail, in the sense that it cannot go far enough; what may be needed is a
paradigm shift in Computer Science so a server can say that the model it
has been given cannot reflect reality but here is a better one freshly
created for the client to use!

I don't see that happening just yet so revised-datastores will have to
do but I think it wrong to make that central - it will not be close
enough to reality.

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Thu, 9 Mar 2017 15:29:14 +0000

Hi Tom,

> goes wrong (a mobile phone app perhaps!).
Yes, I definitely want to place accurate and meaningful data at the 
heart of it.

As I see it:
- YANG is the schema for that data.
- Datastores are really just views on data, bound to the schema and the 
data life cycle
- Protocols are mechanism to access and modify that data, aided by the 
schema & datastores.

I really hope that the solution that we are constructing will work well 
for systems that have real delays, unreliable communications, and 
potentially buggy software.  Certainly, that is my goal ... Some of this 
will need protocol assistance.

> configuration, before things start going wrong.
I don't know the history, but my perception is that NETCONF/YANG was 
focused on config because that is the part of SNMP that failed to gain 
traction in the industry.  As NETCONF/YANG gains traction, it seems 
reasonable to want to fix the operational state aspect of it that seems 
somewhat incomplete today.

> created for the client to use!

So, I think that that issue that you are raising here is that a device 
might not be able to accurately populate the schema being used for the 
operational state datastore.  The latest (unpublished) datastores draft 
states that even all values (including defaults) are returned in the 
operational state datastore.  I.e. everything is explicit, meaning that 
if a device cannot return the correct value for a node then it has the 
choice of returning no value at all.

In terms of dynamic schema, devices can already define their own custom 
schema and augmentations that can carry any extra vendor/device specific 
data that cannot be readily mapped back into the standard schema.  The 
problem here is that these schema are non standard (between vendors 
and/or devices) and hence much harder for automated clients to use.  I 
think that there is also a scope question of these additional vendor 
schema, given that a lot of the data is likely to be verbose, possibly 
expensive to obtain, and perhaps more diagnostics orientated.

> do but I think it wrong to make that central - it will not be close
It will be central in the sense that YANG models will either be built 
assuming that it exists, or that it doesn't.  I don't think that you can 
really have well constructed, fully useful, YANG models where the 
operational state datastore is optional.

I don't think that the datastores draft is going to be a silver bullet 
that solves all problems, but if the solution gains traction then I do 
think that it will give a step improvement to making it easier to manage 
network devices in an automated and robust way.

Regards,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Mar 2017 09:56:06 -0800

> configuration, before things start going wrong.
I don't know if NETCONF or RESTCONF will ever be suitable as a replacement
for SNMP wrt/ functioning in a broken network. TCP and SSH need to function
first, before any network management can start. That's why some of us are
looking
at CoMI as a replacement for SNMP.

NETCONF is designed to be a resource hog running on a stable network.

> created for the client to use!

This might work in an open system, but I have not seen this trend in
routers.
Our server can automatically load/unload modules or module bundles
at runtime, but vendors are not really using it because it doesn't fit
their QA model.
They want to test monolithic images, not modular systems that can be
changed by
the operator at run-time.

The DS work takes care of some corner cases, but does nothing to make
NETCONF
100% suitable for network management.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 11 Mar 2017 08:29:40 -0500

Robert: 

Pulling your comment to the front for ease of reference.  You stated: 
 
- YANG is the schema for that data.
- Datastores are really just views on data, bound to the schema and the data
life cycle
- Protocols are mechanism to access and modify that data, aided by the
schema & datastores.

Can you explain what you mean by "bound to the schema" and "data life
cycle"? 

My understanding from the revised datastores draft was that control plane
datastores are:

1) form a place in which to mount modules 
2) can have global characteristics [E.g. I2RS control plane datastore is
ephemeral] 
3) have their own validation rules  
4) can be tracked by meta-data when mixed with other datastores for
installation - which the applied datastore tracks. 
5) protocols are mechanisms to access/modify data - aided by schema and
datastores, but the 
protocols (NETCONF and RESTCONF) may need augmentation to support other
datastores 
(E.g. "get data <datatstore>") 

Sue 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Thursday, March 9, 2017 10:29 AM
To: t.petch; 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Hi Tom,

On 09/03/2017 12:12, t.petch wrote:
> software in a stable, secure, delay-less environment where nothing 
> ever goes wrong (a mobile phone app perhaps!).
Yes, I definitely want to place accurate and meaningful data at the heart of
it.

As I see it:
- YANG is the schema for that data.
- Datastores are really just views on data, bound to the schema and the data
life cycle
- Protocols are mechanism to access and modify that data, aided by the
schema & datastores.

I really hope that the solution that we are constructing will work well for
systems that have real delays, unreliable communications, and potentially
buggy software.  Certainly, that is my goal ... Some of this will need
protocol assistance.

> operator has to use the failing network to find out what is failing 
> and what might be done about it and then use the failing network to 
> convey changes to the failing component of the network.  SNMP 
> recognised this but I am not sure the NETCONF/YANG do - after all, 
> their focus is on configuration, before things start going wrong.
I don't know the history, but my perception is that NETCONF/YANG was focused
on config because that is the part of SNMP that failed to gain traction in
the industry.  As NETCONF/YANG gains traction, it seems reasonable to want
to fix the operational state aspect of it that seems somewhat incomplete
today.

> fail, in the sense that it cannot go far enough; what may be needed is 
> a paradigm shift in Computer Science so a server can say that the 
> model it has been given cannot reflect reality but here is a better 
> one freshly created for the client to use!

So, I think that that issue that you are raising here is that a device might
not be able to accurately populate the schema being used for the operational
state datastore.  The latest (unpublished) datastores draft states that even
all values (including defaults) are returned in the operational state
datastore.  I.e. everything is explicit, meaning that if a device cannot
return the correct value for a node then it has the choice of returning no
value at all.

In terms of dynamic schema, devices can already define their own custom
schema and augmentations that can carry any extra vendor/device specific
data that cannot be readily mapped back into the standard schema.  The
problem here is that these schema are non standard (between vendors and/or
devices) and hence much harder for automated clients to use.  I think that
there is also a scope question of these additional vendor schema, given that
a lot of the data is likely to be verbose, possibly expensive to obtain, and
perhaps more diagnostics orientated.

I don't think that the datastores draft is going to be a silver bullet that
solves all problems, but if the solution gains traction then I do think that
it will give a step improvement to making it easier to manage network
devices in an automated and robust way.

Regards,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Sat, 11 Mar 2017 21:40:15 +0000

Hi Sue,

> Can you explain what you mean by "bound to the schema" and "data life
By "bound to the schema", I mean nodes marked as "config: true" in YANG 
exist in the schema associated with configuration datastores, but nodes 
marked as "config: false" don't exist in the schema associated with 
configuration datastores.  The operational state datastore contains both 
all nodes defined in the YANG modules (both config: true and config: false).

Likewise, if I2RS defined an "i2rs:ephemeral" extension to YANG, then 
that statement would help indicate which schema nodes are associated 
with the I2RS datastore(s).

By "data life cycle", I mean that:
  - the running configuration datastore (basically) represents the 
configuration sent to the device by the operators (via standard 
NETCONF/RESTCONF mechanisms).  For various reasons nodes that exist in 
the datatree in the running datastore might not exist in the other 
datastores (e.g. inactive config, missing hardware, changed by dynamic 
configuration).
  - the intended datastore is basically running configuration with 
inactive config removed and template expansion performed.  It is the 
intended datastore where validation occurs.
  - the dynamic datastore(s) contain the configuration that has been 
programmed by dynamic protocols (such as I2RS).
  - the operational state datastore contains the actual current 
operational values used by the device.  There are several reasons why 
the data nodes in this datastore may not match those in running 
(including, but not limited to: time delay in acting on the intended 
configuration, missing hardware, system controlled resources, 
configuration that was learned via a dynamic datastore, system failures 
that mean that the operational value doesn't match the desired 
configuration).

So, in short I mean the existence and value of a given data node may 
differ between the different datastores.

> 1) form a place in which to mount modules
I think that mount can logically apply in other datastores as well.

> 2) can have global characteristics [E.g. I2RS control plane datastore is
Yes, this is fine.

> 3) have their own validation rules
Yes, this should be OK.

> installation - which the applied datastore tracks.
Yes.  Really, it is the operational state datastore that tracks this, 
and the applied datastore just represented a view onto the operational 
state datastore.  I.e. it was defined as the subset of operational that 
have origin=static or origin=dynamic.  The datastore draft diagram 
showing intended and control plane datatstores feeding into the applied 
datastore and then operational-state datastore is a bit misleading.  We 
are trying to simplify this diagram to make it clearer.

> (E.g. "get data <datatstore>")
Yes, this is right.

Thanks,
Rob

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 11 Mar 2017 18:00:27 -0500

Robert: 

Thank you for your response.   It was very helpful.  

Sue Hares 

-----Original Message-----
From: Robert Wilton [mailto:[email-masked]] 
Sent: Saturday, March 11, 2017 4:40 PM
To: Susan Hares; 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Hi Sue,

On 11/03/2017 13:29, Susan Hares wrote:
> - Datastores are really just views on data, bound to the schema and 
> the data life cycle
By "bound to the schema", I mean nodes marked as "config: true" in YANG
exist in the schema associated with configuration datastores, but nodes
marked as "config: false" don't exist in the schema associated with
configuration datastores.  The operational state datastore contains both all
nodes defined in the YANG modules (both config: true and config: false).

Likewise, if I2RS defined an "i2rs:ephemeral" extension to YANG, then that
statement would help indicate which schema nodes are associated with the
I2RS datastore(s).

By "data life cycle", I mean that:
  - the running configuration datastore (basically) represents the
configuration sent to the device by the operators (via standard
NETCONF/RESTCONF mechanisms).  For various reasons nodes that exist in the
datatree in the running datastore might not exist in the other datastores
(e.g. inactive config, missing hardware, changed by dynamic configuration).
  - the intended datastore is basically running configuration with inactive
config removed and template expansion performed.  It is the intended
datastore where validation occurs.
  - the dynamic datastore(s) contain the configuration that has been
programmed by dynamic protocols (such as I2RS).
  - the operational state datastore contains the actual current operational
values used by the device.  There are several reasons why the data nodes in
this datastore may not match those in running (including, but not limited
to: time delay in acting on the intended configuration, missing hardware,
system controlled resources, configuration that was learned via a dynamic
datastore, system failures that mean that the operational value doesn't
match the desired configuration).

So, in short I mean the existence and value of a given data node may differ
between the different datastores.

>
> My understanding from the revised datastores draft was that control 
> plane datastores are:
>

>   
> 2) can have global characteristics [E.g. I2RS control plane datastore 
> is ephemeral]
Yes, this is fine.

Yes, this should be OK.

> installation - which the applied datastore tracks.
Yes.  Really, it is the operational state datastore that tracks this, and
the applied datastore just represented a view onto the operational state
datastore.  I.e. it was defined as the subset of operational that have
origin=static or origin=dynamic.  The datastore draft diagram showing
intended and control plane datatstores feeding into the applied datastore
and then operational-state datastore is a bit misleading.  We are trying to
simplify this diagram to make it clearer.

>   
> 5) protocols are mechanisms to access/modify data - aided by schema 
> and datastores, but the protocols (NETCONF and RESTCONF) may need 
> augmentation to support other datastores (E.g. "get data 
> <datatstore>")
Yes, this is right.

Thanks,
Rob

>>>> See my response to Juergen; I agree with you but I define XML as 
>>>> not being a protocol and so XML would remain; and I think that YANG 
>>>> will have to say something about operations on the data it defines, 
>>>> just
>> that
> - Datastores are really just views on data, bound to the schema and 
> the data life cycle
> I really hope that the solution that we are constructing will work 
> well for systems that have real delays, unreliable communications, and 
> potentially buggy software.  Certainly, that is my goal ... Some of 
> this will need protocol assistance.
>
>> subject under consideration and an integral part of the solution.  
>> The operator has to use the failing network to find out what is 
>> failing and what might be done about it and then use the failing 
>> network to convey changes to the failing component of the network.  
>> SNMP recognised this but I am not sure the NETCONF/YANG do - after 
>> all, their focus is on configuration, before things start going wrong.
> reasonable to want to fix the operational state aspect of it that 
> seems somewhat incomplete today.
>
>> fail, in the sense that it cannot go far enough; what may be needed 
>> is a paradigm shift in Computer Science so a server can say that the 
> operational state datastore.  The latest (unpublished) datastores 
> draft states that even all values (including defaults) are returned in 
> the operational state datastore.  I.e. everything is explicit, meaning 
> that if a device cannot return the correct value for a node then it 
> has the choice of returning no value at all.
>
> In terms of dynamic schema, devices can already define their own 
> custom schema and augmentations that can carry any extra vendor/device 
> specific data that cannot be readily mapped back into the standard 
> schema.  The problem here is that these schema are non standard 
> (between vendors and/or
> devices) and hence much harder for automated clients to use.  I think 
> that there is also a scope question of these additional vendor schema, 
> given that a lot of the data is likely to be verbose, possibly 
>> I don't see that happening just yet so revised-datastores will have 
>> to do but I think it wrong to make that central - it will not be 
>> close enough to reality.
> assuming that it exists, or that it doesn't.  I don't think that you 
> can really have well constructed, fully useful, YANG models where the 
> think that it will give a step improvement to making it easier to 
> manage network devices in an automated and robust way.
>
> Regards,
> Rob
>
>
>> Tom Petch
>>
>>> Rob
>>>
>>>> Tom Petch
>>>>
>>>>> Mehmet
>>>>>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Mar 2017 16:48:39 +0100

> I agree with Mehmet, any changes to the NC/RC protocols should be done 
+1.

Regards, Benoit
>
> K.
>
> On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue" 
> <[email-masked] <mailto:[email-masked]> on behalf 
> of [email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Sue,
>
> *From:*Susan Hares [mailto:[email-masked]]
> *Sent:* Tuesday, March 7, 2017 7:36 PM
> *To:* 'Mehmet Ersue' <[email-masked]>; 'Andy Bierman' 
> <[email-masked]>
> *Cc:* 'Juergen Schoenwaelder' <[email-masked]>; 
> 't.petch' <[email-masked]>; 'Netconf' <[email-masked]>
> *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
> Mehmet:
>
> *From:*Mehmet Ersue [mailto:[email-masked]]
> *Sent:* Tuesday, March 7, 2017 12:34 PM
> *To:* 'Susan Hares'; 'Andy Bierman'
> *Cc:* 'Juergen Schoenwaelder'; 't.petch'; 'Netconf'
> *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
> Hi Sue,
>
> *From:*Susan Hares [mailto:[email-masked]]
> *Sent:* Tuesday, March 7, 2017 5:27 PM
> *To:* 'Andy Bierman' <[email-masked] <mailto:[email-masked]>>
> *Cc:* 'Mehmet Ersue' <[email-masked] <mailto:[email-masked]>>; 
> 'Juergen Schoenwaelder' <[email-masked] 
> <mailto:[email-masked]>>; 't.petch' 
> <[email-masked] <mailto:[email-masked]>>; 'Netconf' 
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
> Andy:
>
> Thank you for the clarification. Since this is an Add-on and not 
> focused on the base specification, where should the Add-on 
> specification be worked on?  I2RS WG with final cross-review in 
> NETCONF?  It seems that NETCONF has lots of other work on the list.
>
> Sue
>
> *From:*Andy Bierman [mailto:[email-masked]]
> *Sent:* Tuesday, March 7, 2017 11:25 AM
> *To:* Susan Hares
> *Cc:* Mehmet Ersue; Juergen Schoenwaelder; t.petch; Netconf
> *Subject:* Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
>     From: Netconf [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Mehmet Ersue
>     into the
>     <mailto:j.schoenwaelder@jacobs->
>     > university.de <http://university.de>]
>     > To: t.petch <[email-masked] <mailto:[email-masked]>>
>     > Cc: Kent Watsen <[email-masked]
>     <mailto:[email-masked]>>; Mehmet Ersue
>     > <[email-masked] <mailto:[email-masked]>>; 'Netconf'
>     <[email-masked] <mailto:[email-masked]>>; 'Benoit Claise'
>     > <[email-masked] <mailto:[email-masked]>>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Mon, 20 Mar 2017 17:32:41 +0100

Dear All,

based on the recent discussion and proposals please find below the updated
charter proposal for NETCONF WG.

Please comment before March 24, 2017.

Following Benoit's support the I2RS-related additions have been added as a
separated item.

Being dependent on netmod-revised-datastores point 6 and 7 have been defined
as a goal without a deadline.

Mehmet

Network Configuration (netconf)

-------------------------------

Charter

Current Status: Active

Chairs:

     Mahesh Jethanandani <[email-masked]>

    Mehmet Ersue <[email-masked]>

Operations and Management Area Directors:

     Benoit Claise <[email-masked]>

     Joel Jaeggli <[email-masked]>

Operations and Management Area Advisor:

     Benoit Claise <[email-masked]>

Mailing Lists:

     General Discussion: [email-masked]

     To Subscribe:    https://www.ietf.org/mailman/listinfo/netconf

     Archive:          <https://mailarchive.ietf.org/arch/browse/netconf/>
https://mailarchive.ietf.org/arch/browse/netconf/

Description of Working Group:

  Configuration of networks of devices has become a critical requirement

  for operators in today's highly interconnected networks. Large and 

  small operators alike have developed their own mechanisms or have used

  vendor specific mechanisms to transfer configuration data to and from 

  a device and to examine device state information which may impact the 

  configuration. Each of these mechanisms may be different in various

  aspects, such as session establishment, user authentication,

  configuration data exchange, and error responses.

  manipulate, and delete the configuration of network devices. NETCONF 

  is based on the secure transport (SSH is mandatory to implement while

  TLS is an optional transport). The NETCONF protocol is data modeling 

  language independent, but YANG (RFC 7950) is the recommended NETCONF 

  modeling language, which introduces advanced language features for 

  configuration management.

  (RFC 8040) which provides an interface over HTTPs for accessing data 

  defined in YANG. RESTCONF is based on the capabilities and uses the 

  datastore concept defined in the NETCONF protocol specification. In 

  support of RESTCONF the YANG-Patch (RFC 8072) mechanism has been 

  provided for applying patches to configuration datastores. The YANG 

  Module Library (RFC 7895) provides information about all YANG modules

  used by a network management server.

  Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have been

  developed, which enable a server to initiate a secure connection to a 

  workgroup will focus on following items:

  1. Finalize the YANG data module for a system-level keystore mechanism,

  that can be used to hold onto asymmetric private keys and certificates

  that are trusted by the system advertising support for this module.

  Based on the known dependencies this draft has the highest priority 

  for the WG.

  NETCONF and RESTCONF as well as the Client and Server Models for SSH 

  and TLS.

  just its factory default settings, and the Network Management System)

  Model) by adding support for RESTCONF and the YANG 1.1. constructs 

  like "action" and the "notification" statements.

  5. Provide a set of documents enabling advanced notification/  

  subscription capabilities, which gracefully co-exist in a deployment 

  of RFC 5277. The new capabilities include e.g. transport independence,

  multiple dynamic and configured subscriptions in a transport 

  session. RFC 5277 will be obsoleted in parallel to the publication of

  the new document set. Following specifications will be addressed:

   - Protocol-neutral notification framework, i.e., explaining the 

     concepts of subscriptions, filters, subscription state 

     notifications, replay, etc. and defining the associated YANG data 

     model, RPCs, etc.

   - Definition of notifications sent over NETCONF and how YANG 

     notifications are encoded in XML and JSON. Include considerations 

     for parallel support / implementation compatibility with RFC-5277.

   - Definition of notifications sent over RESTCONF and HTTP2 and how 

     YANG notifications are encoded in XML and JSON. Include specifics 

     of call-home and heartbeat for subscriptions.

   - The subscription and push mechanism for YANG datastores allowing 

  6. Provide a revision for the NETCONF and RESTCONF protocols and the

  used datastore framework building on the datastore concept in NETMOD 

  revised datastores work. Bug fixing will be done and potential   

  YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding Rules 

  from RFC 7950 will be moved to RFC6241bis.

  7. Define capabilities for NETCONF and RESTCONF to support I2RS protocol 

  and ephemeral state datastore requirements. 

  Based on the implementation, deployment experience and inter-

  operability testing, the WG aims to produce a NETCONF status report 

  in a later stage. The result may be clarifications for RFC6241 and 

  RFC6242 and addressing any reported errata.

Goals and Milestones:

  Done     Submit NETCONF/RESTCONF Call Home to AD/IESG for consideration as
Proposed Standard

  Done     Submit YANG Library to AD/IESG for consideration as Proposed
Standard

  Done     Submit RESTCONF to AD/IESG for consideration as Proposed Standard

  Done     Submit YANG Patch to AD/IESG for consideration as Proposed
Standard

  May 2017  WGLC for Zero-touch configuration mechanism

  Jun 2017  Submit Zero-touch configuration to AD/IESG for consideration as
Proposed Standard 

  Jun 2017  Submit keystore mechanism to AD/IESG for consideration as
Proposed Standard 

  May 2017  WGLC for Server and Client models for NETCONF and RESTCONF

  Jun 2017  Submit Server and Client Configuration models to AD/IESG for
consideration as Proposed Standard 

  Jun 2017  Submit Client and Server Models for SSH and TLS to AD/IESG for
consideration as Proposed Standard 

  Jun 2017  WGLC for RFC 6536bis (NETCONF Access Control Model) 

  Jul 2017  Submit RFC 6536bis to AD/IESG for consideration as Proposed
Standard

  Jun 2017  WGLC for advanced Notification/Subscription specifications 

  Jul 2017  Submit Notification/Subscription specifications to AD/IESG for
consideration as Proposed Standard

From: Benoit Claise [mailto:[email-masked]] 
Sent: Friday, March 17, 2017 4:49 PM
To: Kent Watsen <[email-masked]>; Mehmet Ersue <[email-masked]>;
'Susan Hares' <[email-masked]>; 'Andy Bierman' <[email-masked]>
Cc: 'Netconf' <[email-masked]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

I agree with Mehmet, any changes to the NC/RC protocols should be done in
the NETCONF WG.

+1.

Regards, Benoit

K.

On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue"
<[email-masked] <mailto:[email-masked]>  on behalf of
[email-masked] <mailto:[email-masked]> > wrote:

Hi Sue,

I personally prefer to publish such NC/RC add-ons in NETCONF WG as they
belong together.

I would like to suggest to discuss on the maillist and let NETCONF WG decide
in Chicago.

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 7:36 PM
To: 'Mehmet Ersue'  <mailto:[email-masked]> <[email-masked]>; 'Andy
Bierman'  <mailto:[email-masked]> <[email-masked]>
Cc: 'Juergen Schoenwaelder'  <mailto:[email-masked]>
<[email-masked]>; 't.petch'
<mailto:[email-masked]> <[email-masked]>; 'Netconf'
<mailto:[email-masked]> <[email-masked]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet:

How do we make this official?   Should we do the same for NETCONF additions
for I2RS?  

Sue 

Hi Sue,

providing add-ons which don't require republishing of RESTCONF-8040 would be
indeed important.

I don't mind if add-ons to RESTCONF specific to I2RS are done in I2RS.

However forcing serious reviews early and publishing them in NETCONF would
be my preference. 

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[email-masked] <mailto:[email-masked]> >
Cc: 'Mehmet Ersue' <[email-masked] <mailto:[email-masked]> >; 'Juergen
Schoenwaelder' <[email-masked]
<mailto:[email-masked]> >; 't.petch'
<[email-masked] <mailto:[email-masked]> >; 'Netconf'
<[email-masked] <mailto:[email-masked]> >
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Andy: 

Thank you for the clarification.  Since this is an Add-on and not focused on
the base specification, where should the Add-on specification be worked on?
I2RS WG with final cross-review in NETCONF?   It seems that NETCONF has lots
of other work on the list.  

Sue 

 

On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[email-masked]
<mailto:[email-masked]> > wrote:

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
<mailto:[email-masked]> ] On Behalf Of Mehmet Ersue

Mehmet

> <[email-masked] <mailto:[email-masked]> >; 'Netconf' <[email-masked]
<mailto:[email-masked]> >; 'Benoit Claise'

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 09:20:15 +0100

>      of call-home and heartbeat for subscriptions.

I believe we do have specifications how YANG defined notifications are
encoded in XML and JSON. Do we plan to redo this? I do not think so.
Perhaps it needs to be state more clearly what the scope of this work
is and what it is not.

And what is HTTP2 doing here? I assume this is about replacing the
Server-Sent Events (SSE) mechanism with HTTP/2 push. I checked RFC
8040 and it specifically says:

   This document defines a protocol based on HTTP [RFC7230] called
   "RESTCONF", for configuring data defined in YANG version 1 [RFC6020]
   or YANG version 1.1 [RFC7950], using the datastore concepts defined
   in the Network Configuration Protocol (NETCONF) [RFC6241].

Note that RFC 7230 is HTTP/1.1. I think the WG really needs to write a
document that defines RESTCONF over HTTP/2 and not just notifications
over HTTP/2. Such a document may very well say that almost nothing
needs changes to run over HTTP/2 except the notification delivery
being done differently. But I think the scope should be RESTCONF over
HTTP2 and not RESTCONF notifications over HTTP2.

/js

---

From: t.petch <[email-masked]>
Date: Tue, 21 Mar 2017 10:08:46 +0000

What interaction, if any, is there between

draft-ietf-rtgwg-yang-key-chain-15.txt
This document describes the key chain YANG data model.
file "[email-masked]"

currently in IETF Last Call, and

draft-ietf-netconf-system-keychain-00
This document defines a YANG data module for a system-level keychain
mechanism
file "[email-masked]"

?

Tom Petch

----- Original Message -----
From: "Mehmet Ersue" <[email-masked]>
To: "'Benoit Claise'" <[email-masked]>; "'Susan Hares'"
<[email-masked]>
Sent: Monday, March 20, 2017 4:32 PM

>      Archive:
<https://mailarchive.ietf.org/arch/browse/netconf/>
requirement
>   1. Finalize the YANG data module for a system-level keystore
mechanism,

<snip>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 21 Mar 2017 04:21:41 -0700

Tom,

Including RTGWG, the draft-ietf-rtgwg-yang-key-chain home.
In general, there’s no interactions, rtgwg-yang-key-chain work has been focused on data model for routing protocols key-chain’s configuration and management.

Thanks!
 
Cheers,
Jeff

On 3/21/17, 03:08, "Netconf on behalf of t.petch" <[email-masked] on behalf of [email-masked]> wrote:

    

    ?
    
    Tom Petch

    ----- Original Message -----
    From: "Mehmet Ersue" <[email-masked]>
    To: "'Benoit Claise'" <[email-masked]>; "'Susan Hares'"
    <[email-masked]>
    Sent: Monday, March 20, 2017 4:32 PM
    
    requirement
    mechanism,
    
    <snip>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 09:07:22 -0400

Mehmet and Benoit: 

I'm pleased to see the I2RS suggested additions split into 3 parts:
notification/events, revised datastore additions,  and the ephemeral state
additions for the I2RS protocol.   Just a few questions on how this charter
item is related to the I2RS requirements. 

.         My understanding is that the control plane datastore is in the
revised datastore additions.   Is this correct?   Will edit-collision
prevention defined in the I2RS ephemeral state be part of the revised
datastores work?   RESTCONF (RFC8040) Entity-Tag and timestamp could be
utilized for this functionality.  It seems to fit better there.   

.         Is the constraint restrictions for cross datastore reference that
the i2rs ephemeral states going to be part of the revised-datastores work?
Perhaps a more general mechanism for cross-datastore would be useful.   

.         Interestingly, the revised-datastore document
(draft-ietf-netmod-revised-datastores-01) does not include a "write-data"
function for datastores.  Was this an oversight? 

.          <https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/>
draft-ietf-netconf-rfc6536bis-01  - provides access control module update .
Will this be expanded as part of the datastores effort? 

Thank you, 

Sue 

From: Mehmet Ersue [mailto:[email-masked]] 
Sent: Monday, March 20, 2017 12:33 PM
To: 'Benoit Claise'; 'Susan Hares'
Cc: 'Netconf'
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Dear All,

Mehmet

Charter

Current Status: Active

Chairs:

Mailing Lists:

  for the WG.

  and TLS.

     model, RPCs, etc.

 

Goals and Milestones:

 

+1.

Regards, Benoit

K.

On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue"
<[email-masked] on behalf of [email-masked]> wrote:

Hi Sue,

BR,

Mehmet

Mehmet:

Sue 

Hi Sue,

BR,

Mehmet

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[email-masked]>
Cc: 'Mehmet Ersue' <[email-masked]>; 'Juergen Schoenwaelder'
<[email-masked]>; 't.petch' <[email-masked]>;
'Netconf' <[email-masked]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

Andy: 

Sue 

 

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 21 Mar 2017 14:22:40 +0000

Tom,
If you read the two drafts and look at the data nodes in the two models,
you¹ll quickly realize that they have entirely different purposes.
Thanks,
Acee 

On 3/21/17, 7:21 AM, "rtgwg on behalf of Jeff Tantsura"
<[email-masked] on behalf of [email-masked]> wrote:

>In general, there¹s no interactions, rtgwg-yang-key-chain work has been
>focused on data model for routing protocols key-chain¹s configuration and
>management.
>
>Thanks!
> 
>Cheers,
>Jeff
>
>On 3/21/17, 03:08, "Netconf on behalf of t.petch"
><[email-masked] on behalf of [email-masked]> wrote:
>
>    > Following Benoit's support the I2RS-related additions have been
>added
>    as a
>    > separated item.
>    >
>    >   developed, which enable a server to initiate a secure connection
>to
>    a
>    >
>    >   Jun 2017  Submit Client and Server Models for SSH and TLS to
>AD/IESG
>    for
>    >   Jul 2017  Submit Notification/Subscription specifications to
>AD/IESG
>    for
>    > I agree with Mehmet, any changes to the NC/RC protocols should be
>done
>    in
>    > the NETCONF WG.
>    >
>    > +1.
>    >
>    > Regards, Benoit
>    >
>    >
>    
>    <snip>
>    
>    
>rtgwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Robert Wilton <[email-masked]>
Date: Tue, 21 Mar 2017 14:33:27 +0000

Hi Sue,

Some comments (as one of the revised-datastore authors, but comments are 
my own) inline ...

On 21/03/2017 13:07, Susan Hares wrote:
>
> Mehmet and Benoit:
>
> I’m pleased to see the I2RS suggested additions split into 3 parts: 
> notification/events, revised datastore additions,  and the ephemeral 
> state additions for the I2RS protocol.   Just a few questions on how 
> this charter item is related to the I2RS requirements.
>
> ·My understanding is that the control plane datastore is in the 
> revised datastore additions.   Is this correct?
>
The revised datastores draft defines abstractly what a control plane 
datastore looks like (4.2. Dynamic Datastores), and how they interact 
with the system, but doesn't currently define any actual dynamic 
datastores.  My expectation is that various protocols would define their 
dynamic datastores as part of their protocol drafts (as per 5. 
Guidelines for Defining Dynamic Datastores).

> Will edit-collision prevention defined in the I2RS ephemeral state be 
> part of the revised datastores work?
>
I think that this is still open for discussion.

I2RS needs to perform conflict resolution between the various I2RS 
clients.  I would expect that this conflict resolution would be defined 
entirely alongside the I2RS datastore definition, and happen completely 
within the I2RS datastore definition.

But there also needs to be conflict resolution between a generic dynamic 
datastore and the operational datastore.  I think that this should 
probably be defined in the datatstores draft.

> RESTCONF (RFC8040) Entity-Tag and timestamp could be utilized for this 
> functionality.  It seems to fit better there.
>
> ·Is the constraint restrictions for cross datastore reference that the 
> i2rs ephemeral states going to be part of the revised-datastores work? 
I think that this point still needs further discussion.

It isn't clear to me that allowing cross datastore references is the 
right solution.

E.g. in the I2RS case, I had envisaged that one possible abstraction for 
the I2RS datastore is that it might monitor and have some of the 
operational state data logically mirrored into the I2RS datastore. This 
would potentially allow I2RS to validate its models entirely within the 
I2RS datastore without requiring any cross datastore references.  
Further, it would also allow the I2RS datastore to perform config 
resolution between static configuration and I2RS configuration and take 
whatever actions are appropriate, and feed any updates back into the 
operational datastore.

Perhaps something like this diagram:
                       +------------+
                       | <intended> | // subject to validation
                       | (ct, ro)   |
                       +------------+
                             |
                             |        // e.g., missing resources, delays
                             |
                             |
                             |   +------ I2RS datastore(s)
                             |   |         ^
                             v   v         |
                     +---------------+     | // I2RS monitors a subset of
                     | <operational> |-----+ // operationaland can update
                     | (ct + cf, ro) |       // via a feedback loop.
                     +---------------+

> ·Interestingly, the revised-datastore document 
> (draft-ietf-netmod-revised-datastores-01) does not include a 
> “write-data” function for datastores.  Was this an oversight?
>
Again, I think that would be part of the I2RS datastore definition.

Thanks,
Rob

> ·draft-ietf-netconf-rfc6536bis-01 
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/>  - 
> provides access control module update . Will this be expanded as part 
> of the datastores effort?
>
> Thank you,
>
> Sue
>
> *Sent:* Monday, March 20, 2017 12:33 PM
> *To:* 'Benoit Claise'; 'Susan Hares'
> *Cc:* 'Netconf'
> based on the recent discussion and proposals please find below the 
> updated charter proposal for NETCONF WG.
>
> Following Benoit’s support the I2RS-related additions have been added 
> as a separated item.
>
> Being dependent on netmod-revised-datastores point 6 and 7 have been 
> defined as a goal without a deadline.
>
> Mehmet
>
>      Mahesh Jethanandani <[email-masked] 
> <mailto:[email-masked]>>
>
> Mehmet Ersue <[email-masked] <mailto:[email-masked]>>
>
>      Benoit Claise <[email-masked] <mailto:[email-masked]>>
>
>      Joel Jaeggli <[email-masked] <mailto:[email-masked]>>
>
>      Benoit Claise <[email-masked] <mailto:[email-masked]>>
>
> Mailing Lists:
>
>      General Discussion: [email-masked] <mailto:[email-masked]>
>
> Archive: https://mailarchive.ietf.org/arch/browse/netconf/
>
>   Done     Submit NETCONF/RESTCONF Call Home to AD/IESG for 
>   Done     Submit YANG Library to AD/IESG for consideration as 
> Proposed Standard
>
>   Jun 2017  Submit Zero-touch configuration to AD/IESG for 
>   Jun 2017  Submit Server and Client Configuration models to AD/IESG 
>   Jun 2017  Submit Client and Server Models for SSH and TLS to AD/IESG 
>   Jul 2017  Submit RFC 6536bis to AD/IESG for consideration as 
> Proposed Standard
>
>   Jul 2017  Submit Notification/Subscription specifications to AD/IESG 
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Friday, March 17, 2017 4:49 PM
> *To:* Kent Watsen <[email-masked] <mailto:[email-masked]>>; 
> Mehmet Ersue <[email-masked] <mailto:[email-masked]>>; 'Susan 
> Hares' <[email-masked] <mailto:[email-masked]>>; 'Andy Bierman' 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* 'Netconf' <[email-masked] <mailto:[email-masked]>>
>     done in the NETCONF WG.
>     <[email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Sue,
>
>     *From:* Susan Hares [mailto:[email-masked]]
>     *To:* 'Mehmet Ersue' <[email-masked]> <mailto:[email-masked]>;
>     'Andy Bierman' <[email-masked]> <mailto:[email-masked]>
>     *Cc:* 'Juergen Schoenwaelder'
>     <[email-masked]>
>     <mailto:[email-masked]>; 't.petch'
>     <[email-masked]> <mailto:[email-masked]>; 'Netconf'
>     <[email-masked]> <mailto:[email-masked]>
>     *From:* Mehmet Ersue [mailto:[email-masked]]
>     *From:* Susan Hares [mailto:[email-masked]]
>     *From:* Andy Bierman [mailto:[email-masked]]
>     <mailto:[email-masked]>> wrote:
>
>     Mehmet:
>
>         > > > Such changes fall under the "maintaining" clauses in the
>         NETMOD
>         > > charter:
>         > > >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Mar 2017 16:41:17 +0000

Hi Tom,

We renamed our "keychain" module to "keystore" about four months ago, in part to help disambiguate it from the rtgwg's "key-chain" module.  The rtgwg's key-chain module is specific to symmetric keys used in routing protocols, whereas the netconf keystore module is primarily focused on asymmetric keys used in authentication protocols.  We discussed a while back (> 1yr ago) about potential overlap and decided that there was none.  During YANG doctor review, I encouraged Acee to add a statement about the non-relationship, but he didn't go for it.  FWIW, the PCE-PCEP module plans to use both the key-chain and keystore modules.

Kent

-----ORIGINAL MESSAGE-----

?

Tom Petch

----- Original Message -----
From: "Mehmet Ersue" <[email-masked]>
To: "'Benoit Claise'" <[email-masked]>; "'Susan Hares'"
<[email-masked]>

> based on the recent discussion and proposals please find below the
updated
> Being dependent on netmod-revised-datastores point 6 and 7 have been
defined
requirement
mechanism,
consideration as
>   Done     Submit YANG Library to AD/IESG for consideration as
Proposed
consideration as
for
for
>   Jul 2017  Submit RFC 6536bis to AD/IESG for consideration as
Proposed
for

<snip>

---

From: t.petch <[email-masked]>
Date: Tue, 21 Mar 2017 16:38:48 +0000

---- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
Sent: Tuesday, March 21, 2017 2:22 PM

Tom,

<tp>
Acee

Yes, I had read them before posting; my point in quoting what I did was
that from the YANG module name and the introduction to the I-Ds, they
would appear to overlap, and you have to dig deeper to realise that they
do not.  I think this misleading and so wrong.

In the same vein, we have already discussed and agreed to disagree on
'keychain' and 'key-chain'; again, misleading and I think wrong.

As Andy said recently,  'YANG is supposed to be prioritized for readers,
writers, and then tool-makers.' and I interpret one part of this as
making life easy for the non-experts.

Which I do not see our current approach, two I-Ds neither acknowledging
the existence of the other, to key stores as doing.

Tom Petch

Thanks,
Acee

On 3/21/17, 7:21 AM, "rtgwg on behalf of Jeff Tantsura"
<[email-masked] on behalf of [email-masked]> wrote:

>    >      To Subscribe:
>    >   small operators alike have developed their own mechanisms or
have
>    used
>    >
>    >   vendor specific mechanisms to transfer configuration data to
and
>    from
>    >
>    >   a device and to examine device state information which may
impact
>    >   datastore concept defined in the NETCONF protocol
specification.
>In
>    >   Last but not least NETCONF and RESTCONF Call Home (RFC 8071)
have
>    been
>    >   NETCONF and RESTCONF as well as the Client and Server Models
for
>SSH
>    >   relationship between a newly delivered network device
configured
>    with
>    >   session. RFC 5277 will be obsoleted in parallel to the
publication
>    of
>    >   6. Provide a revision for the NETCONF and RESTCONF protocols
and
>    >   Done     Submit RESTCONF to AD/IESG for consideration as
Proposed
>    >   Jun 2017  Submit keystore mechanism to AD/IESG for
consideration

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 21 Mar 2017 17:09:32 +0000

Tom

>'keychain' and 'key-chain'; again, misleading and I think wrong.

The latest version of the NETCONF draft refers to keystore rather than
keychain. 

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore

Hopefully, this has resolved any potential confusion and your concerns.
There are going to be modules that share common qualifiers. Consider “ip”,
“interface”, “system”, “oam”, and “topology”.

Thanks,
Acee

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 13:38:42 -0400

Robert: 

Thank you for the comments.  Please see comments below. 

Sue 

From: Robert Wilton [mailto:[email-masked]] 
Sent: Tuesday, March 21, 2017 10:33 AM
To: Susan Hares
Cc: 'Mehmet Ersue'; 'Benoit Claise'; 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

>Some comments (as one of the revised-datastore authors, but comments are my
own) inline ...

notification/events, revised datastore additions,  and the ephemeral state
additions for the I2RS protocol.   Just a few questions on how this charter
item is related to the I2RS >>requirements. 

>> My understanding is that the control plane datastore is in the revised
datastore additions.   Is this correct?

> The revised datastores draft defines abstractly what a control plane
datastore looks like (4.2. Dynamic Datastores), and how they interact with
the system, but doesn't currently define any actual dynamic ?datastores.  My
expectation is that various protocols would define their dynamic datastores
as part of their protocol drafts (as per 5. Guidelines for Defining Dynamic
Datastores).

If you mean the protocols drafts - does that mean I2RS as a higher -level
protocol reusing other protocols (e.g., NETCONF or RESTCONF), or the draft
that specifies in the additions in NETCONF or RESTCONF.  That's a little
problematic for I2RS which is a re-use protocol supporting multiple
protocols.   It would be better to have a common datastore description.  

> I2RS needs to perform conflict resolution between the various I2RS
clients.  

> I would expect that this conflict resolution would be defined entirely
alongside the I2RS datastore definition, and happen completely within the
I2RS datastore definition.

>But there also needs to be conflict resolution between a generic dynamic
datastore and the operational datastore.  I think that this should probably
be defined in the datatstores draft.

Should the general mechanisms for precedence (aka which datastore wins if
two of the same variables are set) - be done in a common way. 

>>  Is the constraint restrictions for cross datastore reference that the

>It isn't clear to me that allowing cross datastore references is the right
solution. 

>E.g. in the I2RS case, I had envisaged that one possible abstraction for
the I2RS datastore is that it might monitor and have some of the operational
state data logically mirrored into the I2RS datastore.  This ?>would
potentially allow I2RS to validate its models entirely within the I2RS
datastore without requiring any cross datastore references.  Further, it
would also allow the I2RS datastore to perform config >resolution between
static configuration and I2RS configuration and take whatever actions are
appropriate, and feed any updates back into the operational datastore.

>                    | <operational> |-----+ // operational and can update

It does need more discussion.  Why is cross-datastore references for
"reading" a problem? Or are you just looking at writes? 

Constraints were written for "write checks" in I2RS. 

>>Interestingly, the revised-datastore document

>Again, I think that would be part of the I2RS datastore definition.

Really?  Is this because you believe the edit-collision problem will be
solved in lots of different ways. 

We should talk more. 

===========

Thanks,
Rob

Thank you for taking the time to review this draft before IETF. 

Sue 

Thank you, 

Sue 

Dear All,

Mehmet

Charter

Current Status: Active

Chairs:

Mailing Lists:

  for the WG.

  and TLS.

     model, RPCs, etc.

 

Goals and Milestones:

 

+1.

Regards, Benoit

K.

Hi Sue,

BR,

Mehmet

Mehmet:

Sue 

Hi Sue,

BR,

Mehmet

Andy: 

Sue 

 

Mehmet:

 

Sue Hares

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 18:43:58 +0100

Unfortunately, nobody likes to make the distinction symmetric keys vs
asymmetric keys clear and obvious - instead we have keystore
vs. keychain and draft titles such as 'Keystore Model' and 'Routing
Key Chain YANG Data Model'. And authors then prefer to qualify things
as 'routing' and 'system' in the abstract, which does not help either.
I meanwhile have given up on this.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 13:41:15 -0400

+1 - to Juegen's comment that the distinction between symmetric keys and
asymmetric keys should be clear and obvious. 

Sue 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, March 21, 2017 1:44 PM
To: Kent Watsen
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Unfortunately, nobody likes to make the distinction symmetric keys vs
asymmetric keys clear and obvious - instead we have keystore vs. keychain
and draft titles such as 'Keystore Model' and 'Routing Key Chain YANG Data
Model'. And authors then prefer to qualify things as 'routing' and 'system'
in the abstract, which does not help either.
I meanwhile have given up on this.

/js

On Tue, Mar 21, 2017 at 04:41:17PM +0000, Kent Watsen wrote:
> Hi Tom,
> 
> We renamed our "keychain" module to "keystore" about four months ago, in
part to help disambiguate it from the rtgwg's "key-chain" module.  The
rtgwg's key-chain module is specific to symmetric keys used in routing
protocols, whereas the netconf keystore module is primarily focused on
asymmetric keys used in authentication protocols.  We discussed a while back
(> 1yr ago) about potential overlap and decided that there was none.  During
YANG doctor review, I encouraged Acee to add a statement about the
non-relationship, but he didn't go for it.  FWIW, the PCE-PCEP module plans
to use both the key-chain and keystore modules.
> mechanism file "[email-masked]"
> 
> ?
> 
> Tom Petch
> 
> 
> >   Jun 2017  Submit keystore mechanism to AD/IESG for consideration 
> > as Proposed Standard
> >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Mar 2017 18:56:32 +0000

Again, a keystore is not limited to asymmetric keys.   At the moment it is exclusively asymmetric, but that's only because we (the authors) moved the passwords (read symmetric keys) that were present in the previous version to the ietf-ssh-client module, but they may return, as many real-world keystore mechanisms do manage passwords as well (e.g., Mac OSX's Keychain Access utility).

The module names are fine, but we could update the draft title. How about "A System-level Keystore Model"?

K.

-----ORIGINAL MESSAGE-----

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 20:26:53 +0100

So you are saying the distinction is system vs. routing. Does this
mean we will need a web app keystore, a VPN key chain, an AAA
keystore/keychain, etc. in the future? Since we seem to repeat a
previous discussion, I will step out here.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 21 Mar 2017 21:58:54 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, March 21, 2017 4:20 AM
> 

No plans to redo this.  The only thing this shows is that there are plans to provide examples which match to the Network Subscriptions space.

> Perhaps it needs to be state more clearly what the scope of this work is and
> what it is not.
> 
> And what is HTTP2 doing here? I assume this is about replacing the Server-
> Sent Events (SSE) mechanism with HTTP/2 push. I checked RFC
> document that defines RESTCONF over HTTP/2 and not just notifications over
> HTTP/2. Such a document may very well say that almost nothing needs
> changes to run over HTTP/2 except the notification delivery being done
> differently. But I think the scope should be RESTCONF over

There are two different needs:

(1) RESTCONF over HTTP2:  This is what you are asking for, and I would love to see this as well.  As far as I know, nobody is currently defining this. 

(2) Notifications over HTTP2:  for Configured Subscriptions, there is no need for any RESTCONF involvement when the resulting stream of Notifications is delivered over HTTP.  In addition, there are multiplexing, QoS, and other benefits if the Notifications are delivered over HTTP2.   I believe the NETCONF WG has an interest in this issue the same notification structures can be used as would also be used with does Dynamic Subscriptions established using RESTCONF control plane messages.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Mar 2017 07:45:33 +0100

> No plans to redo this.  The only thing this shows is that there are plans to provide examples which match to the Network Subscriptions space.

But this is not what the text says. So the text needs to be fixed.

> (2) Notifications over HTTP2:  for Configured Subscriptions, there is no need for any RESTCONF involvement when the resulting stream of Notifications is delivered over HTTP.  In addition, there are…

I disagree that we should create another protocol in addition to
RESTCONF to deliver notifications.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Mar 2017 08:54:39 +0100

> On 21 Mar 2017, at 22:58, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Juergen,
> 

I wonder: is this needed? AFAIK, HTTP/2 methods are semantically equivalent to those of 1.1. We have a working implementation of RESTCONF over HTTP/2 (only) and I am not aware of any change in RESTCONF that was be needed because of HTTP version.

Regarding HTTP/2 Server Push, its purpose is IMO different, so it cannot serve as a replacement to SSE.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Mar 2017 09:47:51 +0100

> I wonder: is this needed? AFAIK, HTTP/2 methods are semantically equivalent to those of 1.1. We have a working implementation of RESTCONF over HTTP/2 (only) and I am not aware of any change in REST…

I _assume_ there is not much needed but someone has to go and check
the details.

> Regarding HTTP/2 Server Push, its purpose is IMO different, so it cannot serve as a replacement to SSE.

Is that just a feeling or a claim or is there additional technical
detail why this would be the case?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Mar 2017 10:35:35 +0100

> On 22 Mar 2017, at 09:47, Juergen Schoenwaelder <[email-masked]> wrote:
> 

It's used if the server expects some request from the client to follow, and the PUSH_PROMISE frame sent by the server must contain the headers from the expected request. With notifications there are no requests expected from the client.

A more detailed explanation is here (search for SSE):

https://www.infoq.com/articles/websocket-and-http2-coexist

Lada

---

From: Robert Wilton <[email-masked]>
Date: Wed, 22 Mar 2017 11:48:35 +0000

Hi Sue,

On 21/03/2017 17:38, Susan Hares wrote:
> *From:*Robert Wilton [mailto:[email-masked]]
> *Sent:* Tuesday, March 21, 2017 10:33 AM
> *To:* Susan Hares
> *Cc:* 'Mehmet Ersue'; 'Benoit Claise'; 'Netconf'
> >Some comments (as one of the revised-datastore authors, but comments 
> are my own) inline ...
>
> >>
>
> this charter item is related to the I2RS >>requirements.
>
> >> My understanding is that the control plane datastore is in the 
> ?datastores. My expectation is that various protocols would define 
> their dynamic datastores as part of their protocol drafts (as per 5. 
> If you mean the protocols drafts – does that mean I2RS as a higher 
> –level protocol reusing other protocols (e.g., NETCONF or RESTCONF), 
> or the draft that specifies in the additions in NETCONF or RESTCONF.  
> That’s a little problematic for I2RS which is a re-use protocol 
> supporting multiple protocols.   It would be better to have a common 
> datastore description.
>
I think that you could have:
1) Some text defining the I2RS datastore (or a set of datatstores) that 
documents how those datastores fit into the datastore model defined in 
the revised datastores draft.
2) Some text for I2RS related RESTCONF extensions that references the 
(1) above.
3) Some text for I2RS related NETCONF extensions that references the (1) 
above.

As to whether this need to go into separate drafts or one draft, I don't 
know.  Personally, I think that it would be easier to review and keep 
consistent if they are in one document, but I'll leave that for the I2RS 
WG to decide.

> > I would expect that this conflict resolution would be defined 
> entirely alongside the I2RS datastore definition, and happen 
> completely within the I2RS datastore definition.
>
> >But there also needs to be conflict resolution between a generic 
> dynamic datastore and the operational datastore.  I think that this 
> should probably be defined in the datatstores draft.
>
> Should the general mechanisms for precedence (aka which datastore wins 
> if two of the same variables are set) – be done in a common way.
>
If the resolution is between a dynamic datastore and and the static 
configuration datastores then yes I think that this should be defined in 
a common way.

> >E.g. in the I2RS case, I had envisaged that one possible abstraction 
> for the I2RS datastore is that it might monitor and have some of the 
> operational state data logically mirrored into the I2RS datastore.  
> This ?>would potentially allow I2RS to validate its models entirely 
> within the I2RS datastore without requiring any cross datastore 
> references.  Further, it would also allow the I2RS datastore to 
> perform config >resolution between static configuration and I2RS 
> configuration and take whatever actions are appropriate, and feed any 
> updates back into the operational datastore.
>
> “reading” a problem? Or are you just looking at writes?
>
> Constraints were written for “write checks” in I2RS.
>
It seems that the model is simpler if we can avoid cross datastore 
references.

The issues that I perceive are:
  - how are these cross datastore references defined?  Would this cause 
a tight coupling between models and datastores?
  - does it cause complexity in data integrity between the datastores, 
e.g. if I2RS is referencing state in operational that is being modified 
concurrently from intended.  Would I2RS expect to see a consistent 
snapshot across operational.
  - it effectively forces the cross referencing datastores to be 
implemented in the same place since they become tightly coupled.  If the 
definition wasn't tightly coupled then this could allow for more 
flexibility in the implementation (e.g. perhaps running I2RS in a 
different VM).

Hence, I think that the model may be conceptually simpler if cross 
datastore references are avoided, and validation is logically restricted 
to happening within a datastore.  Of course an implementation could 
choose to optimise this ...

> solved in lots of different ways.
I'm not really aware of other dynamic datastores currently coming along, 
so it somewhat hard to generalize.

I think that we need to have some simple rules to control how data flows 
into operational and which data takes precedence, but this may be as 
simple as last write wins.

But personally I think that all of the I2RS requirements concerning 
priority resolution between different I2RS clients and also local config 
should be solved in the I2RS datastore if possible.

> We should talk more.
OK. I'm sure that we can catch up in Chicago.

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 22 Mar 2017 15:28:24 +0000

> Sent: Wednesday, March 22, 2017 5:36 AM
> To: Jürgen Schönwälder <[email-masked]>
> Cc: Eric Voit (evoit) <[email-masked]>; Mehmet Ersue
> <[email-masked]>; Netconf <[email-masked]>
> > On 22 Mar 2017, at 09:47, Juergen Schoenwaelder
> <[email-masked]> wrote:
> >
> >>> (1) RESTCONF over HTTP2:  This is what you are asking for, and I would
> love to see this as well.  As far as I know, nobody is currently defining this.
> >>
> >> I wonder: is this needed? AFAIK, HTTP/2 methods are semantically
> equivalent to those of 1.1. We have a working implementation of RESTCONF
> over HTTP/2 (only) and I am not aware of any change in RESTCONF that was
> be needed because of HTTP version.

HTTP2 has a superset of capabilities vs. HTTP1.1.   There are new elements which are quite useful to expose to RESTCONF.

We had a thread on this in 2015.  You can see some of the possibilities at:
https://www.ietf.org/mail-archive/web/netconf/current/msg10426.html

> It's used if the server expects some request from the client to follow, and the
> PUSH_PROMISE frame sent by the server must contain the headers from the
> expected request. With notifications there are no requests expected from the
> client.

Yes.   And as HTTP2 allows different streams, the headers+notifications can go onto different streams so that higher priority notifications can avoid head-of-line blocking issues.   There is no RESTCONF interactions/encapsulation which is needed for this interaction.

Eric

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 22 Mar 2017 14:32:38 -0700

> On Mar 21, 2017, at 11:56 AM, Kent Watsen <[email-masked]> wrote:
> 
> 

How about "Asymmetric Key System-level Keystore Model"?

And add a reference to keychain model for symmetric keys. 

Mahesh Jethanandani 
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 22 Mar 2017 14:27:12 -0700

> On Mar 21, 2017, at 10:09 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Tom
> 

That should not be reason why we cannot clarify that the purpose of the keychain model is to deal with symmetric keys. And refer to keystore draft for asymmetric keys. 

Do you see a problem for calling out that distinction?

Mahesh

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Mar 2017 22:02:56 +0000

On 3/22/17, 5:27 PM, "Mahesh Jethanandani" <[email-masked]> wrote:

>That should not be reason why we cannot clarify that the purpose of the
>keychain model is to deal with symmetric keys. And refer to keystore
>draft for asymmetric keys.
>

As the original author and editor, I feel this is totally unnecessary. Of
course, if you want to add this to the ietf-keystore model draft, I would
not be oppose the reference.

Thanks,
Acee

---

From: Kent Watsen <[email-masked]>
Date: Wed, 22 Mar 2017 22:11:28 +0000

[+draft-ietf-rtgwg-yang-key-chain-all]

Hi Mahesh,

>> Again, a keystore is not limited to asymmetric keys.   At the moment 
>> it is exclusively asymmetric, but that's only because we (the authors)
>> moved the passwords (read symmetric keys) that were present in the 
>> previous version to the ietf-ssh-client module, but they may return,
>> as many real-world keystore mechanisms do manage passwords as well
>> (e.g., Mac OSX's Keychain Access utility).
>> 

Regarding "asymmetric", as mentioned above, while the keystore module
is currently exclusively asymmetric, it's probable that passwords will
be added to it in the future.

Regarding "system-level", I'm not 100% sure.  Specifically, the PCE-PCEP
use of the ietf-tls-client module, which uses the keystore module, gives
me pause.  Is it still a system-level use then?

Maybe one of the authors of the RTGWG key-chain draft to try to express
how the two modules differ, and why they shouldn't be merged into one
draft.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 22 Mar 2017 22:21:31 +0000

[resending, sorry, wrong key-chain draft alias used before]

Hi Mahesh,

Thanks,
Kent

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Mar 2017 22:35:19 +0000

Kent,

On 3/22/17, 6:21 PM, "Kent Watsen" <[email-masked]> wrote:

>how the two modules differ,

Is this a trick question? As the author of ietf-keystore, I¹d fully expect
that you know the difference.

>and why they shouldn't be merged into one
>draft.

They shouldn¹t be merged since they serve entirely different purposes and
will be implemented and deployed by different sets of network devices.
Furthermore, the key-chain draft is more mature and referenced by 6-10
other IETF YANG models.

Thanks,
Acee

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 22 Mar 2017 17:29:02 -0700

Acee,

> On Mar 22, 2017, at 3:35 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Kent,
> 
> 

But that is the point. The keychain draft description is not just for the authors of keystore draft.

> will be implemented and deployed by different sets of network devices.

I would agree, but to not call out the difference between the drafts and the models would be a disservice to the larger community.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 22 Mar 2017 17:56:06 -0700

Lada,

> On Mar 22, 2017, at 2:35 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
> 

To the question asked by Juergen. Is this reason enough for us to separate notifications for RESTCONF to be split from RESTCONF itself?

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 23 Mar 2017 01:06:55 +0000

>authors of keystore draft.

I don’t see any problem with the description and given the ubiquitous
usage for protocol authentication and encryption, nobody else does.

>I would agree, but to not call out the difference between the drafts and
>the models would be a disservice to the larger community.

There is no guarantee that the ietf-keystore draft will even make it to
standardization - especially with all this parochial concern about
positioning with more imperative and mature drafts. Please address in the
context of the ietf-keystore draft.

Thanks,
Acee

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Mar 2017 01:42:52 +0000

> To the question asked by Juergen. Is this reason enough for us to separate
> notifications for RESTCONF to be split from RESTCONF itself?

Notifications have never been delivered over RESTCONF.  RESTCONF is a just a way to signal / establish the relationship so that HTTP/ TCP can be used.

draft-ietf-netconf-restconf-notif proposes a mechanism which works with HTTP2.  This mechanism could be considered by a future RESTCONF revision should people want to re-open that newly minted RFC.

In either case, we should care about this in our charter. The question is how prescriptive do we want our charter to be in defining the resulting structure of new/potentially adopted drafts.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Mar 2017 07:52:03 +0100

> Notifications have never been delivered over RESTCONF.  RESTCONF is a just a way to signal / establish the relationship so that HTTP/ TCP can be used.

Would this not be true for all of RESTCONF? To me, it seems section 6
of RFC 8040 (aka RESTCONF) defines how notifications are handled.

> In either case, we should care about this in our charter. The question is how prescriptive do we want our charter to be in defining the resulting structure of new/potentially adopted drafts.

I think we need to prevent a babel tower of protocol variants.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Mar 2017 08:44:02 +0100

> On 23 Mar 2017, at 02:42, Eric Voit (evoit) <[email-masked]> wrote:
> 

IMO it makes sense to keep it separate because mechanisms that notifications can use are not part of HTTP, there are at least two alternatives (SSE and WebSockets) and may be more in the future. RESTCONF is built on top of HTTP and it should stay so.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Mar 2017 08:53:03 +0100

> On 22 Mar 2017, at 16:28, Eric Voit (evoit) <[email-masked]> wrote:
> 
> 
> 

All this seems to be related to the plumbing (TCP and SSL) whereas the RESTCONF spec is pretty much independent of it, perhaps except notifications.

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 23 Mar 2017 17:36:33 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Wednesday, March 22, 2017 10:21 PM

Kent

Sorry about mixing up keystore and keychain - I did download the updated
draft last week but failed to find it when I was drafting my post.
However, while I know the English semantics of store and chain, I do
find it more difficult to attach different semantics to keystore and
key-chain, and I do find the Abstracts of the two I-Ds rather similar
which leaves me uncertain about the scope of the work in Netconf.

When the proposed charter says
"  1. Finalize the YANG data module for a system-level keystore
mechanism,
  that can be used to hold onto asymmetric private keys and certificates
  that are trusted by the system advertising support for this module."
I am still uncertain.

You are saying symmetric keys may come in future but should this be part
of the charter now? I am divided on this.

You are saying you are unsure about system-level but what is it then,
not that I have ever realised what is meant by system-level (unless it
means not just for routers, but then the Abstract of key-chain, for the
first five sentences, sounds like a system-wide model with sentence six
only saying it is commonly used for routing protocols, it does not say
it is not also for system-wide use!).

I would then avoid system-level, since I do not understand it:-(
"Generic keystore mechanism" perhaps.

I note that the charter does say 'asymmetric' which I think needs saying
and also adding to the I-D; and I do think that the Netconf I-D should
recognise the existence of other I-Ds relating to the storage of  keys,
although that detail is not a matter for the charter.

Tom Petch

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Mar 2017 18:48:58 +0000

> > HTTP2 has a superset of capabilities vs. HTTP1.1.   There are new elements
> which are quite useful to expose to RESTCONF.
> >
> All this seems to be related to the plumbing (TCP and SSL) whereas the
> RESTCONF spec is pretty much independent of it, perhaps except notifications.

Agree that it is plumbing, and that existing RESTCONF is independent of this.  But should RESTCONF expose some of this plumbing?  

One thing HTTP2 can provide, should the capabilities be exposed above RESTCONF is prioritized TCP stream de-queuing to avoid head-of-line blocking.  For more see:
https://www.ietf.org/mail-archive/web/netconf/current/msg10930.html

Beyond what we are doing with the notification drafts, I am not advocating that we expose this.  But maybe for others there are viable HTTP2 enhancements which leverages the plumbing.  

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Mar 2017 19:37:24 +0000

>>Maybe one of the authors of the RTGWG key-chain draft to try
>> to express how the two modules differ,
>
> Is this a trick question? 

No, it was to see if you could articulate it better than I have
been able to date.

> As the author of ietf-keystore, I'd fully expect that you 
> know the difference.

I do.

>>and why they shouldn't be merged into one draft.
>
> They should't be merged since they serve entirely different 
> purposes and will be implemented and deployed by different 
> sets of network devices. 

Fundamentally, they both are talking about storing keys that
can be referenced.  I could easily make a case for why the
keystore module should include passwords, including policies
around expiration and rollovers, somewhat like RFC7210, which
the key-chain module emulates.  Yes, we're coming at this from
very different angles, but at the end of the day, they're more
alike than not.

FWIW, I'm not actually proposing we merge our drafts/modules,
I'm just using this as a thought exercise for others.

Not that it matters, but I disagree that these modules will 
be implemented by different sets of devices.  As I expect any
router implementing the key-chain module (to configure keys to
protect routing protocols) would also implement the keystore
module (to configure the keys/certificates used to protect e.g.
the SSH/TLS connections over which the key-chain module is 
configured).

> Furthermore, the key-chain draft is more mature and referenced
> by 6-10 other IETF YANG models.

Funny, maybe we should compare dependency graphs using Benoit's 
tool?   But let's wait until Monday since but the Syslog and 
PCE-PCEP drafts should post updates then that import the keystore
module  ;)

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Mar 2017 20:40:08 +0000

Hi Tom,

> Sorry about mixing up keystore and keychain - I did download the
> updated draft last week but failed to find it when I was drafting
> my post. However, while I know the English semantics of store and
> chain, I do find it more difficult to attach different semantics
> to keystore and key-chain, and I do find the Abstracts of the two
> I-Ds rather similar which leaves me uncertain about the scope of
> the work in Netconf.

understood.

>       mechanism, that can be used to hold onto asymmetric private
>       keys and certificates that are trusted by the system 
>       advertising support for this module."
>
> I am still uncertain.

understood.

> You are saying symmetric keys may come in future but should this
> be part of the charter now? I am divided on this.

I'm also divided on it, but it is the case that we had passwords 
(read "symmetric keys") in the previous version of the keystore 
draft and, the reason that they're not there now is because we 
moved the passwords to the ietf-ssh-client module in the current
version of the draft...a decision that I consider to be "under 
review" and to be discussed in Chicago.

> You are saying you are unsure about system-level but what is it
> then, not that I have ever realised what is meant by system-level
> (unless it means not just for routers, but then the Abstract of 
> key-chain, for the first five sentences, sounds like a system-wide
> model with sentence six only saying it is commonly used for routing
> protocols, it does not say it is not also for system-wide use!).
>

I agree, for the reasons you mentioned, hence why I've resisted 
putting "system" into the draft's or the module's name.  Admittedly,
the draft's abstract/intro currently say "system", which should 
probably be removed.

> "Generic keystore mechanism" perhaps.

Perhaps, or just "keystore" with some more words around its 
common uses, kind of like how Acee's key-chain draft says that
it's commonly used in routing protocols.

> I note that the charter does say 'asymmetric' which I think needs
> saying and also adding to the I-D; and I do think that the Netconf
> I-D should recognise the existence of other I-Ds relating to the
> storage of  keys, although that detail is not a matter for the
> charter.

The draft currently says "private keys", which a veiled reference
to asymmetric keys.  It certainly can say this more overtly.

The draft used to have some words regarding the key-chain draft,
but Acee didn't think such sections were useful and so I took it
out in the most recent version.  If we add something back in now,
it would be along the lines of how the key-chain module is
specialized for a narrow purpose, while the keystore module is
useful in several contexts.

Kent

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 23 Mar 2017 21:01:04 +0000

Hi Kent, Tom, et al,

On 3/23/17, 4:40 PM, "Kent Watsen" <[email-masked]> wrote:

>(read "symmetric keys")

I wouldn¹t equate a password with a symmetric key.

>in the previous version of the keystore

That would be fine. I have added ³applications using symmetric keys² to
the Abstract and Introduction of the key-chain draft. While one could
conceivably use key-chains for other purposes, I fully believe there are
much more straight-forward ways to model keys and/or other security
objects required for these usages. I don¹t see key-chains ever evolving to
more than exactly as the Abstract describes them:

   This document describes the key chain YANG data model.  A key chain
   is a list of elements each containing a key string, send lifetime,
   accept lifetime, and algorithm (authentication or encryption).  By
   properly overlapping the send and accept lifetimes of multiple key
   chain elements, key strings and algorithms may be gracefully updated.
   By representing them in a YANG data model, key distribution can be
   automated.  Key chains are commonly used for routing protocol
   authentication and other applications requiring symmetric keys.  In
   some applications, the protocols do not use the key chain element key
   directly, but rather a key derivation function is used to derive a
   short-lived key from the key chain element key (e.g., the Master Keys
   used in the TCP Authentication Option(TCP-AO)).

The only augmentations I¹d envision would be additional algorithms and
potentially other key attributes. Of course, one can never fully predict
the future. 

Thanks,
Acee