[Standards] Fwd: Re: [Netconf] XMPP as transport

Peter Saint-Andre stpeter at stpeter.im
Wed Jul 3 20:17:43 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI, yet more potential "customers" for XMPP. Join the IETF NETCONF
list if you're interested.

/psa

- -------- 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> 
> wrote:
> 
>> Hi,
>> 
>> 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
they?

> Yes, that's my plan, unless somebody convinces me that it's a 
> nonsense.

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

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> 
>> wrote:
>>> 
>>> On Jul 3, 2013, at 4:30 PM, "ietfdbh" <ietfdbh at comcast.net> 
>>> wrote:
>>> 
>>>> 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).

Peter

_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1IbnAAoJEOoGpJErxa2p2dIP/jdHtrOU750CD0RFP6/iOyYX
Gh9NzNrKQ3297kUITVE1Be9YqVwzgG9ZeCcUUxD8lpJ449Yd/Jq1unecMiv79L8M
33hXCMrs0qF7MY3pDQpj+Z/SZmXU4GxHUowvWDg5FlJwPy/Wjm9JDTSNv0KNtbNz
744bWX2fQOcMR3eLnCE4HG/eLd9Ss0nBlmOLfBv2PQU8szmX+5DvVzrdZNrwx8rU
QvPFbcPAP/ZCxE538db6fSaKvEPgDcsHs3l9VoJAodydnpAECUydDlixOH5DULus
9xie1Q+F0LLwtJWXHwaPYU0Ud+tW0y4fRFWQ87HYraPXbhrJEUbLJT9OgxW3Fnpn
fz2H3/u19F0IdvnAb2MLhNY8nBIBTwx0C3Au9u+8F9iDff5ccF1ufn31n+F6z0sE
BJVOVVL/K68nsVd7cktK2sHTJw7bSaV2cMVbrWS/gN9pNkmTMtqn10D2+6esEcVC
gI0jMWWaMd02C/GvA8h4oRKciNTgREBBHLHlAi2m9nCQieHx3foxotTSUhn6GFcJ
3dGrDLE6y4xsjSbeI98PAK8m1gnhmkRGyAGeYlPWnByFktCF9To6hyeaBjgfFH8U
KxWZKQknoLENzvJP8KCzGAIx0o7DtwrScqPfyvH8ru8K6+YHO8+WxhcOlNNPgEci
ucfj19cMsTAJ2yPglai7
=jTRi
-----END PGP SIGNATURE-----



More information about the Standards mailing list