Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview

From: t.petch <[email-masked]>
Date: Fri, 22 Jan 2016 16:03:08 +0000

Having read all of restconf, I find myself with some fairly basic
questions for which I cannot see answers.

A) Is restconf an optional extra for a server on top of NETCONF or do
you expect there to be restconf-only servers?  S.1.3 says that they can
coexists, yes, great, marketing.  But can you perform useful operational
tasks from a restconf-only client to a restconf-only server?  I started
off assuming you could, but ended up thinking the I-D was telling me
that at least the server musy have both e.g. s.12
"it does  require that an authenticated NETCONF username be associated
with each request"
which also begs the question, can there be restconf-only client?

Needs specifying IMO, perhaps after thinking through the consequences.

B) " the user should not need any prior knowledge of NETCONF in order to
use RESTCONF"
Well, I wrote 'rubbish' alongside that and taken literally, it is:=)
NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the
operational infrastructure (configuration, state, datastore, event,
error handling, persistence of data. ....) and while the former is
replaced, in whole or in part, by restconf, the latter most definitely
is not, as exemplified by the definitions imported in s.1.4.1

But that also in untrue.  This I-D implies, mostly without being
explicit, that it refines NETCONF the operational infrastructure
(perhaps using the terms in a different way).  Thus it appears that
there is no explicit selection of NETCONF datastore but that which one
is chosen is implicit.  I infer this from s.1.3 but think that it needs
separating out more clearly.

C) configuration and state; RFC 6241 is very clear about this, this I-D
seems to be half way towards whatever resolution netmod comes to on
netmod-opstate-reqs, which is probably not a good idea.  'state' I see
used only twice, then this undefined 'operational data' takes over and
the water is then muddied by 'config' and 'nonconfig'.  This is
wandering off into its own 'restconf the operational infrastructure'
without ever saying AFAICT how it differs from NETCONF.  It is as if the
three authors each independently wrote parts of the I-D:-)

D) Then there are datastores, at least there are until s.4.4.1, when
datastore seems to be redefined to mean 'top level node' a term which
has surfaced on the (netmod or netconf) mailing list as being something
that is not defined and may mean different things to different people.
I read the first half of the I-D thinking that 'datastore' is as defined
in RFC6241 and then find half way through that I cannot see any way that
it is.  I note the absence of any examples involving
'application/yang.datastore'
and think, well yes, that figures!

E) This then calls into question for me the meaning of the term 'data'.
In the latter part of the I-D, it seems to be shorthand for 'data or
datastore' with datastore having its non-NETCONF meaning but early on,
it is used alongside 'datastore' suggesting that it has a more
restricted meaning, coupled with the use of different media types, but I
cannot tell.

So, I have some detailed comments on s.4 onwards but think that the
'beams' need resolving first.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 20, 2016 6:43 PM
Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09,
draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

<snip>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jan 2016 08:32:48 -0800

Hi,

Why is it rubbish that there can be a RESTCONF-only server?
I can't find any text that says NETCONF MUST be implemented
if RESTCONF is implemented.

Some details (like defaults handling) are aligned with NETCONF.
That doesn't mean the RESTCONF client needs to know much
about NETCONF datastores or locks, etc.

Andy

On Fri, Jan 22, 2016 at 8:03 AM, t.petch <[email-masked]> wrote:

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

---

From: t.petch <[email-masked]>
Date: Sat, 23 Jan 2016 12:51:57 +0000

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Friday, January 22, 2016 4:32 PM

Andy

I find the I-D silent on its applicability.  I see
"  RESTCONF can be implemented on a device that supports NETCONF."
which I regard as close to marketing but have no problem with it being
there.  What I lack is any indication as to whether or not it is
feasible to have a restconf-only management system.  restconf lacks some
of NETCONF's capabilities so is it expected that the server will be
NETCONF as well or is the expectation that there will be restconf-only
systems?

This colours how I comment on the following text.  One small example of
several is in s.12

"Implementors SHOULD provide a comprehensive
   authorization scheme with RESTCONF and ensure that the resulting
   NETCONF username is made available to the RESTCONF server."

