Re: netconf WG charter proposal

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

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

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.

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

Andy>    - Suitable for IP-reachable network devices

Are you saying the protocol runs finally over IP? This is what
everybody expects anyway, right?

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.

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?

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.

/js

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

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