RE: I-D ACTION:draft-weijing-netconf-interface-00.txt

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

Kevin,

Splitting the "conceptual space of 'operations' (a.k.a. 'actions') across
both the operation model and data model" is done because draft-weijing tries
to address two perceived shortcomings with the first enns draft:

1. Splitting read-only (state) and read-write (config) information into
separate schema or separate parts of the schema.  We're afraid it will
become overly tedious to define, use, and maintain separate elements (e.g.
"interface") for state and config information.

2. The acknowledged ambiguity problem on overwrites that has been discussed
previously.

The fix for the ambiguity problem discussed on this email group seemed to be
to add an action on the element.  (I haven't checked the latest Enns draft
to see if this is what they have done.)  Earlier, though, when we had
proposed simply putting all actions on the elements (and thus placing the
conceptual space of operations solely in the data model instead of splitting
it) people were uncomfortable with the possibility of both a "read" and a
"write" operation in the same message.  So, we defined a specific message
type (read, write, etc.) but use the operation on the specific element both
to resolve ambiguity and to be more object-oriented.

I'm not sure what you mean when you say "the correct OOP decomposition of
'finer-grain actions' would be to sub-class a base operations object, not
inject 'verb/adverb' constructs (operations & operation modifiers) into the
'noun' space (data)."  The object-oriented systems with which I am familiar
include methods in the definition of each object class, along with data
attributes.  Thus, the "operation and operation modifiers" ARE "injected"
into the "noun space (data)," if I understand you.

One of the things we really like about the Enns draft is the way it enables
the use XML schema to define the information model of the device being
managed, and to enable that schema to be used to validate the management
messages.  It pretty much treats the XML data on the device as just data,
though.  Draft-weijing pushes to treat the elements in the XML infoset on
the device more as objects.  I think the disagreements here are over whether
this is appropriate, and if it is how to accomplish this.  I would like to
see opinions on this.


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

-----Original Message-----
From: Little, Kevin C (IP) [mailto:kclittle@enterasys.com] 
Sent: Monday, July 07, 2003 12:55 PM
To: Chen, Weijing; netconf@ops.ietf.org
Subject: RE: I-D ACTION:draft-weijing-netconf-interface-00.txt

Ref. 2.1.1, 4th paragraph: 
 
The operation attribute describes the actual operation request as one of the
following operations: get, create, modify, or delete. The further
description of each operation is depended on the data model. Recommendation
is that one attribute named "action" in the targeted element should specify
the finer-grain action (attribute-as-action).
 
And 2.1.1, 8th paragraph: 
 
The attribute "action" is closely associated with targeted element and
specified by data model instead of operation model, which makes interface
flexible and extensible. 
 
Why is the conceptual space of "operations" (a.k.a. "actions") split across
both the operation model and the data model? This doesn't seem right to me.
IMO, the correct OOP decomposition of "finer-grain actions" would be to
sub-class a base operations object, not inject "verb/adverb" constructs
(operations & operation modifiers) into the "noun" space (data).
 
Morphing the example at the bottom of p. 5 a bit, consider the following:
 
    <perform-request messageId="1234"
                     operation="get"
                     transaction="continue-on-error"
                     xmlns="http://www.ietf.org/mops";
                     xmlns:example="http://example.com/schema";>
      <example:running-config name="active">
        <example:ospf name="process 1">
          <example:area action = "get-next">
            <example:interface action="get-first">
              <address/>
              <adminStatus>"up"</adminStaus>
            </example:interface>
          </example:area>
        </example:ospf>
        <example:ospf name="process 45">
          <example:area action = "get-first">
            <example:interface action="get-next">
              <address/>
              <adminStatus>"up"</adminStaus>
            </example:interface>
          </example:area>
        </example:ospf>
      </example:running-config>
    </perform-request>
 
The outer most action looks to be a simple "get", but the two contained
"<example:ospf...>" (data-space!) fragments modify that, and do so in
different ways. One could argue that the meaning here can be well-defined
(we'd have to decide what a "get-next" inside a "get-first" should do), but
it is still confusing to me on first read (late at night, it could be
confusing on the 8th read...).
 
 "Attribute-as-operation", where the attribute is formally part of a data
schema but is nothing but a modifier of the semantics of an outer operation
element from another schema, might turn out to be a can of worms...
 
       -k
 


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