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

[Martin Bjorklund <[e-mail]>]

Hi,

Andy Bierman <[e-mail]> wrote:
> 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?

But this is url as *source*, not target.  url as target is not
supported by 4741 (actually, it is allowed by the XSD, but not
according to the text).

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

I agree.  Also, Appendix D must be rewritten.

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

No.

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

I don't know if it is interoperable, but it does make sense to list
the schemes we expect implementations to support, and for each scheme,
specify how it should be supported.

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

It is probably a good idea to point out the clear-text on-the-wire
issue.

> 5) 'file' scheme
> 
>    It is not clear whether:
>      - absolute path specs must be supported by the server

This could be clarified.

>      - the path-spec represents a conceptual file-system in 
>        the server, or the real file-system.

An implementation detail IMO.

>      - sub-directories must be supported

No MUST.

>      - how many sub-directory levels deep are allowed

No requirements.

>      - other restrictions apply, such as naming, number of files, etc.

Implementation issue. e.g. filesystem dependent.

>      - if the internal mirrored NV-store is really a file,
>        whether this file is accessible via the <url> parameter.

Implementation issue.

>      - if the external :startup config is accessible via the <url> 
>        parameter.

Implementation issue.

We keep track of 'rollback files', which can be accessed using this
parameter.  We also have a proprietary data model to list the files
available.

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

Yes, I think this is a good idea.


/martin