Subject: [Netconf] I-D Action: draft-ietf-netconf-nmda-restconf-00.txt

From: [email-masked]
Date: Thu, 24 Aug 2017 14:11:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : RESTCONF Update to Support the NMDA
        Authors         : Martin Bjorklund
                          Juergen Schoenwaelder
                          Phil Shafer
                          Kent Watsen
                          Robert Wilton
	Filename        : draft-ietf-netconf-nmda-restconf-00.txt
	Pages           : 5
	Date            : 2017-08-24

Abstract:
   This document updates RESTCONF [RFC8040] in order to support the
   Network Management Datastore Architecture (NMDA) defined in
   [I-D.ietf-netmod-revised-datastores].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-nmda-restconf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-nmda-restconf-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Aug 2017 10:22:32 -0700

Hi,

Just a few comments on this short draft:

- terminology: there is no terminology section for new terms or RD terms.
None of the official terms in RD are used.

Conformance:

   A RESTCONF server identifies that it supports NMDA both by supporting
   the <operational> datastore, as well as by supporting at least
   revision YANG_LIBRARY_REVISION of the "ietf-yang-library" module, as
   specified in [I-D.nmdsdt-netconf-rfc7895bis].

Why can't a non-NMDA server implement the new yang-library revision,
and just include the conventional datastores? Is this prohibited?
I suggest a capability URI or some other deterministic indication of NMDA
conformance.

Note the term <operational> datastore not used in any official terminology.

The first sentence is not clear that an NMDA server MUST support the
operational datastore.

There is no suitable definition of the operational datastore given.
The text needs to say that the operational datastore is identified by
resource specification

 {+restconf}/ds/ietf-datastores:operational

The draft says "For instance" (implying e.g., not i.e.) and never defines
"the" operational datastore.
(i.e., there is only one official operational datastore).

The protocol operations section could provide more details.
The handling of defaults is made extra vague by the 3rd bullet.
What does apply if not this paragraph about MAY include defaults?

The with-origin query parameter and required server behavior are poorly
defined.
Is this query parameter mandatory to implement?  How does a client know it
can be used?

The draft completely ignores the fact that RESTCONF does not support
datastores
or datastore locking, or sessions, or datastore lock recovery.  Please
provide details about
how usage of the /restconf/data resources can interact with specific
datastores.

There are no examples at all in the draft, which would help since the terse
text
is not that clear.

Andy

On Thu, Aug 24, 2017 at 2:11 PM, <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Aug 2017 20:31:55 +0200 (CEST)

Hi,

> None of the official terms in RD are used.

Thanks, I'll fix this.

> and just include the conventional datastores? Is this prohibited?

No, this is probably ok.  But the text specifies what a NMDA-compliant
server would do, and it certainly supports <operational>.

> I suggest a capability URI or some other deterministic indication of NMDA

But NMDA conformance really just means that the new version of
yang-library is implemented, and that "operational" is listed as a
datastore in the library.  So I'm not sure what an additional
capability would achieve.  This said, if people think it would be
useful for clarity that would be fine with me.

> Note the term <operational> datastore not used in any official terminology.

I'll fix the terminology.

> The first sentence is not clear that an NMDA server MUST support the

We can add a very explicit sentence:

  An NMDA-compliant server MUST support the operational state
  datastore.

> There is no suitable definition of the operational datastore given.

I'll make sure we import the correct term from the nmda draft, and use
the term properly.

> (i.e., there is only one official operational datastore).

Ok.  I think we must state that the identity MUST be derived from
ietf-datastore (and provide a reference).

> What does apply if not this paragraph about MAY include defaults?

Ok, I'll expand the text.  It really means that all values are always
returned from <operational>, even if a node happens to have a default
statement in the YANG module, and this default value is being used by
the server.

> Is this query parameter mandatory to implement?  How does a client know it

We should probably define a capability for "origin" support, just like
we propose is done for NETCONF.

> how usage of the /restconf/data resources can interact with specific

Are you looking for something like the text in 1.4 in 8040?  

> There are no examples at all in the draft, which would help since the terse

Ok, I'll add some examples.

Thanks for these comments!

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Aug 2017 20:35:51 +0200 (CEST)

[Fixed address line, please reply to this email instead of the
previous one!]

Hi,

Thanks, I'll fix this.

/martin

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Aug 2017 11:44:35 -0700

> useful for clarity that would be fine with me.

Balazs brought up this issue as well.
There are 2 separate transitions and no reason to require both or none.

 1) use <get-data> instead of <get> to retrieve config=false nodes
 2) provide the operational values of config=true nodes

The capability URI indicates both are supported.
Without the capability URI, the server can still provide feature (1)

>   An NMDA-compliant server MUST support the operational state
OK

> statement in the YANG module, and this default value is being used by

OK -- then you will say the "with-defaults" query parameter is ignored?
causes
an error if used? something else?

The draft should clearly state the RESTCONF query parameters that apply to
the new /ds resource, and if they are different in any way.

> we propose is done for NETCONF.
OK

> Are you looking for something like the text in 1.4 in 8040?

Well it would be a start to say if this applies.
It is no different than using /restconf/operations/<netconf-operation> I
guess.

Andy