Re: netconf WG charter proposal

[Andy Bierman <abierman@cisco.com>]

At 07:01 PM 4/4/2003 +0200, Juergen Schoenwaelder wrote:

>>>>>> Andy Bierman writes:
>
>Andy> The Netconf Working Group is chartered to produce a protocol
>Andy> suitable for network configuration, with the following
>Andy> characteristics:
>
>Andy>    - Has a robust transaction model, based on remote procedure 
>Andy>      calls (RPC)
>
>I think I would agree with "the protocol must have the primitives to
>support network wide configuration transactions". Just saying "robust
>transaction model" might lead to nasty discussions later on.

okay 

>Furthermore, I do not understand why the charter requires RPCs. And in
>fact, JunoScript and xmlconf both seem to be just request/response
>protocols very similar to SNMP by the way. I fail to see real support
>for RPC abstractions in the classic sense. I suggest just to drop the
>text about RPCs - I do not find it convincing or helpful.

What is the difference between an RPC and a request that
carries zero or more input parameters, followed by a response
with zero or more output parameters? It is understood that
some work may be done on the device to produce the response,
and that the response may be delayed (hence the rpc-progress
reports).  This looks to me like an RPC model, not a generic
request/response model.


>Andy>    - Uses a data representation that is easily manipulated
>Andy>      using non-specialized text manipulation tools
>
>So XML is out if I take that text serious. XML documents have
>structure and to really operate on them, you need to have tools that
>understand the structure. The good news is that there is an increasing
>amount of such tools.

I will change the text to say XML will be used


>Andy>   - Provides support for multi-device configuration transactions
>Andy>     (with locking and rollback capability)
>
>So I probably mis-understood what the robust transaction model above
>was. This probably indicates a need for clarification. Anyway, does
>this item imply that locking and rollback capabilities are a required
>feature? If yes, I applaud (and look forward for an xmlconf revision
>that actually makes this mandatory).

These features are optional. Not all devices will be
capable of supporting them.


>Andy>    - Suitable for IP-reachable network devices
>
>Are you saying the protocol runs finally over IP? This is what
>everybody expects anyway, right?

this sentence will be removed, per Randy's comments


>Andy>    - XML namespace conventions
>Andy>    - XML usage guidelines
>
>If it is agreed that XML is the data encoding, then say so upfront
>rather than bringing it is sideways.

okay


>Andy> Although it should be possible to transport the Netconf protocol
>Andy> using several different protocols, the group will initially
>Andy> define a mapping for the Blocks Extensible Exchange Protocol
>Andy> (BEEP) [RFC 3080]. Future work may standardize other transport
>Andy> mappings.
>
>I do not recall that the operators were loudly asking for BEEP. So why
>is this initial (and I guess default) transport mapping already
>determined by the charter?

I don't recall operators being very specific in this matter.
The WG will need to discuss the appropriate initial transport
mapping.  If you are objecting to BEEP, then specify which 
protocol should be used in the initial release.  Should we
map more than one?  Being first doesn't imply a default.


>Andy> The working group will use the XMLCONF Configuration Protocol
>Andy> <draft-enns-xmlconf-spec-00.txt> as the starting point for this
>Andy> work.
>
>Personally, I would think that using JunoScript would be an even
>better base since it is a deployed protocol and does not suffer from
>the many options that were introduced in the xmlconf variation.

There is a valid reason for the base+extensions model that was
added to XMLCONF -- we need to be able to support devices from
lots of vendors, not just one.  It is not realistic to assume
all vendors will build products that are configured with the
exact same operational model and exact same capabilities.
The XMLCONF draft attempts to provide for market reality
using a small set of well-constrained extensions, which are
based on capabilities/device characteristics that are advertised
in a standard way.


>/js
>
>-- 
>Juergen Schoenwaelder    <http://www.iu-bremen.de/> 

Andy




--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>