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

[Andy Bierman <[e-mail]>]

Phil Shafer wrote:
> 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?
>
>   


The NETCONF database is XML.
Standard YANG modules will add child elements to
the <config> element.  Your string database will
be incompatible will all YANG modules.  None of the
filtering or editing operations work on a text <config>
element.

I don't see why the standard should support pointless
or awful data modeling practices.  We forbid XSD list
and XML attributes because they are 'bad practices'.


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

There is no text in the RFC that treats file contents
differently -- that means they are not different.
That means they must have correct standard contents,
exactly as if the XML was delivered on-the-wire
instead of read from a file.


>   
>>   Does it even have to be XML?
>>     
>
> If should be any content that would be acceptable in a <config>
> element.
>   

Since NETCONF forbids mixed content,
the server either has XML contents or
is a single string.  I suppose if a vendor
wanted to pretend they really support NETCONF,
then a single text string database would seem
like a good idea.  No YANG module could ever be
supported by that vendor.


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

an entry in the monitoring data model <databases> element
will exist for each <url> database.  This can be the source
or target of any copy-config operation.  Again, NETCONF
does not make any distinction between copying to <running>
or copying to file:///foo.xml.


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

You can only provide URL as a source and it represents
an entire config, which is redundant -- the only thing you
can do with edit-config(url) is what you can already do
with copy-config(url).


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

User A: copy-config A to C
User B: copy-config B to C

locking applies to URL as a target just as much as
it applies to the other databases.  I don't understand
why 'hoping for the best' is an acceptable write-collision
strategy for :url, but not for other write targets.


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


At some point, NETCONF will attempt to advance to Draft Standard.
At that time, we will be forced to assess NETCONF interoperability.
Entire sections will be tossed out at that time, unless there are
2 independent inter-operating implementations.


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

IMO, the :url capability is not interoperable and should
be removed from NETCONF, but since we are cycling at
Proposed Standard it is not important.

> Thanks,
>  Phil
>
>   
Andy