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

From: Andy Bierman <[email-masked]>
Date: Sat, 01 May 2010 12:31:47 -0700

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

---

From: Phil Shafer <[email-masked]>
Date: Sat, 1 May 2010 17:00:42 -0400

>The standard does a really awful job of explaining that.

The standard does not use that term.  IMHO these were meant
as files, not databases.  This seems plain since, e.g. an url cannot
be the target of an edit-config.

Thanks,
 Phil