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

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

[Hand-approved because the sender address was different from the
 subscription address.  Sorry for the delay-- Simon.]

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?  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.

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.

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.

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
 


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