Re: [Netconf] RESTCONF modularilty

[Ladislav Lhotka <[e-mail]>]

On 21 Aug 2014, at 17:12, Andy Bierman <[e-mail]> wrote:

> 
> 
> 
> On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka <[e-mail]> wrote:
> Hi,
> 
> Kent Watsen <[e-mail]> 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?
> 
> 
> I support this strategy as well. We made all 9 groups of RMON optional
> and let the market decide how to best deploy RMON-MIB.  Turned out
> that "RMON-Lite" was very useful.
> 
>  Option 1:  custom lists:
> 
>    container restconf {
>         container modules {  ... currently in tree ... }
>         container capabilities  { ... new ... format TBD }
>         container query-parameters { new ... format TBD }
>    }
> 

If the set of capabilities is open-ended then I would go for this option as it is the most flexible. Capability descriptions could then have more structure than a simple URI.

> 
> Option 2: back to simple list of URIs
> 
>      container restconf {
>         container capabilities  {
>             leaf-list capability { same as in ietf-netconf-monitoring }
>         }
>      }
> 
> 
> Option 3: Require implementation of the ietf-netconf-monitoring 'capability' node
> 
>      /restconf/data/netconf-state/capabilities/capability
>      ** This probably requires a 6022bis to make the
>          monitoring stats support NETCONF and RESTCONF
> 
> 
>  ** 2 & 3 require URI definitions for each query parameter and official protocol capability
> 
> 
> ...
> 
> >
> > 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?
> 
> This approach doesn't work if each person picks their pet options to
> be mandatory.  Everything is optional, even XML. One might want
> to support only JSON and not implement XML.

This is what I am saying.

Lada

> 
> I would make read-only vs read-write vs read-create/delete 3 separate
> capabilities (server MUST support 1 of them)
> 
>   read-only: GET
>   read-write: GET, PUT
>   read-create: GET, POST, PUT, DELETE
> 
> I think this aligns better with capabilities of constrained devices.
> 
> 
> 
> 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)
> >
> 
> Some of these are traditionally client-side tasks.  They should be optional.
> HTTP already makes PATCH optional. All query parameters should be optional.
> 
> 
>  
> >
> > Thoughts?
> >
> > Thanks,
> > Kent
> >
> 
> Andy
>  

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