Subject: Re: [netconf] RFC8040 inquiries

From: Anton Snitser <[email-masked]>
Date: Mon, 7 Oct 2019 11:28:35 +0000

Hello Everyone,

My name Is Anton Snizar, I am a System engineer working for Sedona Systems.

I have a foundational question regarding the RESTCONF specification. I have not seen anywhere in the document whether it is required to provide a synchronous or asynchronous interface? Or maybe you have left it for the implementor to decide?

For Non-NMDA (unified datastore) RESTCONF (RFC 8040) it is stated that only a 201 created status code will valid to be used when new objects are created/configured. With that in mind, should one treat this as an implicit definition to make the interface synchronous? E.g., only upon resource creation in the network will a 201 be sent to the NBI client?

At the moment we implement a synchronous RESTCONF interface but at the same time wondering support for async for some optimization considerations. As were wondering whether it would still be compliant to the standard or not.. Any clarification would be helpful.

Hanks,
Best regards

[id:[email-masked]]
Anton Snizar | Systems Engineer 
m: +972-504042744
e: [email-masked]<mailto:[email-masked]>
w: sedonasys.com<https://sedonasys.com/>
l: Linkedin<http://linkedin.com/in/anton-snizar-4aa57646/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Oct 2019 14:21:39 +0200 (CEST)

Hi,

Anton Snitser <[email-masked]> wrote:
> I have a foundational question regarding the RESTCONF specification. I
> have not seen anywhere in the document whether it is required to
> provide a synchronous or asynchronous interface? Or maybe you have
> left it for the implementor to decide?
> 
> For Non-NMDA (unified datastore) RESTCONF (RFC 8040) it is stated that
> only a 201 created status code will valid to be used when new objects
> are created/configured. With that in mind, should one treat this as an
> implicit definition to make the interface synchronous? E.g., only upon
> resource creation in the network will a 201 be sent to the NBI client?

It depends on what you mean with synchronous.  An implementation may
write the new resource to its internal db and then reply with 201.
But that doesn't mean that the new resource is "used" or "applied" at
that point in time, so in that sense it can be viewed as
asynchronous.  Some other implementation might not return 201 until
the resource is really applied.

/martin

> At the moment we implement a synchronous RESTCONF interface but at the
> same time wondering support for async for some optimization
> considerations. As were wondering whether it would still be compliant
> to the standard or not.. Any clarification would be helpful.
> 
> Hanks,
> Best regards
>

---

From: Anton Snitser <[email-masked]>
Date: Mon, 7 Oct 2019 12:37:42 +0000

Hello Martin,

Thank you for the reply..

Yes. This is exactly what I mean by sync/async. At the moment we reply with a 201 when the resource is applied/created on the network devices as to remain in sync with the network state. I want to understand whether the decision to do one approach or the other is a MUST to be compliant or left to the implementor at the implementation stage? 

To make my question simpler, is there are definitive one way? Or both are valid?

Again, I appreciate you taking the time to answer.

Best regards

On 07/10/2019, 15:22, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Oct 2019 14:46:31 +0200 (CEST)

Hi,

Anton Snitser <[email-masked]> wrote:
> Yes. This is exactly what I mean by sync/async. At the moment we reply
> with a 201 when the resource is applied/created on the network devices
> as to remain in sync with the network state. I want to understand
> whether the decision to do one approach or the other is a MUST to be
> compliant or left to the implementor at the implementation stage?
> 

At the moment, this is not defined in any RFC, which means that both
behaviours are ok.

When we did the NDMA, there were some discussions around this (e.g.,
adding a parameter to let the client control the behaviour), but
nothing has been done.  However, with the NMDA, the client can at
least detect if a certain piece of config has been applied, but
checking the value of the config node in <operational>.

/martin