which implies to me that the server has NETCONF capabilities, at least
in part.  If not, then s.12 needs rewriting, along the lines that
restconf imports the idea of a username (along with masses of other
things) from NETCONF and must conform to the specification of usersname
as in section .. of RFC .....

So can there be a restconf-only system, clients and servers?  (dunno,
I-D implies not)
Can a server support restconf and NETCONF? yes, s1.2 tells me so
Can a restconf-only client do useful work with a hybrid restconf/NETCONF
server? (hopefully)
Can a client support restconf and NETCONF and use them to work with
restconf-only servers and NETCONF-only servers?  um, authentication
needs thinking about but hopefully yes

I find the I-D incomplete without this being clearly stated.

My comment of 'rubbish' was aimed at a different point, where the I-D
says that
" the user should not need any prior knowledge of NETCONF in order to
   use RESTCONF."
To me it is abundantly clear that the user must understand NETCONF in
depth in order to make sense of this I-D and I extrapolate that to
understanding NETCONF in order to make use of restconf.  There may or
may not be a need to have access to NETCONF client/server, which is my
point above, but there has to be an understanding of the concepts of
NETCONF in order to make sense of restconf.  You of course, along with
your fellow authors, WG Chairs, WG ADs, have that in depth.  I have it
to some degree.  Someone without such knowledge has no hope of
understanding or using restconf!

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Jan 2016 05:26:35 -0800

Hi,

We can clarify the sentence about NETCONF knowledge needed.

First of all, a RESTCONF-only implementation is certainly possible,
and planned, and implemented. JSON-only. Ditto.

If NETCONF is supported, then there are implementation details
within the server that need to be addressed.  The unfortunate text
that you and some others are complaining about could be changed
to say the client developer does not need to know the NETCONF details,
such as :candidate vs. :writable-running vs. plus :startup.
In RESTCONF the client just sends an edit and the server
will take care of these details.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Jan 2016 07:13:35 -0800

Hi,

Would your concerns be we put more detail in the NETCONF Coexistence
section.
I have already pointed out that the confirmed-commit details are missing.
We will make it clear which details a RESTCONF client needs to know.

We can add another short section for RESTCONF only considerations.
I thought it was already clear that implementation of NETCONF was not
required, but we can make it extra clear.

Applicability is another problem.  IMO let the market decide.
Some companies (and WGs) are already working on solutions that provide a
unified
"YANG development environment" to deploy with whatever protocol, across a
range of
platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF)
The boundaries of applicability are subjective and might be rapidly
changing for awhile.
(So I don't want to write an AS for RESTCONF.)

Andy

---

From: t.petch <[email-masked]>
Date: Sun, 24 Jan 2016 11:00:01 +0000

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>;
"Netconf" <[email-masked]>
Sent: Saturday, January 23, 2016 3:13 PM

Andy

I think that it is s1.3 that most needs changing, as I said in my first
e-mail of comments, but that its direction needs changing, to become
'Relationship with NETCONF'.

It should then say (although not in this order)

- a restconf client may or may not also be a NETCONF client
- a restconf server may or may not also be a NETCONF server
(and that is all I am intending by way of applicability)

- restconf replaces NETCONF the protocol but does use everything else
from NETCONF, followed by an exhaustive list, which would include at
least:
 state date and configuration data, multiple datastores, data
persistence (yes, I know RFC6241 is rather vague), (roll back on) error
handling, defaults, capabilities  (e.g :writable-running), locks, ...

Tom Petch

> > > > A) Is restconf an optional extra for a server on top of NETCONF
or
> > do
> > > > you expect there to be restconf-only servers?  S.1.3 says that
they
> > can
> > > > B) " the user should not need any prior knowledge of NETCONF in

