Re: [Netconf] 4741bis -- :url capability issues

[Phil Shafer <[e-mail]>]

Andy Bierman writes:
>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.";
>           }

I may be missing something, but why can't I put text in <config>?
If my data model (which NETCONF doesn't care about) is text-based
config, can I not put that config directly in the <config> element?

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

The file contains data acceptable to the data model(s) supported
by the device.  You can say "go load that file" instead of putting
it inline with the <config> element.

>   Does it even have to be XML?

If should be any content that would be acceptable in a <config>
element.

>   There is no <get-config> support for a URL database,
>   so why should there be any partial database editing?

What's an "URL database"?

>   Since the URL file always represents a complete database,
>   there are no operations other than copy-config and delete-config
>   that apply to it.

You aren't editing an URL file, you are using a file as an alternative
to <config>.  That's why it's inside a "choice".

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

Again, what's an URL database?  This is a new concept not
currently in 4741.

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

Not sure I follow you here, but the scheme allows the server
to tell the client what it supports.  There is no SHOULD or
MUST, and MAY is pointless.

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

s/element/device/

s/someone/a client/

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

There are massive interoperability issues with "file:", but
clearly absolute paths are required (file:///), but that the
device need not allow direct access to its native file systems,
if any, so the device can use any file naming mechanism.  There
are no requirements in place re: directories, etc.  Given the
extreme range of networking gear, I'm not sure this is worth
diving into.

Thanks,
 Phil