Subject: bug or feature?

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Dec 2007 00:05:43 +0100 (CET)

Hi,

The XSD in RFC 4741 allows <startup> as <target> in an <edit-config>.
It is not clear if this a bug in the XSD or a feature.  Section
8.7.5.1 lists the operations the server MUST support for the :startup
capability, but it doesn't say that the server MAY support others.  So
is this intentional or not?  (if the intention was that the server MAY
support this, how would a manager know?)

Another related bug (or feature) is that the XSD supports <startup> as
<target> in <delete-config>.  In section 7.4 there is actually an
example where this is used.  But is this really supposed to be
supported?  It is not listed in 8.7.5.1.

/martin

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Fri, 07 Dec 2007 08:24:40 -0500

>support this, how would a manager know?)

This is definitely a bug.  The intention was to not allow editing
of the startup config, since it was really just a chunk of flash
memory and isn't loaded into a real database.

>supported?  It is not listed in 8.7.5.1.

My initial reaction here is that this is a bug.  Startup represents
a section of flash memory, and deleting it IIRC isn't possible.  My
memory is fuzzy, but I don't think we intended to allow this.  The
fact that it's in an example conflicts this, so maybe my memory's off.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 07:33:45 -0800

> fact that it's in an example conflicts this, so maybe my memory's off.

I remember many WG discussions about this.
RFC 4741 is supposed to allow <startup> to be edited or deleted,
but not mandate it by the agent implementor.

IMO, there is absolutely no use case for editing the <startup>.
There is some use for deleting a corrupted <startup>, but minor.
If the agent SW is buggy, such that *it* is responsible for the
<startup> corruption, then <copy-config> may not work to fix it.
Perhaps something in the <startup> is causing the bug to show up,
or even cause a reboot.

Perhaps in some implementation, deleting the <startup> could allow
the agent to boot 'far enough' to reload a previous SW image, and
then recover the config to <running> somehow.

>  Phil

Andy

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 7 Dec 2007 10:53:32 -0500

Hi Andy,

> then recover the config to <running> somehow.

Practically, what would it mean to delete the <startup>  
configuration?  To overwrite it with all zeros?  Or do we require  
that the <startup> configuration include some type of flag indicating  
whether it is there or not?

Margaret

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 08:15:10 -0800

Margaret Wasserman wrote:
> Practically, what would it mean to delete the <startup> configuration?  
> To overwrite it with all zeros?  Or do we require that the <startup> 
> configuration include some type of flag indicating whether it is there 
> or not?
> 

Sec. 8.7.5.1 does not list <delete-config> as a mandatory
operation.  In any case, this is clearly an implementation detail.

The bug is the <get-config> on <startup>.

This text in sec. 7.1 was added to cover the text vs. XML format:

    If the configuration is available in multiple formats, such as XML
    and text, an XML namespace can be used to specify which format is
    desired.  In the following example, the client uses a specific
    element (<config-text>) in a specific namespace to indicate to the
    server the desire to receive the configuration in an alternative
    format.  The server may support any number of distinct formats or
    views into the configuration data, with the client using the <filter>
    parameter to select between them.

      <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
          <source>
            <running/>
          </source>
          <filter type="subtree">
            <!-- request a text version of the configuration -->
            <config-text xmlns="http://example.com/text/1.2/config"/>
          </filter>
        </get-config>
      </rpc>

I really don't like this approach at all.
I really want to think of each configuration database
as just a different instance of the same sort of database,
like <candidate> and <running>.  I would return 'operation-not-supported'
for a <get-config> on <startup>, instead of returning the
text in a <config-text> QName, as RFC 4741 suggests.

Note the 'can be used' text instead of the more proper MUST/SHOULD/MAY.
IMO, this text means MAY.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 07 Dec 2007 14:52:23 -0500

>but not mandate it by the agent implementor.

edited?  That's certainly not my recollection.

>Perhaps something in the <startup> is causing the bug to show up,

Trying to predict the likely work around for random bugs isn't
a good idea.

Thanks,
 Phil