Re: Separation of configuration and control - good or bad?

[Larry Menten <lmenten@lucent.com>]

Phil,

I'd like to see this in a future draft in place of the root-level 
merge/replace/overlay
operations currently specified in the draft.  I proposed the 
alternative, earlier, and
Keith responded:

"I think a problem with this would be that the write-option tag would have to
be an attribute of elements that are not defined by this group and will not
be defined by this group.  The write-option tag would be mixing the protocol
used to transfer configuration data in with the configuration data itself."

So what is the consensus on this issue?  I strongly favor using these 
attributes.

Phil Shafer wrote:

> Larry Menten writes:
>  
> > The idea presented is that the
> > configuration operations be modeled as direct modifications to a
> > tree of configuration information.
> >    
> Configuration content is certainly underspecified in the draft, mostly
> because this was seen as future work. I'd be happy to see the
> attribute-based configuration operations from Junoscript added to the
> draft, which I think will answer most of your points. Here's an
> example from a previous email:
>
> <configuration xmlns="http://xml.juniper.net/junos/5.4I0/junos";>
>  <protocols>
>    <ospf>
>      <exports>
>        <export insert="before" name="bar">foo</export>
>      </exports>
>      <areas>
>        <area active="inactive">
>          <name>0.0.0.1</name>
>        </area>
>        <area>
>          <name>0.0.0.0</name>
>          <interfaces>
>            <interface replace="replace">
>              <name>135.104.52.3</name>
>              <hello-interval>10</hello-interval>
>            </interface>
>            <interface delete="delete">
>              <name>135.104.52.2</name>
>            </interface>
>          </interfaces>
>        </area>
>      </areas>
>    </ospf>
>  </protocols>
> </configuration>
>
> Replace, delete, insert, copy, and rename operations are supported
> inside a <load-configuration> (the Junoscript equivalent of
> <set-config>) operation. The goal was to allow the functionality of
> 'patch' inside a single operation.
>
> The statement in
>  
> > the proposed guidelines that recommends that elements for which
> > more than one sibling instance can appear should be collected in
> > an element representing the array suggests to me that they might
> > be using an object serialization/restoration design pattern to
> > construct the candidate configuration data structures from the
> > configuration file.
> >    
> Not at all. It's just that in Junoscript we've got cases with and
> without the enclosing element and our experience is that having
> such container elements makes life easier (for some unspecified value
> of 'easier').
>  
You ought to try the serialization/restoration approach.  It is compact 
and efficient.  ;  )

> Thanks,
> Phil
>  
Larry

--
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


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