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

[Andy Bierman <[e-mail]>]

Phil Shafer wrote:
> Andy Bierman writes:
>   
> ...
>>   There is no <get-config> support for a URL database,
>>   so why should there be any partial database editing?
>>     
>
> What's an "URL database"?
>   

Good question.
The standard does a really awful job of explaining that.

It is awkwardly defined as:
  1) an edit-content choice for edit-config
  2) a source or target config-choice option for copy-config
  3) a target of delete-config (Note that the current draft is
      wrong wrt/ delete-config -- Sec. 7.4 does not exclude 'candidate'
      as a target, but ietf-netconf.yang does exclue it.
 4) config-source choice option for validate

If I were learning NETCONF, I would think <url> was supposed
to be supported as a database because most the operations that
affect it have 'config' in the name.

But unlike <startup>, you cannot retrieve data with <get-config>,
or lock it before using it as the target of a <copy-config>,
or find out what <url> values the server will allow,
or what values are currently in use (as a hint).

The examples in E.1.2 do not really help much.
I think the example is wrong:

     <url>file://incoming.conf</url>


Correct:

   <url>file://localhost/incoming.conf</url>

or

   <url>file:///incoming.conf</url>


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

OK -- except the external file will not validate correctly if
it contains nc:operation attributes, so this sort of edit-config
is likely to be restricted to a top-level merge or replace.

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

change database to 'file representation of a complete database'.

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

Not pointless to an NMS developer who has to write
code to utilize :url on different servers.  It's the same
reason we picked a mandatory transport (SSH) -- for
the benefit of the client, not the server.

IMO, HTTP and FTP are awful choices, and SHOULD NOT
be supported.  I am surprised the IESG review of 4741
let that go in the security section review.

In one section we explain how NETCONF requires a secure
transport (2.2 & 2.3,  although it says must instead of MUST),
and in another we give examples of passing the entire config
contents over-the-wire in clear-text. (!)


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

IMO, the entire SC text for :url needs to be rewritten.
I guess that means I volunteer to add some text in 4741bis-03.


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

Yep -- it's a tar-baby.
A server is free to do whatever it wants.
Client developers: RTFM and figure it out.

IMO, simple <backup> and <restore> operations
would be better, but too late now.


> Thanks,
>  Phil
>
>   

Andy