> > order to
> > > > there is no explicit selection of NETCONF datastore but that
which
> > one
> > > > is chosen is implicit.  I infer this from s.1.3 but think that
it
> > needs
> > > > C) configuration and state; RFC 6241 is very clear about this,
this
> > I-D
> > > > netmod-opstate-reqs, which is probably not a good idea.  'state'
I
> > see
> > > > used only twice, then this undefined 'operational data' takes
over
> > and
> > > > without ever saying AFAICT how it differs from NETCONF.  It is
as if
> > the
> > > > in RFC6241 and then find half way through that I cannot see any
way
> > that
> > > > datastore' with datastore having its non-NETCONF meaning but
early
> > on,
> > > > restricted meaning, coupled with the use of different media
types,
> > but I

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Jan 2016 06:59:38 -0800

> - a restconf client may or may not also be a NETCONF client

IMO you are really confused.
Why would a RESTCONF client need to implement NETCONF?

The ONLY things a RESTCONF client needs to do
to access RESTCONF functionality if be a RESTCONF clent.

The argument "but RESTCONF can't do everything that NETCONF can do"
is irrelevant because the RESTCONF protocol does not claim
to do everything NETCONF can do.

A RESTCONF-only server may also have CLI, which can
lock the datastore, which can cause a RESTCONF edit to fail.
I suppose we have to warn people about this in the draft as well.

Andy

---

From: t.petch <[email-masked]>
Date: Tue, 26 Jan 2016 17:53:21 +0000

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Sunday, January 24, 2016 2:59 PM
> > > Some companies (and WGs) are already working on solutions that
provide
> > a

If I am, perhaps it is the result of reading this I-D:-)

After all, it is the authors who put in

"     1.3.  Coexistence with NETCONF

RESTCONF can be implemented on a device that supports NETCONF."

which draws the topic of coexistence to my attention for review, which I
have done.  My marginal comment on this section was 'marketing' but I
see nothing wrong with that.  But as I said before, I think that this
section has the wrong emphasis, that it should be about the relationship
between NETCONF and restconf, not just about coexistence on a box; and
if the authors want to cover coexistence, then to me that means
coexistence in a client and coexistence in the server (of which the
latter seems to raise more issues that need addressing, such as locks,
authenticated usernames and such like).

Again, as I have said before, rather than sorting out coexistence, I do
see a greater need to spell out those parts of NETCONF that are being
used alongside the restconf protocol to produce a system for operations.

Tom Petch

> > > > feasible to have a restconf-only management system.  restconf
lacks
> > some
> > > > This colours how I comment on the following text.  One small
example
> > of
> > > > My comment of 'rubbish' was aimed at a different point, where
the
> > I-D
> > > > says that
> > > > " the user should not need any prior knowledge of NETCONF in
order
> > to
> > > >    use RESTCONF."
> > > > To me it is abundantly clear that the user must understand
NETCONF
> > in
> > > > understanding NETCONF in order to make use of restconf.  There
may
> > or
> > > > may not be a need to have access to NETCONF client/server, which
is
> > my
> > > > NETCONF in order to make sense of restconf.  You of course,
along
> > with
> > > > your fellow authors, WG Chairs, WG ADs, have that in depth.  I
have
> > > > > > tasks from a restconf-only client to a restconf-only server?
I
> > > > started
> > > > > > Well, I wrote 'rubbish' alongside that and taken literally,
it
> > is:=)
> > > > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and
NETCONF
> > > > > > error handling, persistence of data. ....) and while the
former
> > is
> > > > > > (perhaps using the terms in a different way).  Thus it
appears
> > > > > > seems to be half way towards whatever resolution netmod
comes to
> > on
> > > > > > D) Then there are datastores, at least there are until
s.4.4.1,
> > when
> > > > > > datastore seems to be redefined to mean 'top level node' a
term
> > > > which
> > > > > > has surfaced on the (netmod or netconf) mailing list as
being
> > > > something
> > > > > > that is not defined and may mean different things to
different
> > > > people.
> > > > > > I read the first half of the I-D thinking that 'datastore'
is as
> > > > defined
> > > > > > E) This then calls into question for me the meaning of the
term
> > > > 'data'.
> > > > > > So, I have some detailed comments on s.4 onwards but think
that

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 19:15:22 +0100

> used alongside the restconf protocol to produce a system for operations.

