IETF
netconf
netconf@jabber.ietf.org
Tuesday, 15 November 2011< ^ >
Bill has set the subject to: NETCONF meeting at IETF-81
Room Configuration

GMT+0
[05:04:29] mbj joins the room
[05:05:30] mbj leaves the room
[08:47:27] ray_atarashi joins the room
[08:53:57] Bert Wijnen joins the room
[09:08:00] mbj joins the room
[09:10:16] <mbj> I'm here!
[09:10:25] <Bert Wijnen> and he hears us
[09:10:33] <mbj> yes :)
[09:11:46] russmundy@jabber.org joins the room
[09:13:41] Atarashi Yoshifumi joins the room
[09:15:03] <russmundy@jabber.org> Andy presenting 2 drafts that are currently in IETF Last Call
[09:15:12] <russmundy@jabber.org> no slides
[09:16:20] lhotka joins the room
[09:16:50] <mbj> We do reference RFC 5607 (with th epolicy id)
[09:17:43] <mbj> Ok.
[09:23:29] <russmundy@jabber.org> Now discussion of AD comments on system-notifications-06
[09:30:03] badra joins the room
[09:30:22] aluchuk joins the room
[09:31:05] <Bert Wijnen> Badra, are you hearing us well?
[09:34:48] <russmundy@jabber.org> AndyB to the mike
[09:35:52] <russmundy@jabber.org> Badra - did you get Andy's comment?
[09:36:04] Badra joins the room
[09:37:01] <russmundy@jabber.org> sorry, I don't know the name of the person at mike
[09:37:09] <Badra> I have prob with the voice
[09:37:38] <mbj> audio works for me
[09:37:43] <Badra> Would you please write here Andy's comment?
[09:37:52] <mbj> (although in one channel only...)
[09:38:43] <aluchuk> Was the question about temporal PSKs, or two keys that map to the same NETCONF username?
[09:39:28] <Bert Wijnen> about having 2 PSKs that are valid at the same time during roll-over period (or that is what I understood)
[09:39:29] <russmundy@jabber.org> Bert requested the last question be posted to the mail list since it dealt with changing identies
[09:39:39] <Bert Wijnen> But Carsten will post the Q to our mlist
[09:40:02] <Badra> It consists of only one PSK, preshared between the client and the server, this PSK is used duting the TLS session to generate a session key (master secret in TLS term), but the PSK is static and is used for authenticating the client and also the server
[09:40:55] <aluchuk> To allow the NETCONF deployer to use the mapping algorithm that is most useful at the site, instead of restricting the choices to those provided by a particular N
ETCONF Server vendor.
[09:42:18] <russmundy@jabber.org> Text refers to base:1.0 and base:1.1. Does not mention corner case where client and server do not agree on a version and session is dropped. Need to be clear not changing algorithm to pick version in use
[09:44:47] <mbj> I read it
[09:44:54] <russmundy@jabber.org> Badra: last comment from me was actually Andy stating his last comment that you asked about it
[09:45:04] <Bert Wijnen> ok some 7-8 people read it
[09:46:07] <Bert Wijnen> some 8 people want it in the WG and nobody objected
[09:46:39] <mbj> Does anyone use this transport?
[09:46:40] <russmundy@jabber.org> any further comments (yea or ney) about whether this document is needed?
[09:47:06] <mbj> As a vendor, I haven't has any requests for it.
[09:47:46] badra leaves the room
[09:51:10] <mbj> hum!
[09:52:37] <russmundy@jabber.org> Any other hums or objections here about obsoleting the transports that only support 1.0??
[09:55:14] <russmundy@jabber.org> Next presentation: NETCONF over WebSocket
[09:56:27] <russmundy@jabber.org> Slide 3 - Background
[09:56:54] <russmundy@jabber.org> Slide 4 - Changes since 80th IETF
[09:57:15] <russmundy@jabber.org> Slide 5 -
[09:57:49] <russmundy@jabber.org> Slide 6
[09:58:18] <russmundy@jabber.org> Slide 7 - Security
[09:58:43] <mbj> (i think there is a small audio delay...)
[09:59:14] <russmundy@jabber.org> Slide 8 - Example
[09:59:47] <russmundy@jabber.org> Slide 9 Conclusions
[10:00:18] <russmundy@jabber.org> Question Time ...
[10:00:55] aluchuk leaves the room
[10:01:18] <mbj> I think this is more interesting than NETCONF over TLS, since this can be used for a new use case (browser based).
[10:02:47] <mbj> REST cannot easily handle notifications
[10:03:02] <Badra> what do you mean by browser based, ad why TLS is not suitable enough?
[10:03:26] <mbj> badra: run in a browser
[10:03:52] <mbj> andy: not just show the xml in the browser - use it to write a proper browser base gui
[10:03:59] <Badra> mbj, but TLS can also do that, no?
[10:04:54] <mbj> peter: this does not help the automation; but helps the UI
[10:05:07] <mbj> (when a UI is needed)
[10:06:16] lhotka leaves the room
[10:08:25] <mbj> sure I do have a document written...
[10:08:43] <mbj> I did not plan to publish it right now, but...
[10:08:58] <mbj> *and * implementatiomn
[10:09:16] Badra leaves the room
[10:09:19] Badra joins the room
[10:10:48] <mbj> We would fix YANG, not NETCONF
[10:16:51] <mbj> Hold on
[10:16:53] <mbj> delay
[10:16:53] <russmundy@jabber.org> Martin: Did you hear Andy's question?
[10:17:11] <mbj> YANG defines the capability string for modules
[10:17:18] <mbj> not NETCONF
[10:17:22] <mbj> (audio delay)
[10:17:36] <mbj> no need to fix netconf
[10:18:13] ray_atarashi leaves the room
[10:18:18] <mbj> netconf doesn't know submodules
[10:19:38] Badra leaves the room
[10:20:01] Atarashi Yoshifumi leaves the room
[10:20:21] <russmundy@jabber.org> Closing meeting - thanks to all jabber room participants
[10:20:33] russmundy@jabber.org leaves the room
[10:25:37] <mbj> I still hear you. Do you want to discuss this?
[10:26:30] Bert Wijnen leaves the room
[10:27:19] mbj leaves the room
[10:52:49] Bert Wijnen joins the room
[11:08:05] Bert Wijnen leaves the room
[20:29:29] Bert Wijnen joins the room
[20:43:11] Bert Wijnen leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!