Subject: Re: [Netconf] YANG Patch Optional or Mandatory

From: Kent Watsen <[email-masked]>
Date: Thu, 6 Mar 2014 15:47:37 +0000

For RESTCONF, I think YANG-Patch SHOULD be supported.

Why less than "MUST":

  1. The PATCH operation is optional in HTTP.  To require YANG-Patch would
also 
     require support for said operation.

  2. The PATCH operation only trades-off network bandwidth for
server-processing.
     Thus it is just a nice-to-have (PUT could be used instead)

  3. The afore-mentioned additional server-processing may not be
acceptable for
     resource-constrained devices, one of the purported targets for
RESTCONF.

Why more than "MAY":

  1. For large documents, the tradeoff mentioned above is easily worth-it

  2. Inspecting a PATCH document easily conveys intent, useful for auditing
     and troubleshooting

That said, I would be ok with the following statement:

    The RESTCONF server MAY implement the PATCH operation.  If a RESTCONF
    server supports the PATCH operation, it MUST at least support
YANG-Patch
    for all resources having Content-Type "application/yang.data+xml" or
    "application/yang.data+json".  In order for RESTCONF clients to
discover
    if a server supports the PATCH operation and which PATCH formats are
    supported, RESTCONF servers SHOULD return the "Accept-Patch" HTTP
header,
    As specified in RFC 5789.

Thanks,
Kent

From:  <Ersue>, "Mehmet   (NSN - DE/Munich)" <[email-masked]>
Date:  Thursday, March 6, 2014 2:22 PM
To:  NetConf <[email-masked]>
Subject:  [Netconf] YANG Patch Optional or Mandatory

Dear NETCONF WG,
 
there was a discussion in the IETF #89 NETCONF session on whether YANG
patch for the RESTCONF protocol should be optional or mandatory.
Although we heard different opinions there was no final conclusion.
 
The chairs would like to raise this discussion again to come to an
agreement for the way forward.
Please state your opinion with pro and contra.
 
Thanks,
Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Mar 2014 07:59:49 -0800

>      Thus it is just a nice-to-have (PUT could be used instead)

I do not agree.
The ability to apply changes all-or-none can be critical,
depending on the data model.  If changes to multiple resources
are needed then plain PATCH may not work.

This is one of the ways that network management can not be
treated as if the operation is patching a static XML document.

Andy

> From:  <Ersue>, "Mehmet   (NSN - DE/Munich)" <[email-masked]<javascript:;>
> >
> To:  NetConf <[email-masked] <javascript:;>>
> _______________________________________________
> Netconf mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Mar 2014 17:13:21 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
>   1. The PATCH operation is optional in HTTP.

Yes, in a "general-purpose server" (RFC 2616).  In fact, only GET and
HEAD are mandatory in "general-purpose servers".   But this is not a
general purpose server, and we decide which methods MUST be implemented.

>      To require YANG-Patch would
>      also 

We could use POST instead.

I think we should ask some APPS folks about guidance - should we use
PATCH or not.

>      Thus it is just a nice-to-have (PUT could be used instead)

This is not scalable, and has issues with access control.  If I am not
allowed to read/write everything, I can't PUT, and thus not change
anything.

/martin

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 7 Mar 2014 09:32:08 +0000

> general purpose server, and we decide which methods MUST be

I am new to this conversation. However, as far as I understood some comments yesterday in the ALTO sessions, there seems to be single suggestions that RESTCONF, or parts of it, could be used in other working groups with different use cases and requirements, such as ALTO.
 
Mandating an optional and complex HTTP method that is not supported by existing running code (at least in ALTO) would certainly be an excellent reason for such other WGs not to use RESTCONF at all.

Michael

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 7 Mar 2014 12:24:41 +0000

Michael,

Can you please clarify what would be the use case for ALTO to use RESTCONF?  PATCH method enable partial update , when the client just wants to change one part of the resource state.

Yes, you can achieve same functionality with GET of the state and then PUT the entire thing back with the updated value. This is pretty heavy operation. PATCH is lighter case.

Dean
On Mar 7, 2014, at 9:32 AM, "Scharf, Michael (Michael)" <[email-masked]> wrote:

> [email-masked]

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 7 Mar 2014 13:04:10 +0000