What you are looking for is an architectural document that defines the
basic concepts that tie NETCONF, RESTCONF, YANG, etc together. I see
that such a document is needed and I am happy to invest some of my
time into such a document in the future. That said, I do not think
that we should hold back RESTCONF until such a document has been
written and gone through the consensus process. Hence, we need to find
a reasonable compromise (as we do with other documents at the moment)
but the long term goal should indeed be to create this architectural
document (and future revisions of protocol and language specifications
should then align with it).

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

---

From: t.petch <[email-masked]>
Date: Fri, 29 Jan 2016 17:06:11 +0000

I know; if you want to change an I-D, send text!

This is what I would like to have seen at the start of the I-D; likely
it is slanted towards a reader familiar with NETCONF, but that seems a
reasonable assumption to me at this point in time

NEW

1.x Relationship with NETVIEW

NETVIEW [RFC6241 et al] defines a protocol and associated concepts for
the configuration of network devices; RESTCONF, in this document,
provides an alternative protocol while reusing many of those
concepts.  A sound grasp of those concepts is necessary in order to
understand this document.

While RESTCONF can be used instead of the NETCONF protocol, the two,
RESTCONF and NETCONF can also coexist, in a network device or an
application or both.

NETCONF divides data into configuration data and state data, the former
being the writeable data that may be needed to get a device into its
running
condition, the latter the additional read-only data that is available on
a device which is not configuration data, such as status information and
collected statistics.

Data resides in configuration datastores of which NETCONF defines
running, candidate, startup and user-defined datastores along with a
capability, :writable-running, which allows changes to be made to the
running datastore.  While NETCONF allows explicit control over
which datastore(s) an operation applies to, with RESTCONF, this is
implicit (RESTCONF defines a media type yang.datastore but this refers
to top level nodes, not to datastores as defined by NETCONF).

If the device supports :writable-running, all edits to configuration
nodes are performed in the running datastore.

If the device does not support :writable-running but supports candidate,
all edits to configuration nodes are performed in the candidate
datastore.  The candidate is automatically committed to running after a
successful edit. Note that this may commit edits that have been
performed by means other
than RESTCONF.

If the device supports neither :writable-running nor candidate, then
RESTCONF cannot be used to edit the configuration.

If the device supports startup, then any edits that are performed to
running are copied to startup upon successful completion of the edits.

RESTCONF cannot be used to access user-defined datastores.

If the datastore that RESTCONF would edit is locked as a result of
actions by another protocol, such as NETCONF, then the edit fails with a
409 (Conflict) error code.  RESTCONF does not provide means to lock a
datastore.

NETCONF requires the underlying protocols to provide confidentiality and
authentication and to provide an authenticated user identity; this is
equally true of RESTCONF.  Where RESTCONF and NETCONF coexist on a
device, then it is expected that they share the same set of  user
identities.

While the authentication of a NETCONF server over TLS is restricted to
the use of X.509v3 certificates, and the same is true of RESTCONF,
RESTCONF is more flexible than NETCONF in the methods available for the
authentication of a user; this is discussed in section 2.5.

NETCONF offers a number of options for the retrieval of default values
[RFC6243] and the behaviour of RESTCONF is aligned with that of NETCONF.
A default data node is one which is not present in a datastore and for
which the server uses the schema default definition; not all servers use
the same criteria to decide if a data node is actually instantiated in a
datastore although the behaviour should be consistent between NETCONF
and RESTCONF where a device supports both servers.

RESTCONF edits are usually applied to one instance at a time, whereas
with NETCONF, the number of resources affected by an edit can be
considerable in number.  Hence NETCONF offers an optional
rollback-on-error capability which restores the datastore to its initial
state when an error is detected; with RESTCONF, this capability is
implicit - if an error is detected, then edits performed so far, if any,
are removed.  (The server may be unable to perform this rollback in
which case, it reports a rollback-failed error, code 500).

NETCONF also has the capability to lock a datastore so that a sequence
of edits can be treated as atomic.  RESTCONF has no such capability but
an edit may encounter a datastore locked by NETCONF, or by some other
protocol, in which case the edit will fail (code 409).

Tom Petch