Re: Where do we go from here?

[Rob Austein <sra+xmlconf@hactrn.net>]

Well, at the risk of both stating the obvious and adding yet another
spin vector to all this, let me add my two zorkmids.

The application in this space for which XML seems like a possible good
fit is configuration files.  I know this is the IETF and we do wire
protocols here, but sometimes we need to talk about files too.

We've got a bunch of protocols for fiddling with the state or
configuration of boxes on the fly, and I certainly would not want to
give those up, but when it comes right down to it, one is often much
more concerned with what a box will do after the next time it reboots
than with what it is doing right now.  I could state this in a more
extreme fashion: at least in my experience, when one is managing a
critical piece of equipment, the question of "will the box do the
right thing when it reboots?" is so important that the preferred way
of making configuration changes is to modify the box's configuration
file[*] then trigger a reboot to see whether the wretched thing comes
up correctly.

So when I hear people talking about XML configuration, what I think of
is (a) some kind of XML structure for this sort of thing and (b) a set
of templates (or schemas, or whatever the heck they're called in the
XML universe) that allow one to configure the things that every device
in a certain catagory will need to have configured.  XML certainly is
not the only way to build such a configuration file mechanism, but (as
others have mentioned) it has some nice properties and there are a lot
of tools available for it, so it's a potentially interesting approach.

SSH2 would be a fine way to ship such configuration files around, so I
suspect that Ran and I are at least partially on the same page here.

I'll let Margaret figure out how (and if) the above rant fits into her
overall taxonomy, she's better at that than I am.

[*] Yes, I am all too aware that some devices do not have disks or
    even much in the way of non-volatile storage.  But either (a) they
    have -something- in the way of some kind of structured
    non-volatile storage (even if it's only a small chunk of flash
    that contains a binary image of in-memory data structures for some
    programming language or another), (b) they can suck down a
    configuration file somehow (perhaps via TFTP with an HMAC
    integrity check), or (c) they really need to be configured on the
    fly every time they come up.  (c) is a prefectly reasonable way to
    build certain kinds of boxes, but perhaps their needs are
    sufficiently different that trying to configure such boxes with
    the same mechanisms we use to configure backbone routers is not a
    productive approach.

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