> Can you please clarify what would be the use case for ALTO to use
> RESTCONF?

Well, I currently try to figure out that question myself. I am new to RESTCONF, and obviously it has not been me who has suggested this.

However, in ALTO yesterday I've raised the question on the mic whether RESTCONF is a protocol as simple as ALTO, and I've been told so. Mandating the support of HTTP patch seems to contradict that statement.

>  PATCH method enable partial update , when the client just
> wants to change one part of the resource state.

ALTO doesn't change resource states. It reads network topology information and allows certain kinds of query/ranking operations. In my current understanding, such use would not require HTTP patch.
 
> Yes, you can achieve same functionality with GET of the state and then
> PUT the entire thing back with the updated value. This is pretty heavy
> operation. PATCH is lighter case.

ALTO only uses GET and POST (see draft-ietf-alto-protocol-27).

Michael

> Dean
> On Mar 7, 2014, at 9:32 AM, "Scharf, Michael (Michael)"
> <[email-masked]> wrote:
> 
> > I am new to this conversation. However, as far as I understood some
> comments yesterday in the ALTO sessions, there seems to be single
> suggestions that RESTCONF, or parts of it, could be used in other
> working groups with different use cases and requirements, such as ALTO.
> >
> > Mandating an optional and complex HTTP method that is not supported
> by existing running code (at least in ALTO) would certainly be an
> excellent reason for such other WGs not to use RESTCONF at all.
> >
> > Michael
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Mar 2014 20:20:12 +0100 (CET)

Hi,

"Scharf, Michael (Michael)" <[email-masked]> wrote:
> Well, I currently try to figure out that question myself. I am new to RESTCONF,
> and obviously it has not been me who has suggested this.
> 
> However, in ALTO yesterday I've raised the question on the mic whether RESTCONF
> is a protocol as simple as ALTO, and I've been told so. Mandating the support
> of HTTP patch seems to contradict that statement.

Obviously, if the RESTCONF server only supports read-only data models,
it doesn't need to support PUT or PATCH.  This should be be clarified
in the document.

> ALTO doesn't change resource states. It reads network topology information and
> allows certain kinds of query/ranking operations. In my current understanding,
> such use would not require HTTP patch.

Right.

> ALTO only uses GET and POST (see draft-ietf-alto-protocol-27).

Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the
data model from the protocol, and "just" define a YANG module with the
necessary data:

  module ietf-alto {
    ...
    container alto {
      container network-map {
        list netloc {
          ...
        }
      }
      container cost-map {
        ...
      }
    }
  }

It should be noted that RESTCONF currently does not support a "query"
interface like the "filtered"-thingie in ALTO.  However, I believe
such a mechanism should be addded to RESTCONF.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Mar 2014 16:58:31 -0800

Hi,

Maybe SHOULD instead of MUST is OK.
I realized that confirmed-commit is totally optional to implement,
and that has not stopped developers who want to support
network rollback in the device.

The market may favor devices with complete APIs over incomplete ones.
Devices with severely broken or unusable editing capabilities should not
stay around long.  Small devices that need to reload an entire subtree
(maybe even the whole config) with a PUT may only disrupt themselves,
not the entire network.

Andy

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 9 Mar 2014 11:32:24 +0000

> it doesn't need to support PUT or PATCH.  This should be be clarified

Yes, I think read-only access should be made simple, if non-configuration use of RESTCONF should become relevant.

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 9 Mar 2014 13:04:50 +0000

Regarding the "network": In ALTO use cases, there can be HTTP proxies on the path between client and server, because they can be located in different domains.

I don't fully understand so far whether proxies could be an issue if we used (parts of) RESTCONF.

Michael

From: Andy Bierman [mailto:[email-masked]]
Sent: Saturday, March 08, 2014 1:59 AM
To: Martin Bjorklund
Cc: Scharf, Michael (Michael); Netconf
Subject: Re: [Netconf] YANG Patch Optional or Mandatory

Hi,

Andy

On Fri, Mar 7, 2014 at 11:20 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Right.

  module ietf-alto {
    ...
    container alto {
      container network-map {
        list netloc {
          ...
        }
      }
      container cost-map {
        ...
      }
    }
  }

/martin

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