[Netconf] 4741bis -- :url capability issues

[Andy Bierman <[e-mail]>]

Hi,

Here are more issues for 4741bis:

1) :url as a source for <edit-config>
   (Martin already raised this issue)

         choice edit-content {
           mandatory true;
           anyxml config {
             description
               "Inline Config content: 'config' element.
                This is not full 'anyxml' because the <config>
                element cannot directly contain a text node.";
           }
           leaf url {
             if-feature url;
             type inet:uri;
           }
         }

   The edit-config operation allows <url> as a source,
   but there is no explanation what the file has to contain.
   Does it even have to be XML?

   There is no <get-config> support for a URL database,
   so why should there be any partial database editing?
   Since the URL file always represents a complete database,
   there are no operations other than copy-config and delete-config
   that apply to it.

   Proposed solution:
     - Delete 'url' as a source for <edit-config>
     - Delete section 8.8.5.1.


2) There is no lock support at all for URL databases, so it is 
   not even clear that copy and delete are properly supported.

   Issue: Should <url> be allowed in <lock> and <unlock>
   operations?

3) :url interoperability

   It is not clear what a client application should expect
   for any given scheme, or what schemes a server SHOULD
   or even MAY support.

   Issue: is the :url capability interoperable?
   If not, what should be done about it?

4) :url security considerations

   The security considerations for external database representations
   of NETCONF configurations are ignored, which should probably be
   fixed, if anybody knows what to write.

   Current text:

       Similarly, just because someone says "go write a configuration
       through the URL capability at a particular place", this does not mean
       that an element should do it without proper authorization.

   Issue:  Are the security considerations clear enough or are
   more details needed?  (e.g., file system permissions for 'file' scheme,
   clear-text on-the-wire for 'ftp' and 'http' schemes.

5) 'file' scheme

   It is not clear whether:
     - absolute path specs must be supported by the server
     - the path-spec represents a conceptual file-system in 
       the server, or the real file-system.
     - sub-directories must be supported
     - how many sub-directory levels deep are allowed
     - other restrictions apply, such as naming, number of files, etc.
     - if the internal mirrored NV-store is really a file,
       whether this file is accessible via the <url> parameter.
     - if the external :startup config is accessible via the <url> 
       parameter.

   Issue: are any guidelines needed for the 'file' scheme?
   This is the most likely scheme to be supported by a server.



Andy