-----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 <[email protected]> To: Ladislav Lhotka <[email protected]> CC: Netconf <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >>> >>> On Jul 3, 2013, at 4:30 PM, "ietfdbh" <[email protected]> >>> 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 [email protected] 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-----
