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

[Andy Bierman <abierman@cisco.com>]

At 02:36 PM 7/3/2003, Chen, Weijing wrote:
>Andy,
>
>Both the Enns and Weijing drafts sort of skip over the "lets gather
>requirements" phase and go straight into proposing a solution.  That's
>probably ok, why get bogged down in arguing over what's a requirement? 

Actually, the IETF spent about 2 years soliciting comments from
network operators.  I doubt every detail got documented, but they
are mostly captured in RFC 3535, especially section 3.  For
example, the separation of config and state data is captured
in section 3, requirement 2.

> As
>engineers, I think it is easier for us to study a possible solution and
>argue over its merits than to sit around and argue about what's a
>requirement.  We wanted to propose a solution that is more in line with our
>philosophy towards the design of network management protocols while still
>meeting the "requirements."
>
>I guess to summarize our philosophy, I would say we think that a management
>protocol should be divided into two parts, a basic set of management
>"operations" and an "information model" that defines the manageable
>capabilities of a device.  Probably no argument there.  Where I think we may
>begin to disagree, however, is that we feel the management operations should
>be as simple and flexible as possible, with the information model being the
>focus for defining the complexity of the device.  Wherever possible, our
>preference would be to make the protocol simpler and the information model
>more complex.

I'm not focusing on complexity right now, but rather interoperability.
I want the protocol to contain enough standard functionality to
be genuinely useful.  It has to be specified in unambiguous 
detail so multiple independent implementations will interoperate.

Separating the data model work from the protocol work is
a pragmatic choice designed to increase the WG focus.
I think standard data models for common features are
needed just as much as this protocol.  Just because
version 1 of netconf will leave the data models unspecified
doesn't mean that the protocol itself should be loosely
specified.

The netconf-interface draft does not mention an operational
model (e.g., candidate, running, startup config, capabilities
exchange, multiple channels).  These are also important aspects
of the standard.

There is a big difference between flexibility (let the
vendors decide) and extensibility (modular functionality
based on standardized capabilities).  


>As an example, take the issue of killing a user session on a device.  The
>enns draft defines a standard "state data" information model that every
>device is expected to support (section 10).  It includes session entities
>that represent each user logged into a device.  One way of killing a session
>is to define a special "kill session" operation, as enns does.  Another way
>is to use the basic "delete" capability of the protocol and simply delete
>the session.  Our preference would be for the latter.  It simplifies the
>protocol at some expense of complicating the information model a bit.

In either case, you have to identify the session to be killed.
The xmlconf-state schema provides the session-IDs of all
active sessions and all active locks.  The point of
the <kill-session> operation is to kill somebody else's
session who is holding a lock too long.


>The advantage to our approach is that it makes the protocol simpler, which
>is always a good thing, but without at least a basic standard information
>model interoperability flies out the window.  Of course, without standard
>information models interoperability flies out the window, anyway, so I'm not
>sure this is a huge penalty.

It doesn't work out to be simpler for the application developer
in the end if there is little commonality across vendor agent
implementations.  And even commonality doesn't help much
if the protocol feature set isn't rich enough.


>If I had my way the group would:
>        1. Agree that it is going to define a management operations
>protocol.
>           (This has been done.)
>        2. Agree that it is going to define a basic standard information
>           model. (Some precedence set in enns.)
>        3. Agree that wherever possible it would seek to simplify the
>protocol
>           and increase the complexity of the information model.
>        4. Start with a very simple protocol and information model such as 
>           that proposed in the Weijing draft.
>        5. Add to it capabilities that we feel are "required" (such as the 
>           ability to kill a user session) by first trying to see if it
>could 
>           be done by adding to the standard information model.  Then, only
>if 
>           it turned out to be impossible or too painful to meet the 
>           "requirement" by adding to the information model would we add a
>new 
>           message or capability to the underlying protocol.
>
>
>Sincerely,
>
>Keith Allen
>SBC Labs
>9505 Arboretum Blvd.
>Austin, TX 78759
>(512) 372-5741
>keith_allen@labs.sbc.com
> 

Andy



>-----Original Message-----
>From: Andy Bierman [mailto:abierman@cisco.com] 
>Sent: Wednesday, July 02, 2003 5:40 PM
>To: Ted Goddard
>Cc: Allen, Keith; netconf@ops.ietf.org
>Subject: Re: I-D ACTION:draft-weijing-netconf-interface-00.txt
>
>I tend to agree with you on many points below, but
>before getting into any of that, I would like the
>authors of draft-weijing-netconf-interface-00.txt
>to explain why they think we should use their draft
>as the starting point instead of the xmlconf draft.
>The charter says we will use the xmlconf draft as
>a starting point.  I personally don't see any
>real advantages, and in some cases a lack of
>specificity that would make multi-vendor 
>interoperability less likely.
>
>As for the netconfsoap draft, this does not really
>conflict with the xmlconf draft.  It addresses the
>transport issue, which is totally open at this time.
>
>Andy
>
>
>
>
>--
>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/> 


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