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

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Apr 2010 19:25:41 -0700

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

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?

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?

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.

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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Apr 2010 12:35:59 +0200 (CEST)

Hi,

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

>      - Delete section 8.8.5.1.

I agree.  Also, Appendix D must be rewritten.

>    Issue: Should <url> be allowed in <lock> and <unlock>

No.

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

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

>      - absolute path specs must be supported by the server

This could be clarified.

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

>        whether this file is accessible via the <url> parameter.

Implementation issue.

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

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.

>    This is the most likely scheme to be supported by a server.

Yes, I think this is a good idea.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 30 Apr 2010 10:34:04 -0400

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

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

>   so why should there be any partial database editing?

What's an "URL database"?

>   there are no operations other than copy-config and delete-config

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

>   Issue: Should <url> be allowed in <lock> and <unlock>

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

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

>       that an element should do it without proper authorization.

s/element/device/

s/someone/a client/

>   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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Apr 2010 10:02:56 -0700

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

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

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

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.

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

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

> Again, what's an URL database?  This is a new concept not

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.

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

> extreme range of networking gear, I'm not sure this is worth

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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Apr 2010 23:31:26 +0200 (CEST)

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

The problem with this that in the <config> element, you may have
several child elements, e.g.:

  <config>
    <interface xmlns="urn:ietf...:inteface">
      ...
    <interface>
    <nacm xmlns="urn:ietf....nacm">
      ...
    </nacm>
  </config>

If you just copy the stuff in the <config> element and put it into a
file, you will get an invalid XML document.  Now, this may not be a
problem, but if this is something we want to support in an
interoperable way, we need to define how this should work.

(But I don't think this is an important feature, and would rather see
it removed.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Apr 2010 15:48:58 -0700

Martin Bjorklund wrote:
>> ....

The IETF is moving forward with YANG and standard
NETCONF data models will use YANG.

Technically, a 4741 server can contain a string.
That does not mean we have to allow that  in 4741bis,
now that we are using YANG instead of continuing
with an ad-hoc opaque content layer.

Since the 'single-string' <config> is completely
incompatible with YANG modules, there is no role
for such a server implementation in the standard.

But we can remove the description-stmt text in question,
and be silent on this issue.  It is a market decision
whether or not a vendor wants to sell a NETCONF server
that can never implement a YANG module.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Apr 2010 18:41:28 -0700

> An implementation detail IMO.

The problem is that way too much of the :url capability
is left as an implementation detail.

There is no way for a client/operator to know from
the standard:
   - what file restrictions are enforced by the server
   - what URL files even exist (the monitoring module
     only supports candidate, running, and startup).

We usually try to announce server capabilities in
the protocol instead of forcing users to call
tech-support, or fish through WEB docs to find out
the same information.

Seems like it would be useful to know what local <url>
database files are available at any given time.
I thought this was supported in the monitoring draft.
I guess locks do not apply, so the existing <database>
element is not appropriate.

Andy