RE: Separation of protocol and information model

["Allen, Keith" <Keith_Allen@labs.sbc.com>]

Juergen,

You understand me correctly.  I think both approaches allow a device to have
multiple named configurations, or not, and to allow a vendor to create their
own named configurations with special semantics associated to them.  In the
current WG draft, the target may be either <running>, <startup> or
<candidate> or it may simply be any URL you wish.  (Defining your own target
with an XML tag seems to be a little trickier as you have to extend the XML
schema substitution group defined for targets.  I'm not sure exactly how
this works.  A simple URL seems to be the way to go, though.)  I guess the
vendor would simply supply you with a list of valid URLs you could include
as targets, and they would specify the special semantics associated with
each.  In our approach the vendor would define additional configurations as
part of their XML schema, including their allowed contents.

The ability to define multiple named configurations was not our concern with
the current WG draft.  One of our concerns was that the specification of
those named configurations, including <running> or <startup> or whatever,
should be up to the vendor and not imposed by the protocol.  Granted, every
device does have a <running> configuration and technically the protocol does
not require a device to support the other named configurations.  They can
opt out by reporting in their capabilities schema that they don't support
them.  Still, the startup, running, and candidate named configurations are
built into the protocol.  Many devices may not support them, so we don't
feel they should be built in like that.


Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com
 


> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Thursday, September 04, 2003 11:23 AM
> To: Keith_Allen@labs.sbc.com
> Cc: netconf@ops.ietf.org
> Subject: Re: Separation of protocol and information model
> 
> 
> >>>>> Allen, Keith writes:
> 
> [...]
> 
> Keith> The two messages really convey the same request.  There are,
> Keith> however, some important differences.  The most obvious is that
> Keith> in the first example the <running> and <users> elements are
> Keith> separate, but in the second the <users> element is contained in
> Keith> the <running> element.  Also, in the first example <running> is
> Keith> part of the message's standard name space, and in the second it
> Keith> is part of the device's name space.  That is, in the first it
> Keith> is part of the NETCONF standard message definition and in the
> Keith> second it is part of the XML "MIB" defined by the device
> Keith> supplier (in this case, example.com).
> 
> If I understand you right, then you are saying rather than having
> multiple named configurations (and some names might have special
> semantics attached to them, such as "running" or "startup", it would
> be better to have just one config and to structure the config space
> into "running", "startup" or whatever people like.
> 
> Personally, I do not see the big difference for named configurations.
> What I consider more important is how we distinguished between named
> configurations ("config-that-used-to-work-until-yesterday") and
> configurations that carry special semantics with them "running",
> "startup". There should be rules that allow to distinguish an
> arbitrary named configuration from something that has special
> properties. And I think the question is whether vendors are allowed
> to create their own named configurations with special semantics
> associated to them.
> 
> /js
> 
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
> Germany


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