Subject: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

From: "Seehofer, Markus" <[email-masked]>
Date: Tue, 11 Dec 2018 14:17:07 +0000

Hello,

Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text.

1.       RFC 8342 (NMDA)
Chapter 5.3.  The Operational State Datastore (<operational>) says:
"The operational state datastore (<operational>) is a read-only datastore ... "
Chapter 6.2. Invocation of Actions and RPCs says:
"Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore."

Chapter 3.1 in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 says:
"YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational."

Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something?

2.       The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores
in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says:
"A PUT on the datastore resource is used to replace the entire contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy
the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?

3.       Typo in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."
There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".

Best Regards,
Markus Seehofer
------------------------------------------------------------------------------------
Dipl.-Ing. (FH) Markus Seehofer - [email-masked]

**********************************************************************
DISCLAIMER:
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2018 15:33:13 +0100

On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:
> "The operational state datastore (<operational>) is a read-only datastore .... "

Why do you expect that a datastore has to be writable in order to
invoke an action? RFC 7950 has the example of a ping action tied to an
interface. (You ping a remote system from that specific interface.)
In general, actions are understood as being tied to real resources and
hence to the operational datastore. (For example, you can't ping from
an interface that is configured but not physically present.)

> the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?

A PUT does not really get you there, to copy a datastore to another
you want an operation on the server.
 
> There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".
 
Lets hope we get this fixed with the help of the RFC editor.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Seehofer, Markus" <[email-masked]>
Date: Tue, 11 Dec 2018 14:55:10 +0000

Hello Juergen,

see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging.
So please apologize for "simple" questions or ones maybe already raised.

-----Ursprüngliche Nachricht-----
Von: Juergen Schoenwaelder [mailto:[email-masked]]
Gesendet: Dienstag, 11. Dezember 2018 15:33
An: Seehofer, Markus
Cc: [email-masked]
Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:
> Chapter 3.1 in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= says:

