Re: [Netconf] RESTCONF modularilty

I also agree XML/JSON should be on equal footing.   I like Andy's idea of having them both optional to implement.  I can easily imagine cases where an implementation only want to support a single encoding, perhaps one NETCONF supports in the future.

From: Wojciech Dec <wdec.ietf@gmail.com<mailto:wdec.ietf@gmail.com>>
Date: Thursday, August 21, 2014 at 1:30 PM
To: Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>>
Cc: Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>>, NetConf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [Netconf] RESTCONF modularilty

On 21 August 2014 16:26, Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>> wrote:
Hi,

Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>> writes:

> The RESTCONF authors recently discussed adding support for filtering,
> sorting, and paging collections (i.e. lists).  One comment was that it
> was complex and better defined in another draft.  I agree, but more
> importantly, RESTCONF should be fully modular, providing an ability
> for implementations to selectively advertise support for various
> things.  This is exactly the approach we used for the NETCONF Light
> draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but
> RESTCONF being a new protocol, there is no reason to not do it from
> the get go.  This strategy was discussed in Toronto, but we felt we
> should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities
will be indicated somehow under the "restconf" resource?

...

>
> The corollary to RESTCONF might be:
>
>     Base Support
>           - the ability to GET and PUT on the top-level node using XML only
>
>     Optional Support:
>           - the ability to do PATCH  (this is already optional)
>           - the ability to use JSON encoding

I think XML and JSON should be given equal footing, i.e. the server
could support either or both. Perhaps the "Accept" header on the client
side and 406/415 status codes on the server side could be enough?

+1 re XML and JSON on equal footing.

Lada

>           - the ability to POST/GET/PUT/DELETE subtrees   (PATCH too, is support for it is advertised)
>           - the ability to use "select" with GET operations
>           - the ability to use "filter" with GET on collection resources (i.e. lists) and event streams
>           - the ability to do pagination with GET on collection resources (i.e. lists)
>           - the ability to do sorting with GET on collection resources (i.e. lists)
>
>
> Thoughts?
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org<mailto:Netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf