Re: [Netconf] RESTCONF modularilty

On Fri, Aug 22, 2014 at 10:37 AM, Kent Watsen <kwatsen@juniper.net> wrote:

>
>  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.
>
>
NETCONF is problematic because of backward compatibility.
That is why the NETCONF-EX "encoding" capability is part of the
<hello> message.  The first message needs to be XML encoding
using base:1.0 message framing. Framing and encoding switch after
the <hello> message.

Andy

>   From: Wojciech Dec <wdec.ietf@gmail.com>
> Date: Thursday, August 21, 2014 at 1:30 PM
> To: Ladislav Lhotka <lhotka@nic.cz>
> Cc: Kent Watsen <kwatsen@juniper.net>, NetConf <netconf@ietf.org>
> Subject: Re: [Netconf] RESTCONF modularilty
>
>
>
>
> On 21 August 2014 16:26, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> Kent Watsen <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
>> > https://www.ietf.org/mailman/listinfo/netconf
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>