Why do you expect that a datastore has to be writable in order to invoke an action? RFC 7950 has the example of a ping action tied to an interface. (You ping a remote system from that specific interface.) In general, actions are understood as being tied to real resources and hence to the operational datastore. (For example, you can't ping from an interface that is configured but not physically present.)

[MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only".

> "A PUT on the datastore resource is used to replace the entire
> contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?

A PUT does not really get you there, to copy a datastore to another you want an operation on the server.

[MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with <copy-config> but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would
               be possible too. Or do I still miss something?

> 3.       Typo in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 11 Dec 2018 16:05:30 +0000

Hi Seehofer,

Please see inline ...

On 11/12/2018 14:55, Seehofer, Markus wrote:
>> "The operational state datastore (<operational>) is a read-only datastore ...."

RPCs and actions don't modify the operational state datastore as such, 
instead they modify the properties of the underlying system, and the 
operational state datastore provides a read-only view onto the state of 
the system.  So <operational> is only being updated as a side effect of 
reflecting the changes to the underlying system.

This contrasts with writable configuration datastores (e.g. <candidate> 
or <running>), where the client can modify the configuration in those 
datastores directly which will then attempt to change the behavior of 
the system as the config is applied.

>                 be possible too. Or do I still miss something?

I think that it is theoretically possible to invoke the NETCONF RPCs 
(e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from 
RESTCONF (e.g. section 3.6 of RFC 8040).

Whether this is actually a good thing to do/encourage I'm not so sure.

Thanks,
Rob

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2018 17:14:47 +0100

> [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore…

Is your question 'how do I do actuall invoke an operation/action'?
Well, RFC 8040 talks about 'operation resource' and that you POST to
them. What NMDA RESTCONF I think says is that such an invocation is
executed in the context of the operational state datastore.

>                be possible too. Or do I still miss something?

I think this was discussed at some point but then dropped. It may work
to implement ietf-netconf (or the copy-config defined in there) to get
direct access to NETCONF operations.

/js

---

From: "Seehofer, Markus" <[email-masked]>
Date: Tue, 11 Dec 2018 17:11:16 +0000

Hello Juergen,

comments inline below.

-----Ursprüngliche Nachricht-----
Von: Juergen Schoenwaelder [mailto:[email-masked]] 
Gesendet: Dienstag, 11. Dezember 2018 17:15
An: Seehofer, Markus
Cc: [email-masked]
Betreff: Re: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

On Tue, Dec 11, 2018 at 02:55:10PM +0000, Seehofer, Markus wrote:
> interface. (You ping a remote system from that specific interface.) In 
> general, actions are understood as being tied to real resources and 

Is your question 'how do I do actuall invoke an operation/action'?
Well, RFC 8040 talks about 'operation resource' and that you POST to them. What NMDA RESTCONF I think says is that such an invocation is executed in the context of the operational state datastore.

[MSEE]: No I guess I understood how to invoke an operation/action but I'm stuck with the following statements:
               - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with
                  "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore (<operational>) is a read-only datastore"
               - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and
                 "An action is invoked as: POST {+restconf}/data/<data-resource-identifier>/<action>"

               So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"?
              
>                be possible too. Or do I still miss something?

I think this was discussed at some point but then dropped. It may work to implement ietf-netconf (or the copy-config defined in there) to get direct access to NETCONF operations.

[MSEE]: Thanks, this could work. Haven't thought about that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=iyd1IgmqNVNO9Nlyjn_0i4tRy8l_6sfEwqtRJvqEtPA&s=TFP1iqry2-5IRNGuTpQGZ_O4zo3yvwU823NqKOPSSZ0&e=>

---

From: "Seehofer, Markus" <[email-masked]>
Date: Tue, 11 Dec 2018 17:21:50 +0000

Hello Robert,

comments inline below.

BR
 Markus 

-----Ursprüngliche Nachricht-----
Von: Robert Wilton [mailto:[email-masked]] 
Gesendet: Dienstag, 11. Dezember 2018 17:06
An: Seehofer, Markus
Cc: [email-masked]
Betreff: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Hi Seehofer,

Please see inline ...

On 11/12/2018 14:55, Seehofer, Markus wrote:
> Von: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF 
> extension (draft-ietf-netconf-nmda-restconf)
>
>
>

RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So <operational> is only being updated as a side effect of reflecting the changes to the underlying system.

This contrasts with writable configuration datastores (e.g. <candidate> or <running>), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied.

[MSEE]: I agree but I'm still stuck with the following text.

>                 be possible too. Or do I still miss something?

I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040).

[MSEE]: OK. But what is the preferred way for someone implementing RESTCONF on a device who would like to have the support of <candidate>, <startup>, <running> and the new ones defined in NMDA.
               How does one copy the data from <running> to e.g. <startup> using the mechanisms RESTCONF has defined in RFC 8040? From reading the RFC it seems is out of scope of RFC 8040 but is this really intended? 
               Implementing ietf-netconf.yang of course could be an option. 

Thanks,
Rob

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netmod&d=DwIDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv
> 1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=TrPMVXQ5IovFm08BS
> bbXa2E-HnSO_yzHRy0GR9djT2M&s=sd11onHA42ODnysz9ZOIZikWWQMHkHwUSeL-lNWck
> DE&e=

---

From: Robert Wilton <[email-masked]>
Date: Wed, 12 Dec 2018 10:21:08 +0000

Hi Markus,

>                 So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in…

So, you invoke it on the equivalent path using the operational datastore.

E.g. to take the example from RFC 8040 3.6.2, the request pre NMDA is this:

       POST /restconf/data/example-actions:interfaces/\
          interface=eth0/get-last-reset-time HTTP/1.1
       Host: example.com
       Accept: application/yang-data+json

The equivalent path on a NMDA server is this:

       POST /restconf/ds/ietf-datastores:operational/\
          example-actions:interfaces/\
          interface=eth0/get-last-reset-time HTTP/1.1
       Host: example.com
       Accept: application/yang-data+json

I think that your concern might be: why is it right/OK to invoke a 
action on what is defined as a read only structure?

The answer to this is that the action isn't acting on <operational>, it 
is acting on the underlying system and has the remit to change any of 
the system behavior.

However, before the action can be processed, the system must validate 
that the data node that it is acting on exists, and the parameters are 
valid.  This validation is performed against the systems operational 
state, and hence is validated against <operational>.

Again, considering the example above, it wouldn't make sense to get the 
last reset time of an interface that existed in configuration, and hence 
was present in <running>/<intended>, but was not in <operational>.

In future we may need actions that are validated against other 
datastores, but when the authors were discussing this it was unclear 
whether proper use cases for such actions exist, and hence we decided 
that this could be deferred to future work, which would presumably come 
along with a concrete use case.

>                 Implementing ietf-netconf.yang of course could be an option.

I agree that this isn't really specified.

IIRC our initial focus was to effectively get parity with RFC 8040.  
I.e. my working assumption is that <candidate> (if present) would be 
handled automatically and similarly updates to <startup> would be 
handled automatically.  E.g. broadly equivalent to the /data resource in 
RESTCONF.  So in essence this boils down to clients interacting with 
/ds/ietf-datastores:running, /ds/ietf-datastores:operational and 
/ds/ietf-datastores:intended. No new RESTCONF operations should be 
necessary here.

I'm also not really convinced that independently controllable <startup> 
and <candidate> is really a great idea.

Given that <running> is meant to represent persistent configuration, 
then automatically updating <startup> as a side effect of updating 
<running> seems like the most sensible behavior.  If the desire is for 
some ephemeral type configuration then that would be better modeled via 
an explicit dynamic configuration datastore (e.g. a bit like what I2RS 
were trying to do).

Similarly, instead of a shared candidate datastore, there is some work 
investigating private candidate datastores. 
draft-lhotka-netconf-restconf-transactions-00 gives some ideas of what 
this could look like, but further work is required.

If there is a strong requirement to allow full explicit manipulation of 
configuration datastores then I think that we should probably define 
explicit RPCs for these operations (modeled on the NETCONF ones).  
Ideally, these could be defined in a protocol neutral format so that 
they can work with any YANG based management protocols.  In the interim, 
using the NETCONF RPCs from RESTCONF seems like a reasonable stopgap 
measure.

Thanks,
Rob

---

From: "Seehofer, Markus" <[email-masked]>
Date: Wed, 12 Dec 2018 14:40:36 +0000

Hello Robert,

Von: Robert Wilton [mailto:[email-masked]]
Gesendet: Mittwoch, 12. Dezember 2018 11:21
An: Seehofer, Markus; [email-masked]
Betreff: [EXTERNAL] Re: AW: [netmod] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Hi Markus,

Hello Robert,

comments inline below.

BR

 Markus

-----Ursprüngliche Nachricht-----

An: Seehofer, Markus

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

Hi Seehofer,

Please see inline ...

Hello Juergen,

-----Ursprüngliche Nachricht-----

An: Seehofer, Markus

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

Hello,

1.       RFC 8342 (NMDA)

      Host: example.com

      Host: example.com

I think that your concern might be: why is it right/OK to invoke a action on what is defined as a read only structure?

[MSEE]:  Exactly. By just reading "The operational state datastore (<operational>) is a read-only datastore ...." may be confusing. I still struggle with the text.

The answer to this is that the action isn't acting on <operational>, it is acting on the underlying system and has the remit to change any of the system behavior.

However, before the action can be processed, the system must validate that the data node that it is acting on exists, and the parameters are valid.  This validation is performed against the systems operational state, and hence is validated against <operational>.

[MSEE]: I agree, this of course makes sense as only the <operational> datastore has the informations which nodes are in use and therefore are available for usage.

Again, considering the example above, it wouldn't make sense to get the last reset time of an interface that existed in configuration, and hence was present in <running>/<intended>, but was not in <operational>.

[MSEE]: Yes, I agree.

In future we may need actions that are validated against other datastores, but when the authors were discussing this it was unclear whether proper use cases for such actions exist, and hence we decided that this could be deferred to future work, which would presumably come along with a concrete use case.

[MSEE]: OK.

[MSEE]: Along with the above questions and answers/statements (thanks for this) I probably still have more questions than answers from reading the RFCs and drafts.

-          Draft draft-ietf-netconf-nmda-restconf-05 says:
“An NMDA-compliant server MUST implement {+restconf}/ds/ietf-datastores:operational.  Other datastore resources MAY be implemented”.
Does this mean a GET to {+restconf}/data} (which is still valid) returns the same data as a GET to {+restconf}/ds/ietf-datastores:operational if it is NMDA compliant?

-          If such a NMDA compliant RESTCONF server has e.g. “example-jukebox” implemented, are both of the following statements correct?

     PATCH /restconf/data/example-jukebox:jukebox/\
         library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
     Host: example.com
     If-Match: "b8389233a4c"
     Content-Type: application/yang-data+xml
     <album xmlns="http://example.com/ns/example-jukebox">
      <year>2011</year>
     </album>

and

PATCH /restconf/ds/ietf-datastores:operational/example-jukebox:jukebox/\
   library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If-Match: "b8389233a4c"
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox">
<year>2011</year>
</album>

-        Draft draft-ietf-netconf-nmda-restconf-05 says:
          “ YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational”
          In such a NMDA compliant RESTCONF server, is {+restconf}/operations (RFC8040 - 3.6 Operation Resource )still valid? Because the above statement says “…can only…” or does one have to use:

POST {+restconf}/ds/ietf-datastores:operational /<operation>
and
POST {+restconf}/ds/ietf-datastores:operational /<data-resource-identifier>/<action>
on a NMDA compliant server only?

IIRC our initial focus was to effectively get parity with RFC 8040.  I.e. my working assumption is that <candidate> (if present) would be handled automatically and similarly updates to <startup> would be handled automatically.  E.g. broadly equivalent to the /data resource in RESTCONF.  So in essence this boils down to clients interacting with /ds/ietf-datastores:running, /ds/ietf-datastores:operational and /ds/ietf-datastores:intended.  No new RESTCONF operations should be necessary here.

I'm also not really convinced that independently controllable <startup> and <candidate> is really a great idea.

Given that <running> is meant to represent persistent configuration, then automatically updating <startup> as a side effect of updating <running> seems like the most sensible behavior.  If the desire is for some ephemeral type configuration then that would be better modeled via an explicit dynamic configuration datastore (e.g. a bit like what I2RS were trying to do).

Similarly, instead of a shared candidate datastore, there is some work investigating private candidate datastores.  draft-lhotka-netconf-restconf-transactions-00 gives some ideas of what this could look like, but further work is required.

If there is a strong requirement to allow full explicit manipulation of configuration datastores then I think that we should probably define explicit RPCs for these operations (modeled on the NETCONF ones).  Ideally, these could be defined in a protocol neutral format so that they can work with any YANG based management protocols.  In the interim, using the NETCONF RPCs from RESTCONF seems like a reasonable stopgap measure.

[MSEE]: I agree, this would be helpful.

BR
Markus

Thanks,
Rob

Thanks,

Rob

/js

--

Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>

netmod mailing list

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

DE&e=

DISCLAIMER:

---

From: Robert Wilton <[email-masked]>
Date: Wed, 12 Dec 2018 15:10:14 +0000

Hi Markus,

On 12/12/2018 14:40, Seehofer, Markus wrote:
>
> Hello Robert,
>
> *Von:*Robert Wilton [mailto:[email-masked]]
> *Gesendet:* Mittwoch, 12. Dezember 2018 11:21
> *An:* Seehofer, Markus; [email-masked]
> *Betreff:* [EXTERNAL] Re: AW: [netmod] Re: Question on RFC8342 + 
> RESTCONF extension (draft-ietf-netconf-nmda-restconf)
>
> **
>
> Hi Markus,
>
>     Cc:[email-masked]  <mailto:[email-masked]>
>
>         Cc:[email-masked]  <mailto:[email-masked]>
>
>             Chapter 3.1 inhttps://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e=  says:
>
> [MSEE]:  Exactly. By just reading "The operational state datastore 
> (<operational>) is a read-only datastore ...." may be confusing. I 
> still struggle with the text.
>
RW: I guess that you can think of <operational> just being a view on to 
the underlying system state.  I.e. you are allowed to use an action to 
modify the underlying state which, as a side effect, updates 
<operational> (because it always reflects the system state), but you 
cannot write to <operational> as an attempt to update the underlying 
system state.

>
> The answer to this is that the action isn't acting on <operational>, 
> it is acting on the underlying system and has the remit to change any 
> of the system behavior.
>
> [MSEE]: I agree, this of course makes sense as only the <operational> 
> datastore has the informations which nodes are in use and therefore 
> are available for usage.
>
> Again, considering the example above, it wouldn't make sense to get 
> the last reset time of an interface that existed in configuration, and 
> hence was present in <running>/<intended>, but was not in <operational>.
>
> [MSEE]: Yes, I agree.
>
> that this could be deferred to future work, which would presumably 
> come along with a concrete use case.
>
> [MSEE]: OK.
>
> [MSEE]: Along with the above questions and answers/statements (thanks 
> for this) I probably still have more questions than answers from 
> reading the RFCs and drafts.
>
> -Draft draft-ietf-netconf-nmda-restconf-05 says:
> “An NMDA-compliant server MUST implement 
> {+restconf}/ds/ietf-datastores:operational.  Other datastore resources 
> MAY be implemented”.
> Does this mean a GET to {+restconf}/data} (which is still valid) 
> returns the same data as a GET to 
> {+restconf}/ds/ietf-datastores:operational if it is NMDA compliant?
>
RW: The definition of {+restconf}/data} has not changed in any way.  So, 
the contents/behavior of {+restconf}/data} should match what is 
specified by RFC 8040.

But this is tricky (because /data mixes intended configuration with 
operational state).

Hence, I wouldn't be surprised if some implementations either:
(1) don't implement /data at all, or
(2) handle DELETE/POST/PATCH/PUT operations as if the operation was made 
against {+restconf}/ds/ietf-datastores:running, handle GET requests as 
if they the operation was made against on 
{+restconf}/ds/ietf-datastores:operational.  This would be non-standard 
behavior though ....

A future version of RESTCONF, as opposed to an extension (i.e. 
draft-ietf-netconf-nmda-restconf-05), may remove support for 
{+restconf}/data}.

>
> -If such a NMDA compliant RESTCONF server has e.g. “example-jukebox” 
> implemented, are both of the following statements correct?
>
>                   “ YANG actions can only be invoked in
>         {+restconf}/ds/ietf-datastores:operational”
>                   In such a NMDA compliant RESTCONF server, is
>         {+restconf}/operations (RFC8040 - 3.6 Operation Resource
>         )still valid? Because the above statement says “…can only…” or
>         does one have to use:
>
RW:

No, you can't PATCH against <operational>.  PATCH is not a YANG action, 
it is a RESTCONF method.

It is covered by draft-ietf-netconf-nmda-restconf-05, section 3.2:

    o  Some datastores are read-only by nature (e.g., <intended>), and
       hence any attempt to modify these datastores will fail.  A server
       MUST return a response with a "405 Method Not Allowed" status-line
       and error-tag value "operation-not-supported".

