Andy, in the middle, you write:
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.
I would hope that this is actually more of a generic request/response model. The enns draft had a marvelous diamond buried in it - the notion of capabilities. That is most definitely a request/response paradigm. Add the concept of registration services, and you're definitely doing requests and responses.
regards,
John
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO 80903 USA
phone: +1.719.785.0648
FAX: +1.719.785.0644
email: john.strassner@intelliden.com
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Friday, April 04, 2003 11:57 AM
To: Juergen Schoenwaelder
Cc: xmlconf@ops.ietf.org
Subject: Re: netconf WG charter proposal
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/>