Re: [Netconf] RESTCONF modularilty

[Andy Bierman <[e-mail]>]

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 }
   }


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.

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