>         on a NMDA compliant server only?
You can only POST against editable configuration datastores, e.g. 
<candidate>, <running>,<startup>, and only then if the server allows this.

Thanks,
Rob

>             2.       The NMDA is a huge step forward for NC and RC,
>             thanks for that. NMDA in combination with the new RESTCONF
>             extensions let one now select one of the named datastores
>
> handled automatically. E.g. broadly equivalent to the /data resource 
> in RESTCONF.  So in essence this boils down to clients interacting 
> with /ds/ietf-datastores:running, /ds/ietf-datastores:operational and 
> I'm also not really convinced that independently controllable 
> <startup> and <candidate> is really a great idea.
>
> some ephemeral type configuration then that would be better modeled 
> via an explicit dynamic configuration datastore (e.g. a bit like what 
> I2RS were trying to do).
>
> If there is a strong requirement to allow full explicit manipulation 
> of configuration datastores then I think that we should probably 
> define explicit RPCs for these operations (modeled on the NETCONF 
> ones).  Ideally, these could be defined in a protocol neutral format 
> so that they can work with any YANG based management protocols.  In 
> the interim, using the NETCONF RPCs from RESTCONF seems like a 
> reasonable stopgap measure.
>
>             3.       Typo inhttps://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e=  Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."
>
>         Fax:   +49 421 200 3103<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>
>
>         [email-masked]  <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this 
> message. If you are not the addressee of this message, you may not 
> copy, use or deliver this message to anyone. In such event, you should 
> destroy the message and kindly notify the sender by reply e-mail. It 
> is understood that opinions or conclusions that do not relate to the 
> official business of the company are neither given nor endorsed by the 
> company. Thank You.

