[00:51:41] stefan.winter joins the room
[00:55:00] Alan DeKok joins the room
[00:59:16] Bernarda joins the room
[00:59:27] Bernarda has set the subject to: IETF 79 RADEXT Meeting
[00:59:43] <Bernarda> Hello. 
[01:07:07] <Bernarda> Blue sheets are circulating.  Please sign them. 
[01:07:50] <Bernarda> Mauricio appears to be muted.  I am connected to streaming audio. 
[01:08:20] semery joins the room
[01:09:12] dromasca joins the room
[01:09:29] <dromasca> hi, jabbering from the room
[01:09:47] <dromasca> mauricio bashing agenda
[01:09:51] <dromasca> adopted
[01:09:59] <dromasca> wg status - slide 1
[01:11:59] <Bernarda> Alan, Stefan and I are on a Skype conference call...
[01:12:11] <Bernarda> Has anyone read the IPv6 Access document?  1 person (the AD). 
[01:12:23] <dromasca> i know - backing up in case skype fails
[01:12:33] <dromasca> yes - i am the wrong person :-)
[01:12:36] <Bernarda> Having the AD read the document is good.... but not if that's the only person reading it :(
[01:13:14] <dromasca> slide 2
[01:13:51] <Alan DeKok> how many people are in the room?
[01:14:34] <dromasca> around 15
[01:14:54] <dromasca> hot errata slides
[01:16:36] <Bernarda> Why change the status from verified to "hold"?  It's been verified....
[01:17:39] <Bernarda> 753 is not an error.... the difference was intentional, since RFC 1035 is not enforced (e.g. 3com.com)
[01:18:30] <Bernarda> We don't want this enforced.... this errata should not be verified!
[01:20:06] <Bernarda> 753 should be rejected since it was intentional, yes. 
[01:20:30] <Bernarda> 1469 should be verified... not held (assuming it is correct)
[01:22:25] <Alan DeKok> Alfred Hoenes needs to read *all* documents before they're published.
[01:22:28] <dromasca> any comments?
[01:22:40] <Alan DeKok> He caught those two errata for 5997
[01:23:21] <dromasca> agree with moving to held?
[01:23:33] <Alan DeKok> yes
[01:24:31] <Alan DeKok> yes
[01:25:07] <Bernarda> Some feedback....
[01:25:31] <Alan DeKok> I'm on headphones to avoid feedback issues
[01:25:41] <Bernarda> Which document is this?
[01:25:54] <Bernarda> Transport?
[01:26:29] <dromasca> radius over tcp
[01:26:48] <Bernarda> So has the IESG removed its DISCUSS comments?
[01:27:42] <Bernarda> Last I saw, Ralph didn't think his issue was addressed.
[01:28:19] <stefan.winter> no comments. I'm happy with the document.
[01:29:05] <Bernarda> I think Ralph thinks he is waiting for Alan... and vice versa. 
[01:29:33] <Alan DeKok> ok
[01:29:35] <Alan DeKok> will do that
[01:29:51] <dromasca> design guidelines
[01:31:08] <Bernarda> IETF last call is done, no?
[01:33:12] <dromasca> radius over tls
[01:33:49] <dromasca> bernard - will reset iesg ballot and go into new ballot
[01:35:57] <Alan DeKok> for existing Radsec, administrators presumably talk to each other, and avoid misconfiguration
[01:36:06] <Alan DeKok> we can't rely on that for the future. for all RADIUS
[01:38:53] <Alan DeKok> i can talk on the mike, too, if necessary.  just want to avoid interrupting anyone else
[01:39:32] <Bernarda> In RADIUS over TCP draft, we don't encourage this without TLS... so is it really an issue to differentiate TLS from RADIUS over TCP?
[01:39:54] dromasca leaves the room
[01:40:49] <Bernarda> The nuiance is actually important to security analyses such as downgrade attacks....
[01:40:51] dromasca joins the room
[01:41:16] <dromasca> sorry, i was out of jabber for a few minutes
[01:41:16] <stefan.winter> so three ports would be easier on the process, right?
[01:42:30] <dromasca> stefan - we cannot here you
[01:43:10] <stefan.winter> even if TCP isnt encouraged, we should keep it as a usable option. So demultiplexing needs to be considered.
[01:45:58] <stefan.winter> That looks like it's going to be: distinct ports, and using 1812,1813,3799, right?
[01:46:32] <stefan.winter> with demultiplexing on server side.
[01:46:52] <stefan.winter> I'll summarise the issue on the list then, and ask for implementor's feedback.
[01:49:08] dromasca leaves the room: Replaced by new connection
[01:49:45] dromasca joins the room
[01:51:00] <dromasca> radius over dtls
[01:55:01] <stefan.winter> Checked Alan's implementation already; works ! :-)
[01:57:12] <Alan DeKok> finishing early means more sleep for me
[01:57:20] <stefan.winter> ACK
[01:57:30] <dromasca> extended attributes
[02:01:39] Bjoern A. Zeeb joins the room
[02:09:22] <stefan.winter> Why not have "flags" for all the ext-attrs? That would make the distinction of 241-244 and 245-256 obsolete. And enable larger sizes for the TLVs in "struct"s.
[02:12:16] <stefan.winter> we just discussed that ...
[02:13:12] <stefan.winter> Q: how many deployers have gone the "simple string" way like EAP-Message *because* there were no longer attributes?
[02:23:15] <stefan.winter> HAve any of the proposed VSA attributes been "hijacked" yet? I.e. are they already defined in dictionaries with a conflicting data type? This has happened for example with Operator-Name (126) and it seems to cause pain in some server implementations.
[02:24:18] dromasca leaves the room
[02:26:03] dromasca joins the room
[02:27:53] stefan.winter waves hand to become WG item, willing to review
[02:27:57] <Bernarda> People on the jabber room can also raise their hands. 
[02:28:06] <Bernarda> Bernard:  Raises hand....
[02:29:22] Alan DeKok leaves the room
[02:29:28] semery leaves the room: Disconnected
[02:30:05] stefan.winter leaves the room
[02:31:16] <Bernarda> Meeting adjourned.
[02:31:19] Bernarda leaves the room
[02:34:46] dromasca leaves the room
[02:35:11] Bjoern A. Zeeb leaves the room
[02:50:42] davem joins the room
[02:51:21] semery joins the room
[02:53:19] davem leaves the room: offline
[04:00:57] semery leaves the room: Disconnected
[04:20:14] semery joins the room
[04:30:03] semery leaves the room