[Netconf] RESTCONF modularilty

[Kent Watsen <[e-mail]>]

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

Recapping the NETCONF Light strategy, the YANG module defined the follow features:

     feature get-config {
       description
        "This feature indicates that the server supports the
         <get-config> protocol operation, albeit without subtree
         filtering.   The server must additionally advertize
         the \"subtree-filtering\" feature to enable subtree
         filtering.  Alternatively, if the server only wants
         to support XPath filtering, it may just advertize
         the :xpath capability.";
     }

     feature subtree-filtering {
       description
        "This feature indicates that the server supports subtree
         filtering for the <get-config> operation.  This
         feature is only meaningful if the "get-config" feature
         is advertized; if "get-config" is not also advertized,
         this feature MUST be ignored.";
     }

     feature edit-config {
       description
        "This feature indicates that the server supports the
         <edit-config> protocol operation.  If the server is
         unable to support all the <edit-config> attributes
         (merge, replace, create, delete, remove), then it
         should advertize the \"copy-config\" feature instead.";
     }

     feature copy-config {
       description
        "This feature indicates that the server supports the
         <copy-config> protocol operation.";
     }

     feature delete-config {
       description
        "This feature indicates that the server supports the
         <delete-config> protocol operation.";
     }

     feature locking {
       description
        "This feature indicates that the server supports the
         <lock> and <unlock> protocol operations.";
     }

     feature get {
       description
        "This feature indicates that the server supports the
         <get> protocol operation.";
     }

     feature close-session {
       description
        "This feature indicates that the server supports the
         <close-session> protocol operation.  When this feature
         is not advertized, clients are expected to close the
         underlying transport directly.";
     }

     feature kill-session {
       description
        "This feature indicates that the server supports the
         <kill-session> protocol operation.";
     }



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