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

["Allen, Keith" <kallen@tri.sbc.com>]

Scott Lawrence wrote:

> I'm not sure that I understood your intent in this note.  Did you mean
> to say "identifying the operation type as _an_attribute_ in the
> element"?  

> Your example seemed to perform selection using an attribute defined as
> a part of the netcof schema (the 'select' attribute of the 'operation'
> element), but the operation type as an attribute in the data model.
> If those two are to be separated, that seems backwards to me.

That is what I meant.  I thought it was backwards at first, too.  Or at
least sideways.  I originally thought both the selection and the operation
type belonged in the 'operation' element.  I now think, though, that putting
the operation type with the element makes sense.  If you think about it,
it's really more object-oriented.  Every object-oriented system I know of
identifies an object in some standard way (pointer, reference, IOR, etc.)
but the operation types (methods) that may be performed on that object are
determined by the object's definition.

If we do it this way, the operations that may be performed on an XML element
are defined with the element.  Perhaps some elements are read only, so the
opType would be restricted to "read" for that element type.  One advantage
of doing it this was is that validating the element (including the opType
attribute) against the schema would catch illegal operations.

I was hung up on what the device would assign as the value of this attribute
when the device responed, or if you did a config file dump.  It doesn't
really matter, though.  The simplest approach would probably be to just make
the attribute optional and define a default value.  I suggest "write."
Then, the device could just leave it out when it responded.  If you did a
dump and then later wrote the contents back to the device, it would all be
written.

One thing I'm not sure about is if a group like this should try to define
all the possible opTypes, or to just leave the definition of the opTypes up
to the individual information model developers.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 

-----Original Message-----
From: Scott Lawrence [mailto:scott-xmlconf@skrb.org] 
Sent: Friday, May 16, 2003 11:10 AM
To: Allen, Keith
Cc: netconf
Subject: Re: Separation of configuration and control - good or bad?

"Allen, Keith" <kallen@tri.sbc.com> writes:

> I wrote:
>>> "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."
>
> Then Larry Menten wrote:
>> So what is the consensus on this issue?  I strongly favor using these 
>> attributes.
>
>
> Actually, I think I'm beginning to like the idea of identifying the
> operation type as a tag in the element.  When discussing this with
> my colleague Weijing Chen, he pointed out that it would allow the
> developers of the information model to identify their own operation
> types, and which operations could be applied to which elements in
> their XML schema.  I think this would lend a lot of flexibility to
> the protocol, and simplify the work of this group.

> Just to lend some concreteness to this, we think this would lead to
> instance documents that could look something like this:

I'm not sure that I understood your intent in this note.  Did you mean
to say "identifying the operation type as _an_attribute_ in the
element"?  

Your example seemed to perform selection using an attribute defined as
a part of the netcof schema (the 'select' attribute of the 'operation'
element), but the operation type as an attribute in the data model.
If those two are to be separated, that seems backwards to me.

-- 
Scott Lawrence        
  Actively seeking work 
  http://skrb.org/scott/
  [ <lawrence@world.std.com> is deprecated ]

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