---

From: "Seehofer, Markus" <[email-masked]>
Date: Wed, 12 Dec 2018 15:20:59 +0000

Thank you very much Robert. Your answers are really helpful.

BR
Markus

Von: Robert Wilton [mailto:[email-masked]]
Gesendet: Mittwoch, 12. Dezember 2018 16:10
An: Seehofer, Markus; [email-masked]
Betreff: [EXTERNAL] Re: AW: Re: AW: [netmod] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Hi Markus,

Von: Robert Wilton [mailto:[email-masked]]
Gesendet: Mittwoch, 12. Dezember 2018 11:21
An: Seehofer, Markus; [email-masked]<mailto:[email-masked]>
Betreff: [EXTERNAL] Re: AW: [netmod] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Hi Markus,

Hello Robert,

comments inline below.

BR

 Markus

-----Ursprüngliche Nachricht-----

An: Seehofer, Markus

Hi Seehofer,

Please see inline ...

Hello Juergen,

-----Ursprüngliche Nachricht-----

An: Seehofer, Markus

Hello,

1.       RFC 8342 (NMDA)

      Host: example.com

      Host: example.com

RW: I guess that you can think of <operational> just being a view on to the underlying system state.  I.e. you are allowed to use an action to modify the underlying state which, as a side effect, updates <operational> (because it always reflects the system state), but you cannot write to <operational> as an attempt to update the underlying system state.

