Re: Deja vu Again

[Phil Shafer <phil@juniper.net>]

"David T. Perkins" writes:
>> 1) what can be changed during operation of the device versus what
>>     can only be changed by device reset.
>> 2) does a config modification operation change both the "running"
>>     config and the "persistent" config, or is a explicit 
>>     operation needed to cause running to be copied to persistent

Or is it commit-based?

>> 3) are there more than one copy of persistent config, and if so,
>>     then how are they named and managed?
>> 4) are default values supported (that is, are incomplete
>>     configuration allowed)?

How can default values for discovered or changed?

>> 5) how are configurations removed?

How are vendor-specific operations defined/discovered/invoked?

>>What part of the above are to be standardized?
>Now, lets do the minimum, which is define a "standard" way
>to get the complete config in XML format from a box. If this
>is the only goal, is it valuable?

Not if the customer is deploying 20MB config files ;^)

Having some sort of add/delete/replace mechanism will be required,
soon if not initially.  JUNOS uses attributes on elements of the
configuration for this:

<rpc>
  <load-configuration action="replace">
    <configuration>
      <system>
        <login replace="replace">
           <user>
             <name>phil</name>
             <class>white-hat</class>
           </user>
        </login>
        <name-server delete="delete"/>
        <services>
           <ssh inactive="inactive"/>
        </services>
      </system>
    </configuration>
  </load-configuration>
</rpc>

>>To be able to intelligently display and edit this stuff with
>>a single tool would be another step forward.
>I can't see using an "off the shelf" XML editor with a DTD
>per device type. I believe that a config editor is custom
>code that has built into it the semantics of the device.

The question is how much of the semantics can be put into the
Schema? Emacs doesn't grok everything in C, but it knows enough to
know how far to indent the next line. The Schema can give the editor
all is needs to know to allow the creation of a syntactically correct
configuration, but adding sufficient information to allow the editor
to tie the pieces together is the trick.

For example, JUNOS uses a path-reference element under the schema's
<xsd:appinfo> element to point an identifier at the set of things
it is identifying. The 'filter' statement for an interface
has a path reference to the firewall filter statement where
the given filter would have to be defined. The editor, knowing
nothing about what a filter is, can ensure that one exists.

Not that that's the most interesting application, since it means
working at a vendor-specific level.

More interesting is the scenario where you've got a customer network
fully or partially described in a database and you connect to that
database using an XML API, pull out the configuration, run it thru
vendor/platform/release-specific transformations and ship the
results to the device.

Thanks,
 Phil

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