[Operators] Fwd: Re: [Netconf] XMPP as transport
stpeter at stpeter.im
Wed Jul 3 20:17:43 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
FYI, yet more potential "customers" for XMPP. Join the IETF NETCONF
list if you're interested.
- -------- Original Message --------
Subject: Re: [Netconf] XMPP as transport
Date: Wed, 03 Jul 2013 14:16:10 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
To: Ladislav Lhotka <lhotka at nic.cz>
CC: Netconf <netconf at ietf.org>
Ahoj. ;-) David Harrington alerted me to this discussion (as author of
RFC 6120 etc.), so I've joined the list.
On 7/3/13 11:57 AM, Ladislav Lhotka wrote:
> On Jul 3, 2013, at 7:36 PM, Andy Bierman <andy at yumaworks.com>
>> The "must therefore be mediated by one or more XMPP servers" part
>> doesn't sound too great. Perhaps somebody should implement a
>> prototype and compare the performance characteristics to
>> NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then
>> write an I-D explaining why we need another NETCONF transport,
>> and it should be XMPP.
Pardon my ignorance of NETCONF, but it seems that even using ssh or
some other transport would require some form of mediation, no? It's
not as if NETCONF clients and servers talk to each other directly, do
> Yes, that's my plan, unless somebody convinces me that it's a
I would be willing to at least advise you in that work.
> It may be more effective than bending ssh and facing the
> opposition of ssh and security folks.
I have no opinion there.
> Performance-wise, I don't think a XMPP server could be a
There are several XMPP server implementations that have been tested up
to 100,000 concurrent sessions and beyond. I don't think this should
be a problem for NETCONF.
> Of course, it's an extra box to care about.
Well, the xmpp daemon could be co-located with the NETCONF server (I'm
not clear on the usual deployment scenarios for NETCONF).
>> On Wed, Jul 3, 2013 at 9:33 AM, Ladislav Lhotka <lhotka at nic.cz>
>>> On Jul 3, 2013, at 4:30 PM, "ietfdbh" <ietfdbh at comcast.net>
>>>> Hi Lada,
>>>> I would be interested in your analysis of how XMPP does/does
>>>> not meet the rfc6241 requirements for transport.
I will endeavor to read RFC 6241 before long. But it might not happen
until after IETF 87.
>>> XMPP streams are secure and authenticated, typically via TLS &
>>> SASL. However, the endpoints of each stream are a XMPP server
>>> and client, so the messaging between NETCONF client and server
>>> must therefore be mediated by one or more XMPP servers, and the
>>> NETCONF parties must trust those XMPP servers.
>>> NETCONF usernames can be derived either from JID, or just from
>>> its local part.
>>> The "iq" stanza can be used for wrapping NETCONF RPC requests
>>> and replies, and "message" for notifications. An XMPP server
>>> must ensure in-order processing of the stanzas from a
>>> connected client (sec. 10.1 in RFC 6120).
That's all correct.
>>>> For example, can Netconf reliably determine if a connection
>>>> is terminated, so it knows to release locks?
>>> It could be done using the same mechanism that Jabber clients
>>> use for determining the presence of their peers.
Or, if the NETCONF server is integrated with the XMPP server properly,
it might have that knowledge based on the status of connections from
clients. This, for example, is how folks are using XMPP in the
SmartGrid space (see the spec for OpenADR 2.0).
Netconf mailing list
Netconf at ietf.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Operators