Re: XMLCONF Proposal

[Phil Shafer <phil@juniper.net>]

Harrie Hazewinkel writes:
>Why using RPC and not for instance SOAP over HTTP??

There are a number of reasons. The ones that pop into 
my head are:

  SOAP lacks the connection-oriented aspect we've found
  simplifies locking, debugging, and session recovery.

  Using HTTP/HTTPS makes firewalling more difficult.

  We needed multiple channels for control and notifications.

  The benefits of XMLCONF wrapped in SOAP wrapped in HTTP/HTTPS
  weren't clear to us.

All of this solvable, but BEEP more closely matched our needs and made
a better initial target protocol.

>Maybe it is wise to seperate that layer from the
>XMLCONF protocol so various mappings can exist.

We separated the BEEP mapping into its own section, but didn't want to
pull it out into a distinct document at this point. We may
later. Certainly future mappings will be in separate documents.

>As a transport you mantion various protocols in a figure in
>section 1.1. Later you use the concept of channels.
>Why adding RPC between the operations layer and transport
>layer if you could use BEEP directly and providing you the
>channels??

We wanted to make it possible to run XMLCONF with other (non-BEEP)
protocol mappings. In other mappings, the channels would likely be
distinct socket connections, rather than being multiplexed over a
single BEEP connection.

>Section 2.2 speaks about authentication and privacy.
>However, the use of privacy is not explained. They are
>left out of this document, but I am interested in seeing
>this somehow.

We're relying on the underlaying protocol to provide authentication
and privacy. In 2.2, we only list our requirements for that protocol.
For XMLCONF-over-BEEP, we use TLS. For XMLCONF-over-SOAP, you might
use HTTP's authentication mechanism and HTTPS for
privacy. XMLCONF-over-ssh may use ssh's native authentication and
privacy, and uses ssh's port-forwarding facility for encoding
channels. 

To the XMLCONF protocol, it doesn't matter. The specific
protocol mapping should describe all this.

>4) With respect to 'kill-session' I could not figure
>out on how to know the session from the protocol
>operations defined in section 5. Or are the sessions the
>channels defined in section 2.4.

The sessions are XMLCONF sessions, not channels. In the lock operation
fails, the <lock-config> operation must provide the details of the
locking session's information in the reply. <kill-session> is meant as
a big hammer for clearing locks.  This should all be explained better
in the draft.

Thanks,
 Phil

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