[MSEE]: Yes, I agree.

[MSEE]: OK.

RW: The definition of {+restconf}/data} has not changed in any way.  So, the contents/behavior of {+restconf}/data} should match what is specified by RFC 8040.

But this is tricky (because /data mixes intended configuration with operational state).

Hence, I wouldn't be surprised if some implementations either:
(1) don't implement /data at all, or
(2) handle DELETE/POST/PATCH/PUT operations as if the operation was made against {+restconf}/ds/ietf-datastores:running, handle GET requests as if they the operation was made against on {+restconf}/ds/ietf-datastores:operational.  This would be non-standard behavior though ....

A future version of RESTCONF, as opposed to an extension (i.e. draft-ietf-netconf-nmda-restconf-05), may remove support for {+restconf}/data}.

-

     PATCH /restconf/data/example-jukebox:jukebox/\
         library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
     Host: example.com
     If-Match: "b8389233a4c"
     Content-Type: application/yang-data+xml
     <album xmlns="http://example.com/ns/example-jukebox"<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_ns_example-2Djukebox&d=DwMDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=IQZ3gVb5SlkQ0SorJQeIG9D3trfQrNh2mtSCStXJf8U&s=0ifcjgWDrgm2cSSui9E4IQLHK3y2e1-zsrJo_9ol6Rw&e=>>
      <year>2011</year>
     </album>

and

PATCH /restconf/ds/ietf-datastores:operational/example-jukebox:jukebox/\
   library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If-Match: "b8389233a4c"
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox"<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_ns_example-2Djukebox&d=DwMDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=IQZ3gVb5SlkQ0SorJQeIG9D3trfQrNh2mtSCStXJf8U&s=0ifcjgWDrgm2cSSui9E4IQLHK3y2e1-zsrJo_9ol6Rw&e=>>
<year>2011</year>
</album>

RW:

No, you can't PATCH against <operational>.  PATCH is not a YANG action, it is a RESTCONF method.

You can only POST against editable configuration datastores, e.g. <candidate>, <running>,<startup>, and only then if the server allows this.

Thanks,
Rob

BR
Markus

Thanks,
Rob

Thanks,

Rob

/js

--

netmod mailing list

DE&e=

DISCLAIMER:

________________________________
DISCLAIMER:
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.