[06:57:13] --- bharris has joined
[06:57:17] --- bharris has left
[06:59:17] --- bharris has joined
[06:59:21] --- bharris has left
[08:06:38] --- tsavo_work@jabber.org/Meebo has joined
[08:07:32] --- jiangxingfeng has joined
[08:08:11] --- lowekamp@gmail.com has joined
[08:10:23] --- rohan has joined
[08:10:57] <rohan> discussing p2p-state and draft-ford-behave-app documents
[08:11:23] --- csp has joined
[08:11:24] <rohan> summary from mic: do we really need this? seems like a discussion of how we would build apps if we didn't have ICE
[08:11:59] <rohan> dan: this could be for something like a game that doesn't use offer/answer
[08:12:25] <rohan> ekr and jdr: maybe better to adapt the game to use ICE and offer/answer just not using SDP
[08:12:36] --- yjs has joined
[08:12:45] --- csp has left
[08:12:47] <rohan> françois: i think we want a different document
[08:13:57] <rohan> jdr: not a tutorial. what tools do we have. describe use cases and what you need for nat traversal in each model/use case. The hardest use case will always be something like ICE.
[08:15:28] <rohan> dan as chair: no support for current ford-behave-app. need volunteer to do the new proposed document
[08:16:38] <rohan> philip: do we want to discuss the usefulness of UNSAF versus SAF approaches, like JDR's long expired "IV" document did.
[08:18:52] <rohan> rohan: is there a volunteer?
[08:18:56] <rohan> philip: maybe.
[08:19:16] <rohan> moving right along to STUN bis presentation
[08:20:03] --- MagnusW has joined
[08:21:39] --- MagnusW has left: Replaced by new connection
[08:22:31] <rohan> lars eggert: we could add a new author now please?
[08:22:41] <rohan> (in addition)
[08:22:50] <rohan> philip and rohan both want to think about it
[08:23:28] <rohan> dan: lets let JDR work on it for 2 weeks before bringing in extra editing help
[08:23:51] <rohan> jdr: need hash agility plan for MESSAGE_INTEGRITY
[08:24:56] <rohan> jdr: proposal is to define a new attribute (ex: MESSAGE_INTEGRITY2) using the new hash function
[08:25:34] <rohan> ekr: vaguely risky. 40-60% chance that Sam (sec AD) will make us add the new attribute now
[08:27:09] --- ttfr has joined
[08:27:14] <rohan> kai vemahen: is anyone using this
[08:27:19] --- bhoeneis has joined
[08:27:46] <rohan> jonathan lennox: why not just include the new attribute ; answer you would have to fail over
[08:29:23] <rohan> ekr: if we did this right you would have a flag in the attribute for hash function and allow multiple copies of the attribute
[08:30:44] <rohan> several people: it doesn't matter we can't go back and change time
[08:31:15] <rohan> phillip: can we just change the draft
[08:31:29] <rohan> jdr: i am very reluctant to break backwards compatibility
[08:34:11] --- sarolaht has joined
[08:36:09] <rohan> STUN TCP framing: should use a shim framing mechanism anytime we do both STUN over TCP and some other protocol on the same stream.
[08:36:24] <rohan> unclear whether over TLS this is inside or outside of the TLS record layer.
[08:38:33] --- jiangxingfeng has left
[08:41:14] --- jiangxingfeng has joined
[08:45:27] --- yjs has left: Disconnected.
[09:00:23] --- jiangxingfeng has left
[09:00:54] --- jiangxingfeng has joined
[09:02:56] --- Adam has joined
[09:04:16] --- cabo has joined
[09:05:18] <Adam> Sorry I can't be there because of the SIMPLE conflict (and I'm not sure how stale this is now), but with outbound using CRLF, is there a use-case for STUN TCP multiplexing left?
[09:05:45] <rohan> RTP over TCP with ICE
[09:05:52] <Adam> Ah, yes. Thanks.
[09:06:00] <rohan> I presented on TURN
[09:07:15] <rohan> ekr brought up a good point, asked why time to wait before setting the active destination is 5 seconds, why isn't it the same as the maximum segment lifetime (2 minutes)
[09:07:38] <rohan> no conclusion to discussion, but magnus will probably suggest something
[09:07:53] <rohan> hopefully this will be deferred to the transport ADs
[09:08:15] <Adam> I must have missed something -- what is the 2 minute timeframe derived from?
[09:08:36] <rohan> there was some discussion about the implication of getting a very late UDP packet forwarded from TURN server toward the client just before the active destination was changed
[09:09:13] <Adam> Ah, yes. That makes sense. OTOH, encapsulating data for a full two minutes seems very ineficient.
[09:09:45] <Adam> If you're actually bumping badwidth limits for 5 seconds, users will suffer through that. A 2-minute service outage, not so much.
[09:10:01] <rohan> JDR suggested a shim over UDP for all packets, but this did not get additional support
[09:10:15] <Adam> I don't think I would support that approach either
[09:10:30] <Adam> I'll think about it and (if I come up with anything worth saying) take it on the list
[09:10:35] <rohan> rohan brought up the shim (straw) that broke the fragment's (camel's) back
[09:10:51] <Adam> Who is typing as rohan here?
[09:11:25] <rohan> ekr said TURN is screwed for fragmentation, but agreed to explain offline
[09:11:39] <rohan> i (Rohan) am typing as rohan
[09:12:00] <Adam> Ah. I was confused by the third-party reference to self. Thanks for clarifying.
[09:12:05] <rohan> No other TURN issues where controversial
[09:12:33] <rohan> Bruce is now 5 minutes into his presentation on NAT discovery usage
[09:13:17] <rohan> JDR said that he doesn't want all stun servers having to support two IP addresses (2 virtual or physical interfaces)
[09:14:43] <Adam> From the SIMPLE chair: is this the final presentation? We're trying to get a feel for when we can expect BEHAVE participants to show up here.
[09:16:04] <rohan> bruce: lots of things in nat discovery don't require 2 addresses. for eample in p2p the source address is still useful
[09:17:22] <rohan> jdr: unreasonable for ICE peers for example to have two addresses. not unreasonable for a server doing behavior on the
[09:17:55] <rohan> philip: why not just return an error that server doesn't have 2 Ip addresses
[09:18:15] <rohan> jdr: what would client do in this case
[09:18:34] <rohan> rohan: try another discovery server
[09:26:23] --- akiniemi has joined
[09:28:17] <cabo> meeting still running?
[09:34:08] <Adam> We have a relatively large number of people who are interested in BEHAVE, but are otherwise stranded in SIMPLE -- can we get someone in BEHAVE to do some summarization of the conversations?
[09:39:52] <lowekamp@gmail.com> now talking about nat-icmp
[09:40:37] --- jiangxingfeng has left
[09:40:52] <lowekamp@gmail.com> http://www3.ietf.org/proceedings/07mar/slides/behave-1.pdf
[09:40:54] <Adam> Thanks
[09:41:40] <lowekamp@gmail.com> slide 8
[09:42:07] <lowekamp@gmail.com> dan presented as proxy for authors, so EKR trying to determine someone to ask questions to
[09:42:16] --- cabo has left
[09:43:07] <Adam> Is it safe to assume that the meeting is wrapping up, then?
[09:43:15] <lowekamp@gmail.com> close
[09:43:18] <Adam> Thanks
[09:43:53] <rohan> bruce: can you summarize the rest of the discussion form behavior discovery?
[09:44:36] <lowekamp@gmail.com> sure
[09:44:51] <lowekamp@gmail.com> we're currently discussing whether the authors could be expected to participate at least remotely.
[09:45:07] <lowekamp@gmail.com> document is useful and important, but no one is willing to assume it who attends
[09:45:34] <rohan> bruce: i asked for the summary of the issues on *your* topic
[09:45:42] <lowekamp@gmail.com> oh
[09:45:46] <lowekamp@gmail.com> sorry
[09:46:07] <rohan> no problem, the other comments are also useful ;-)
[09:50:49] <lowekamp@gmail.com> notes that I made when I sat down after the presentation (I hope there's an audio recording that I can refer to later): clarify that only two-IP servers should have an SRV entry claiming they offer this service remove backward compatibility with 3489 clients by removing old attributes (non-XOR forms) PADDING will remain mandatory specify that mapped-address and xor-mapped-address are always returned in behavior-discovery usage so we can specify new use case that you can look at both mapped and xor-mapped to see if you have that behavior (thanks rohan and jdr)
[09:51:36] <rohan> cool, thanks bruce
[09:53:38] --- rohan has left
[09:55:57] --- lowekamp@gmail.com has left
[09:58:27] --- sarolaht has left
[10:05:46] --- Adam has left: Computer went to sleep
[10:06:09] --- ttfr has left
[10:06:34] --- akiniemi has left
[10:07:47] --- bhoeneis has left
[11:45:40] --- tsavo_work@jabber.org/Meebo has left
[13:30:41] --- Adam has joined
[14:02:39] --- Adam has left