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