Re: bug or feature?

[Andy Bierman <ietf@andybierman.com>]

Margaret Wasserman wrote:
> Hi Andy,
>
> On Dec 7, 2007, at 10:33 AM, Andy Bierman wrote:
> > 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.
>
> 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.

> Margaret

Andy


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