[06:50:50] --- fluffy has become available
[06:53:48] --- Melinda has become available
[06:54:36] --- shima has become available
[06:56:14] --- shima has left
[06:56:14] --- shima has become available
[06:57:05] --- hartmans has become available
[06:58:59] --- marcos has become available
[07:01:34] --- tlyu has become available
[07:01:59] --- raeburn@jis.mit.edu has become available
[07:02:16] --- raeburn@jis.mit.edu has left
[07:02:20] --- raeburn has become available
[07:02:26] <hartmans> Are we planning on having scribes here?
[07:04:32] --- javier has become available
[07:04:55] --- pguenther has become available
[07:05:37] --- fanf has become available
[07:05:45] --- fenton has become available
[07:05:51] <raeburn> Yeah, I'll try...
[07:05:55] --- taiji-k has become available
[07:06:08] --- jeroen has become available
[07:06:24] <raeburn> SAAG: The Russ and Sam Show
[07:06:26] --- Xag has become available
[07:06:54] --- raeburn2 has become available
[07:07:04] --- shep has become available
[07:07:07] --- WH has become available
[07:07:33] --- smb has become available
[07:07:36] <raeburn> Agenda: WG reports, BOF reports, 2 Invited presentations, Open Mic
[07:07:38] --- mstjohns has become available
[07:08:12] <raeburn> invited talks: ITU-T recommendation x.805; unicode security considerations.
[07:08:15] --- mike has become available
[07:08:31] --- fluffy has left: Replaced by new connection
[07:08:31] --- fluffy has become available
[07:08:41] <raeburn> Kitten WG, Jeff Altman
[07:09:10] --- sommerfeld has become available
[07:09:11] --- tlr has become available
[07:09:14] --- warlord has become available
[07:09:38] <raeburn> Lively mtg. PRF extension for GSS near another WG LC, draft in just before conference. Krb5 PRF ready, waiting for general PRF to go to IETF LC.
[07:09:53] --- jsalowey has become available
[07:10:14] --- jhutz has become available
[07:10:50] <raeburn> (eep, already falling behind) Naming extensions draft 00 discussed at mtg, many issues to be addressed, issue is very broad. Want PKIX community help re naming in certs. Volunteers?
[07:11:20] <jhutz> housley: what does "relateed" mean
[07:11:28] <jhutz> hartmans: think as broadly as you can
[07:11:52] <raeburn> Sam: Naming related to certs, subject alt names and cert extensions, stuff not names in the strictest sense.
[07:11:58] <jhutz> jaltman: currenlty GSS exports a single canonical name for an entity, that can be used on an ACL
[07:12:10] <raeburn> GSS assumes you can export a single name for acl, but names can change over time.
[07:12:10] <jhutz> jaltman: problem is, names change over time; simply having a name isn't always what people want
[07:12:22] <jhutz> jaltman: they want access to other things, like attributes, groups, etc.
[07:12:29] <raeburn> (you taking over, jeff?)
[07:12:43] <jhutz> Sort of, but not while I speak (next)
[07:12:47] <raeburn> ok
[07:13:07] --- stefans has become available
[07:13:08] <raeburn> Discussing steps to move 2743 2744 to draft std.
[07:13:22] --- andrewdmcgregor@jabber.psg.com has become available
[07:13:29] <raeburn> Will put together a feature list to determine interoperability.
[07:13:45] <jhutz> we'll also be working to put together a list for our missed milestone wrt updates to gssapi
[07:13:50] <raeburn> KRB-WG: Jeff Hutzelman.
[07:14:35] <raeburn> Met Monday. Long, mildly traumatic discussion on identifying KDC certs in PKINIT, whether EKU needed and required to be present, etc. Will continue on list.
[07:15:17] <raeburn> Andre S(spelling?) and Aaron (sp?) found a problem w PKINIT, discussed ways to fix it, a few minor details still to be hashed out.
[07:15:45] <raeburn> Sam gave very brief discussion on Kerberos assumptions he'd like us to consider removing. Probably will have presentation next meeting.
[07:16:30] <raeburn> Interim mtg next month (end of Sep) on advancing new RFC to Draft. Info will be on wg list soon.
[07:16:49] <raeburn> Russ: Second time formal methods analysis on one of our protocols, and both times, problems were found.
[07:17:01] <raeburn> Jeff: Not especially a fan, but can't argue...
[07:17:10] <raeburn> LTANS, Tobias Gondrom
[07:17:22] <jhutz> Short meeting. We currently have 4 drafts
[07:17:28] --- m.behringer has become available
[07:17:33] <jhutz> skipped last IETF, but gaining speed again
[07:17:36] <jhutz> ???
[07:17:37] --- bert has become available
[07:17:46] <jhutz> presentation about cryptographic maintenance policies
[07:17:56] <jhutz> presentation about cryptographic archive protocol
[07:18:22] <jhutz> presentation about notary services (now called "data certification services"). Community still not sure about real use cases.
[07:18:22] <raeburn> need community input, wg unsure of real-world use cases.
[07:18:24] <jhutz> Let's alternate...
[07:18:40] <jhutz> warlord, openpgp
[07:19:15] <jhutz> juergen, isms (kenh not here)
[07:19:24] --- Jeffrey Altman has become available
[07:19:32] <jhutz> had a short-lived charter to find out which way to go.
[07:19:39] <jhutz> made an architectural decision after last IETF
[07:19:40] --- hardaker has become available
[07:19:46] <jhutz> by this meeting, had to agree on a transport to use
[07:19:54] <jhutz> goal is to find a security protocol for snmp
[07:20:07] <jhutz> charter says we have to finish by end of much and re-charter
[07:20:18] <jhutz> four candidates: DTLS, SSH, TLS+SASL, BEEP
[07:20:22] --- stefans has left
[07:20:46] <jhutz> first eliminated udp-based (DTLS) because we don't need udp and don't consider dtls mature enough.
[07:20:54] <jhutz> 3 left; majority in session prefer ssh solution
[07:21:17] <jhutz> because ssh is most widely deployed in network management (many devices already do it)
[07:21:35] <jhutz> actions: quickly agree on a new charter, including development of a solution based on ssh
[07:21:38] <jhutz> and start working on the drafts
[07:21:59] <jhutz> tim polk, steven kent, pkix
[07:22:27] <jhutz> [someone else type]
[07:22:47] <raeburn> (list of docs) got iesg approval, more in review
[07:23:06] --- weiler has become available
[07:23:26] <raeburn> crl iaa (?) in ietf lc, wg lc soon for another, 3280bis and (?) discussed
[07:23:41] <jhutz> [jaltman, you get to do people who ask questions]
[07:23:49] --- stefans has become available
[07:23:57] --- dumdidum has become available
[07:24:03] <Jeffrey Altman> [ok]
[07:24:18] <raeburn> (detailed minutes being read, it seems, i can't keep up :(
[07:24:24] <raeburn> SASL, Tom Yu
[07:24:39] <jhutz> discussed cram-md5, which is expired
[07:24:48] <raeburn> Discussed cram-md5, expired. Consensus to take off std track, Sam suggested historical.
[07:24:55] <jhutz> sam suggested remove from standards track; also needs an applicability statement
[07:25:08] <jhutz> gss-sasl: really describes two sets of mechs.
[07:25:16] <raeburn> gssapi mech draft refreshed. describes two types, legacy (krb5, spnego) and generic, some concern about round-trips.
[07:25:22] <jhutz> (krb5,spnego and all others)
[07:25:37] <raeburn> consensus to split out legacy and get that moving forward.
[07:25:48] --- Love has become available
[07:25:49] <raeburn> plain spec revised, sam & kurt to discuss issues.
[07:25:51] <jhutz> ("legacy" meaning GSSAPI (krb5) and GSS-SPNEGO (spnego)
[07:25:56] <jhutz> and defer the rest until later
[07:26:20] <jhutz> appreciate outside review we've gotten. It was pointed out we keep getitng confusion about
[07:26:23] <raeburn> good outside review in lc on (base?), some clarification on some points seems to be needed.
[07:26:33] <jhutz> athentication vs authorization ID's; needs more clarification
[07:26:37] <jhutz> (yes, base)
[07:26:38] <raeburn> discussion on cbc vs counter for aes.
[07:26:48] <jhutz> ... for aes in digest-MD5
[07:27:08] <raeburn> some agreement counter is good, drop cbc without iv in every packet. also ccm, gcm mentioned, some ipr questions.
[07:27:11] --- danwing has become available
[07:27:11] <raeburn> russ: no ipr issues.
[07:27:41] <raeburn> (iirc, the question was just that we couldn't assert that in the meeting.)
[07:27:48] <raeburn> smb: no *known* issues, you mean.
[07:28:14] <raeburn> tlyu: presentation in apps area on challenge-response protocols and offline attacks.
[07:28:32] <raeburn> some concern that digest-md5 isn't much better than cram-md5.
[07:28:52] <raeburn> but tom wasn't there, so it's nth-hand report. ekr responds...
[07:29:10] <Jeffrey Altman> ekr: digest is better than ccram-md5
[07:30:04] <raeburn> tlyu: also concern that no formal proof for digest-md5; ldap community uncertain about what's secure and should be recommended; apps area is reportedly unhappy with lack of consensus from security area regarding recent hash breaks.
[07:30:54] <raeburn> to do: get sasl base to iesg by end of month, discuss cram/digest-md5 future, more text on applicability of digest-md5. gss legacy mechs split off in new doc ready by Oct.
[07:31:11] <jhutz> ran canetti, lakshminath dondeti, msec
[07:31:13] <raeburn> MSEC: Lakshminath
[07:31:27] <jhutz> between ietf62 and now, we've had two rfc's publsihed, 3 more in queue
[07:31:28] <raeburn> since Minn., two RFCs published (informational), more in queue
[07:31:32] <jhutz> 3 more in iesg review
[07:31:50] <jhutz> in ietf62 we got an action item from russ to work on msec extensions for ipsec
[07:32:03] <jhutz> we now want comments; will distribute to ipsec, soon after this ietf
[07:32:13] <raeburn> want comments on scope specifically
[07:32:14] <jhutz> currently only looking for comments on scope; if the details are wrong we can fix them
[07:32:22] <jhutz> we have several drafts presented at the meeting...
[07:32:25] <jhutz> mostly in MIKEY.
[07:32:45] <jhutz> about 4 MIKEY drafts plus rfc3830. do we need to write an umbrella document to describe what those mean, where they apply
[07:32:53] --- raeburn2 has left
[07:32:56] <jhutz> someone proposed we write a roadmap doc for MSEC documents.
[07:33:07] <jhutz> one action item to get a consensus on the list as to which to write
[07:33:18] <jhutz> there is a MIKEY RSA doc that needs review; will send to MMUSIC for that.
[07:33:27] <jhutz> reviewed a couple of other's WG's proposals.
[07:33:46] <jhutz> one from XXX on YYY; want to find a home in msec, maybe. russ said eithe way run WGLC in both docs
[07:33:58] <jhutz> finally, IPDVB asked us to review a doc for xxx in that wg
[07:34:22] <jhutz> after some discussion, it was decided we should start at the beginning, write a reqs draft; msec volunteered to review when done
[07:34:33] <jhutz> gregory lebovitz, paul knight, pki4ipsec
[07:34:39] <jhutz> (er, "pki4ipse")
[07:34:51] <jhutz> looked at our 2 documents
[07:35:02] <jhutz> trying to profile use of certs as proof of authentication in IKE and IKEv2
[07:35:32] <jhutz> first doc profiles how certs should be constructed and how IKE peers should use them. narrowed down from 15 issues to 2
[07:35:35] --- gr8k@jabber.org has become available
[07:35:55] <jhutz> one is fairly small, cernters around EKU; had a proposal in th room and consensus; will take to use
[07:36:04] --- tanupoo has become available
[07:36:10] <jhutz> There used to be 3 oid's in pkix set aside for use in ipsec; use was never clearly defined
[07:36:20] <jhutz> we're going to deprecate those, and create a new one for IKE and IPSEC.
[07:36:34] <jhutz> Would cover IKE v1 and v2 (these are EKU OID's?)
[07:36:47] <jhutz> one question: what do we need to do outside our WG?
[07:37:01] <jhutz> as soon as we get that text finalized, will rev to -06 and go to WGLC
[07:37:15] <jhutz> took a straw poll; would people feel good about moving to WGLC; no disagreement in room
[07:37:24] <jhutz> second document is a reqs doc for a management protocol
[07:37:43] <jhutz> to handle things like lifecycle management, cert request, revocation, looking up trust anchors, crls, etc in directories
[07:37:47] <jhutz> getting fairly close
[07:38:03] <jhutz> one member brought up a use case that dramaticallyt changes the base architecture we agreed to a long time ago
[07:38:22] <jhutz> actually a valid use case; we're not sure what to do. will discuss on the list, decide whether to start over, deal in a different doc, whatever
[07:38:28] <jhutz> if you want more details, please read our list
[07:38:45] <jhutz> last item... third charter item. once lifecycle/mangement doc done, profile CMC
[07:39:01] <jhutz> it appears that interest in this has waned. we did a straw poll; people are not interested in building that doc
[07:39:11] <jhutz> one thing that would change it is if there were significant interest from cert vendors
[07:39:29] <jhutz> if that's the case; if we've misunderstood market need, please let us know; otherwise sense of the room was to
[07:39:33] <jhutz> drop that item from the charter.
[07:39:45] <jhutz> if that's the case, we'll finish the two docs I mentioned, then wrap up and close.
[07:39:57] <jhutz> roman danyliw, inch [someone else type]
[07:40:00] <raeburn> INCH, Roman Danyliw, met Wed morning
[07:40:14] <raeburn> req draft taking too long, hoping wg lc end of month.
[07:40:45] <raeburn> have schema, dropped legacy dtd stuff. two small modelling issues left, rest is editorial. freeze at end of sept, then do editorial changes,
[07:41:24] <raeburn> done by december. extended iodef(?) to cover phishing reports. iodef revved for changes in data model.
[07:41:28] --- nico has become available
[07:41:53] <raeburn> transport protocol? have an ind submission discussing, need to see if people comfortable with doing that work, currently out of charter.
[07:42:04] <jhutz> stephen farrell, sacred
[07:42:10] <jhutz> (also magnus nystrom)
[07:42:12] <raeburn> SACRED, Stephen Farrell. Was basically done but not happy because of IPR.
[07:42:36] <jhutz> presentations on PAK(?), SPEKE, OPEKE(?)
[07:42:49] <nico> PAK, SPEKE, OPAKEEEE
[07:42:52] <nico> OPAKE
[07:42:54] <raeburn> Looked like it might've changed, had some presentations, including DoCoMo's new scheme OPAKE. Asked Lucent, Phoenix to talk to lawyers and get back to us in a month, maybe we'll recharter and use one of their schemes.
[07:42:58] <jhutz> jari arkko, paul hoffman, mobike
[07:43:02] <raeburn> MOBIKE, Paul Hoffman
[07:43:17] <jhutz> mobike is working toward enabling movements of simultaneous conns in IKE v2 VPN's.
[07:43:21] --- tonyhansen has become available
[07:43:27] <jhutz> If you're walking around and ipaddr changes, you don't lose your vpn conn
[07:43:33] <jhutz> in may we reached agreement on design decisions
[07:43:45] <jhutz> in june, a protocol spec came out; lots of in-depth reviews prior to this meeting
[07:44:02] <jhutz> at this meeting, discussed technical issues; many were simple or even editorial; we have consensus on most
[07:44:12] <jhutz> big issue remaining is how mobike interacts with nat traversal
[07:44:19] <jhutz> long discussion; multiple proposals
[07:44:26] <jhutz> need to figure out what we want to do, how to do it.
[07:44:36] <jhutz> ended up with 2 things we might want to do, and for each, 1-2 ways to do it.
[07:44:48] <jhutz> think we'll be ready for WGLC by mid-september; sent protocol to IESG well in advance of vancouver
[07:45:03] <jhutz> in next couple weeks, invite anyone to come take a look; rapidly streaming toward wglc
[07:45:26] <jhutz> also, have a protocol design considerations doc, meant to be informational, document for the future what we considered and why we picked what we did
[07:45:38] <jhutz> trailing the protocol doc itself, but not by much; hopefully done by vancouver as well.
[07:45:48] --- andrewdmcgregor@jabber.psg.com has left
[07:45:50] <jhutz> also have inter-wg dependency from mobike, and liason statement from XXX
[07:46:17] <raeburn> BTNS, Love Hornquist Astrand
[07:46:29] <jhutz> Hi, I'm Love Hörnquist Åstrand and I'm chairing BTNS together with Pekka Nikander. The BTNS working group had its first meeting as a working group this morning. Joe Touch presented the working group's first document, the problem and applicability statement. He have received comments from 2 people, will get more comments, and submit new version in a couple of weeks. Joe thinks he needs one or two more iterations before going to WGLC. Some decisions was made during the meeting is that: need to support tunnel mode, where the inner address is the same as the other. This is because its the required implementation by other documents. We will also will look at the problem using IKE v2 first and then go back and look what modification is needed for IKE v1. For the next item to do we will work on is the SPD/PAD extensions draft, target is to have it out well before Vancouver meeting. We have a editor and 7 people that are willing to the work. We also came to the conclusion that we need to support the case where there is a BTNS peer talking to a full IKE peer, its part of our charter.
[07:46:47] <jhutz> [thanks to lha for sending me his comments in advance]
[07:47:06] <nico> cool
[07:47:39] <Jeffrey Altman> all WG/BOF reports have also been sent to the SAAG mailing list
[07:47:48] <jhutz> [BOF's to come: hash, secmech, alien, mass]
[07:47:53] --- pguenther has left
[07:48:10] <jhutz> paull hoffman, hash
[07:48:23] <jhutz> met monday evening. had a bunch of presentations on upcoming NIST hash meeting
[07:48:44] <jhutz> presentation from nist on where they're going with truncating longer hashes and mixing/truncating down to needed lengthds
[07:49:02] <jhutz> presentations on other techniques for strengthening sha1, md5 against recent attacks
[07:49:29] <jhutz> for those not following... hashes have 2 properties you want to be true; one (collision resistance) ther have been attackes in the area
[07:49:42] <jhutz> still not practical, but getting there. time to work on hashes anyway
[07:49:50] <jhutz> [missed something]
[07:50:01] <raeburn> need to document which protocols allow updating to newer hash functions (based on smb & ekr's work)
[07:50:05] <jhutz> strong consensus IETF should not develop hash functions here, but might want to review
[07:50:12] <jhutz> mailing list is hash@ietf.org
[07:50:19] <jhutz> secmech, joe salowey
[07:50:22] --- gerardo has become available
[07:50:23] <jhutz> BOF on tuesday morning
[07:50:28] <jhutz> discussed two main topics:
[07:50:35] <jhutz> - standardization of EAP methods,
[07:50:48] <jhutz> - proposal to unify mech development strategy of GSSAPI, SASL, EAP
[07:51:08] <jhutz> discussion of status & history of EAP method development; mostly it's happened outside the IETF
[07:51:19] <jhutz> current XXX less open and interoperable than we'd desire
[07:51:34] <jhutz> concern that if we work toward standards in this space (EAP), might not want to gate it on GUAM
[07:51:54] <jhutz> determined that probably we'd want to look at only a small set of EAP methods for standardization
[07:52:21] <jhutz> discussion of GUAM was centered around looking for approaches for instead of having divergent mechs in different groups, developing a mech once and having it applicable in all these environments
[07:52:38] <jhutz> discussion of particular architectural approaches, but not clear direction set at the time of the bof
[07:53:06] <jhutz> most people in the room thought EAP standardization was important; didn't care where, except some thought it needed to be in SEC area
[07:53:25] <jhutz> GUAM - good, but no concrete proposal. some interest for authoring and reviewing drafts; not a huge amount
[07:53:32] --- WH has left: Logged out
[07:53:34] <jhutz> some discussion since then indicates there might be more
[07:53:50] <jhutz> moving forward - some work to be done finding requirements for EAP methods to standardize, and
[07:54:10] <jhutz> more work in figuring out concrete proposals for unifying mechanisms before work can be chartered
[07:54:17] <jhutz> [someone else do alien]
[07:54:54] <Jeffrey Altman> This is a brief report from the Wednesday ALIEN BoF for today's SAAG session. The ALIEN (Anonymous Identifiers) BoF discussed privacy, focusing on making various identifiers throughout the protocol stack unlinkable, thereby achieving some level of anonymity or pseudonymity. The result from the discussion was that we are not close enough of understanding the threat model and the exact problem we want to solve to consider forming a Working Group. However, the feeling of the room was that this is an important problem and worth IETF/IRTF attention. The likely next steps are writing a concrete proposal for an IRTF Research Group. Some people were also interested in organising a workshop on the topic. There was a proposal was to have an IAB workshop, but at this time it is completely unclear whether the workshop should be an IAB one or, perhaps more likely, a separate workshop to kick start the research group. One of the first working items for the research group, probably to be discussed also in the workshop, is the understand better the threat model, exact technical problems, and the requirements from those people that need the functionality. --Pekka
[07:56:17] <raeburn> MASS ...
[07:56:24] <raeburn> Jim Fenton
[07:56:40] <jhutz> [thanks, jeff]
[07:56:48] <Jeffrey Altman> [np]
[07:56:48] <nico> MASS summary is on saag list
[07:57:01] --- Peter Koch has become available
[07:57:07] <nico> (as are most others)
[07:57:29] --- robertml has become available
[07:57:46] <jhutz> [I have no intention to scribe presentations. We can do Q&A after them, though. We probably should have two people scribing questioners, and one doing the speaker(s)
[07:58:14] <nico> I can scribe a bit
[07:58:19] <nico> having wireless nooow
[07:58:30] <nico> I just have to get power now :)
[07:59:25] <shep> anico--- there's a seat with power available halfway back, between myself and radia
[07:59:31] --- Xag has left
[07:59:47] <jeroen> in the front right also two sockets and seats free with power
[07:59:50] <jhutz> [silly jhutz forgot to turn the mic back on before giving it to the speaker
[08:00:20] <jhutz> smb, you're working on posting the slides?
[08:00:31] <nico> I'll move
[08:01:05] --- tanupoo has left: Disconnected
[08:01:11] <smb> yes
[08:01:33] --- WH has become available
[08:01:42] <Jeffrey Altman> ITU-T Recommendation: X.805 Security Architecture for Systems Providing end-to-end Communications. Goal of presentation is to introduce the internet community to x.805
[08:01:45] <smb> I'll post them as soon as I get them.
[08:02:21] <hartmans> It turns out the slides were sent to Russ but not me
[08:02:36] <nico> are they online?
[08:02:48] <Jeffrey Altman> not yet
[08:02:52] --- Xag has become available
[08:03:02] --- gerardo has left
[08:03:03] --- Xag has left
[08:03:50] <jhutz> Do I need to pass a USB storage device to the chairs?
[08:04:04] <jhutz> Oh; the problem is that russ's laptop is presenting
[08:04:09] <hartmans> So, the probably will not be available
[08:04:26] <nico> ... for a bit, right?
[08:04:34] <jhutz> how about the next speaker?
[08:04:36] <Jeffrey Altman> until the end of the presentation
[08:06:37] --- fenton has left
[08:08:27] --- ekr has become available
[08:11:16] <hartmans> The next speaker is sitting next to smb
[08:11:35] <smb> yes, and his slides are uploaded and ready to go.
[08:12:07] --- ekr has left: Online
[08:12:20] <hartmans> What sort of examples are they giving for IP networks?
[08:13:47] <nico> the current slide is hard to describe
[08:14:04] <jhutz> If you're asking about the slide I think you are, it was just a mapping of various protocols you might find in an IP stack to his three layers
[08:14:16] <shep> did he mean that the End User Security Plane is to protect the network from the user?
[08:15:22] --- mstjohns has left: Disconnected
[08:16:03] <jhutz> The last two slides weren't hard to describe to people who already know what the data, control, and management planes are
[08:17:04] <hartmans> What are those planes for IP networks though? Especially management?
[08:18:17] --- fluffy has left: Replaced by new connection
[08:19:04] <weiler> Holistic != realistic
[08:19:05] --- fenton has become available
[08:20:13] <sommerfeld> the security area uses black helicopters, not planes
[08:20:27] <shima> What's NGN?
[08:20:33] <nico> Next Gen Network
[08:20:39] <shima> thx
[08:20:43] <Jeffrey Altman> :) sommerfeld
[08:20:44] <nico> I think
[08:20:52] <tlr> Hey, NGN was missing from that list...
[08:21:16] <Jeffrey Altman> ekr: please go back to dimensions slide
[08:21:16] <nico> ekr: back to dimensions slides
[08:21:18] <robertml> Mike please
[08:21:27] <nico> (what?)
[08:21:41] <robertml> I am not in the room. Can't hear when people dont use the mike :)
[08:21:44] <Jeffrey Altman> ekr: these dimensions seem really non-orthogonal. how does this factoring work?
[08:21:46] <nico> trying to understand how this factoring works
[08:21:52] <jhutz> speaker: comsec is to insure that traffic flow is not diverted
[08:21:55] <nico> (ekr is using the mic)
[08:21:59] <jhutz> from intended source->dest flow
[08:22:05] <robertml> yes, but someone before him wasnt
[08:22:06] <jhutz> [I'll do the speaker]
[08:22:24] <nico> talking about data diversion, routing security
[08:22:45] <nico> sam: want to see an example of comms sec
[08:22:52] --- hsantos has become available
[08:23:11] <nico> ekr: this slide is weird too
[08:23:27] <nico> commsec examples: VPN, MPLS and L2TP
[08:23:34] <jhutz> (examples of comsec are VPN, MPLS, L2TP)
[08:23:52] <nico> ekr: VPN is for encrypting data
[08:23:57] <nico> sam: no! l2vpn
[08:24:06] <nico> ekr: exactly [laughter]
[08:24:23] <nico> (falling behind)
[08:24:53] <nico> ekr: I'm still baffled by this
[08:24:56] <Jeffrey Altman> ekr is giving up for now. still confused
[08:25:15] --- hardaker has left: Disconnected.
[08:25:25] <jhutz> [someone going to scribe this guy?]
[08:25:26] <nico> dennis: I don't see audit and alarm
[08:25:31] <nico> in your document
[08:25:48] <jhutz> audience: audit logs were in nonrepudiation
[08:25:53] --- robocon has become available
[08:26:10] <nico> uma:for audit and alarm non-repudiation is where you cover auditing
[08:26:21] <jhutz> (point the mic down further)
[08:26:23] <hartmans> OK, I understand this now.
[08:26:32] <nico> for alarm when you look at the layers and planes, the mgmt plane is where alarm goes
[08:26:51] <nico> dennis: don't mix the two things
[08:27:06] <jhutz> speaker: these are important concepts. I think X.805 is XXX
[08:27:16] <jhutz> to serve as a base for following secuirty recommendations
[08:27:22] <jhutz> need to address audit & alarm in more detail
[08:27:23] <nico> speaker: these are important concepts, but x.805 is in the ... we need to address in more detail audit and alarm
[08:27:35] <nico> jhutz: you're a better scribe
[08:27:36] <jhutz> on this level, nonrepudiation dimension has XXX mechanism
[08:27:43] <nico> :)
[08:27:57] <jhutz> uri: audit does belong to a separate dimension; traditionally it is not mixed with nonrepudiation
[08:27:59] <nico> uri: don't mix non-repudiation and audit
[08:28:04] <nico> ;)
[08:28:05] <jhutz> speaker: thank you
[08:28:39] <jhutz> speaker: XXX... main idea of this recommendation is the systematic approach, and 3 major concepts
[08:28:50] <jhutz> hartmans: are the examples part of the recommendation, or just part of your presentation
[08:29:04] <jhutz> hartmans: for example, does X.805 give examples how to get integrity, confidentiality on IP networks.
[08:29:09] --- robocon has left
[08:29:14] <jhutz> speaker: X.805 doesn't give recommendations, but does give some examples
[08:29:18] <jhutz> hartmans: were those the same you gave us today
[08:29:21] <jhutz> speaker: it gives more
[08:29:35] --- hsantos has left: Logged out
[08:29:42] <jhutz> jim [xxx]: for those of us who want to read the recommendation, can we obtain them without purchase?
[08:30:02] <jhutz> speaker: yes. a limited number of copies can be downloaded without purchase. need to register
[08:30:09] <jhutz> russ: for each email address you have, you can get 5 documents.
[08:30:21] <Jeffrey Altman> for each e-mail address you have, you can get 5 documents
[08:30:43] <jhutz> nico: so far, I just see a... it looks like you're asking us to think about the internet differencely
[08:30:53] <jhutz> nico: no recommendations. what do you recommend?
[08:31:02] <jhutz> speaker: x.805 recommends this approach, way of thinking
[08:31:09] <jhutz> nico: so no particular technology?
[08:31:12] <jhutz> speaker: right
[08:31:34] <jhutz> nico: so, you think the IETF process should be asking how document fits in X.805?
[08:31:38] <jhutz> speaker: I think it could be useful
[08:32:10] <jhutz> [yyy]: There has already been a replication of x.805, at a high level, in security work in XXX, which has existed for a year
[08:32:16] <jhutz> [who is yyy?]
[08:32:20] <nico> someone from lucent
[08:32:26] <hartmans> xxx: ngn focus group
[08:32:27] <nico> I forget the name
[08:32:33] <raeburn> igor something
[08:32:49] <smb> Igor Faynberg
[08:32:53] <jhutz> yyy: there are some people here, who have contributed to that, there was exactly this mechanism; a bit different approach
[08:33:18] <nico> ahFaynberg
[08:33:20] <jhutz> Igor: where I thought it has been useful is developing kinds of things under topic of ??? security key management
[08:33:34] <jhutz> Igor: good at getting assistance, but not complete for dealing with networks [is this making sense?]
[08:33:56] <jhutz> Igor: overall method desiging network, XXX; what do you have to check to see if network is secure
[08:34:12] <jhutz> Igor: I wouldn't say it is one protocol; it's an approach to a network
[08:34:15] <jhutz> russ: questions?
[08:34:36] <jhutz> zzz: agenda suggested these presentations were invited?
[08:34:39] <jhutz> russ: yes
[08:34:45] <jhutz> zzz: who invited them; what was in their mind?
[08:34:52] <nico> [laughter]
[08:34:55] <nico> [lots]
[08:35:25] <jhutz> bert: I'm here as an AD; we have to look at sec cons a lot.
[08:35:38] <jhutz> bert: do I run the risk that we have to check sec cons using this kind of approach?
[08:35:43] <jhutz> bert: was that the intention?
[08:35:51] <nico> sam: we went to geneva
[08:36:03] <jhutz> hartmans: we all went to geneva; this was an interesting tech. we believe it's importatnt to figure out how others are handling security
[08:36:28] <jhutz> hartmans: if you're writing sec cons sections, and you wanted to reference X.805, found the concepts there matched your threat well, you can do that
[08:36:40] <jhutz> hartmans: if it helps you think about things better, you can do that
[08:36:50] <jhutz> hartmans: will help understand how other SDO's think about security
[08:37:00] <jhutz> russ: no thought about imposing this mechanism on every doc that shows up
[08:37:06] <jhutz> russ: it applies to some situations, not to others
[08:37:11] --- jsalowey has left
[08:37:27] <jhutz> russ: I can't imagine a document to describe a SIP extension going through an analysis of all of these aspects for adding one field to SIP
[08:37:39] <jhutz> russ: whereas this kind of thinking might be applied to a more complete environment spec
[08:37:48] <jhutz> russ: it's a tool; we need to see if it helps us do our job better
[08:37:55] <jhutz> uri: can you give an example of a doc to which it would apply?
[08:38:04] <jhutz> russ: I'm not sure we have one where it would apply in total
[08:38:10] <jhutz> russ: it certainly applies in some situations
[08:38:44] --- Xag has become available
[08:38:44] <jhutz> barbara frasier: I gto my feet wet with ITU for the first time a month ago
[08:38:59] <jhutz> barbara: I got dragged unti a document that someone had created.
[08:39:12] <jhutz> barbara: high-level protocol. not so much bits on the wire but messages between entities
[08:39:32] <jhutz> barbara: was pointed at x.805, which I'd never seen, to try to apply it to what I was looking at
[08:40:12] <jhutz> barbara: some of the language is a bit different. I usually think about authorization. It appears not mentioned in their dimensions, until you read the doc and realize that their "access control" covers what we call authorizations.
[08:40:34] <jhutz> barbara: not all of it applies. Had to think about whether the thing I was looking at was services or applications
[08:40:47] <jhutz> barbara: we might not use it literally, but xxx
[08:40:53] <jhutz> barbara: it worked, it was OK
[08:41:09] <jhutz> barbara: I wish we had something similar in the IETF that would help us frame our analyses
[08:41:35] <jhutz> barbara: I did a search for the word threat. There's no standard way we do this; depends on the individuals involved, etc.
[08:41:52] <jhutz> barbara: would be nice to be consistent in terminology
[08:42:04] <jhutz> barbara: would be nice to have something like this; make our docs more consistent
[08:42:06] --- hugo.santos has become available
[08:42:22] <jhutz> aaa: interesting question - how people get to XXX.
[08:42:37] <jhutz> aaa: still a grey area
[08:42:52] <jhutz> aaa: there has been a precendent; XXX were allowed to bring docs, share within the room
[08:43:10] <jhutz> aaa: there is a mechanism by which ITU-T can have XXX with IETF
[08:43:14] <jhutz> [someone fill in my XXX's]
[08:43:31] <smb> aaa==Igor Faynberg
[08:44:22] <jhutz> bbb: perhaps what one needs here is translation from XXX-ese to YYY-ese (?)
[08:44:23] --- WH has left: Disconnected
[08:44:29] <marcos> bbb = Carrasco
[08:44:31] <jhutz> russ: going to cut this off in fairness to next speaker
[08:44:45] <smb> slides for the next talk are at http://www.machshav.com/~smb/unicode_security_considerations.pdf
[08:44:46] <jhutz> Next speakers slides are at... (smb, please post URL)
[08:44:49] <sommerfeld> itu-ese to ietf-ese
[08:45:03] <jhutz> Michel Suignard, MS
[08:45:12] <jhutz> Unicode Security Considerations
[08:45:12] <nico> example applications of x.805 to analyze some sample docs would be useful
[08:45:22] <jhutz> [I'm not going to scribe the talk]
[08:46:22] --- leifj has become available
[08:46:55] --- Harald Alvestrand has become available
[08:47:57] --- javier has left
[08:48:56] --- danwing has left
[08:49:05] --- danwing has become available
[08:54:26] <Harald Alvestrand> the phone system is not a secure system......
[08:55:05] <smb> not secure, but he's not talking about that kind of failure mode
[08:55:59] <Harald Alvestrand> not? try remembering the difference between 800-1234-567 and 877-1234-567
[08:56:26] <Harald Alvestrand> that one went to court.....
[08:58:06] <shep> I thought the famous paypal example was www.paypa1.com
[08:58:12] <smb> they both happened
[08:58:12] --- Xag has left
[08:58:39] <shep> oh, of course
[08:58:49] <jeroen> same thing for IDN
[08:59:05] <nico> but the other one demonstrates that ASCII alone is problematic
[08:59:06] <jeroen> which brings up the question..... do we like what mozilla did or no
[08:59:20] <danwing> Same thing for 800-OPERATOR and 800-OPERATER (one owned by AT&T, the other later created by MCI).
[08:59:20] <fenton> So why does IDN allow mixed character sets in names?
[08:59:24] <nico> depends on what domains we frequent
[08:59:49] <nico> because some of us are multilingual? (speculating)
[09:00:03] <Harald Alvestrand> fenton: IDN WG decided not to mess in ICANN's business. There's too much politics in the namespace!
[09:00:10] <smb> danwing: right -- those aren't numbers, which is part of the poit.
[09:00:13] <fenton> Yeah, but how many languages do we need in the same word or short phrase?
[09:00:32] <tlyu> if you have a domain populated by polyglots...
[09:00:42] --- m.behringer has left: Replaced by new connection
[09:00:59] <fenton> hta: That makes sense, too bad it has created a vulnerability though
[09:01:08] <danwing> Yes, they're not numbers, but the same problem (common mispellings) is the problem for ASCII and Unicode, as well as malicious use of "l" (letter "L") and "1" (digit one).
[09:01:38] --- Xag has become available
[09:01:42] <nico> point taken about single words... (but remember, 'w' is not formally available in spanish, yet it's used plenty -- languages evolve and borrow things from others)
[09:01:48] --- Xag has left
[09:02:06] <marcos> Not true. "w" is part of the Spanish alphabet for 50 years now
[09:02:10] <danwing> I have to say those HTTP addresses on the screen are impressive.
[09:02:20] <nico> danwing: still not numbers
[09:02:37] <nico> 7 and 1 can be confused -- in handwriting, maybe in some fonts
[09:02:55] <fenton> What way do you read it if there's a mix of Arabic and Latin between dots?
[09:03:07] <nico> marcos: which stresses my point
[09:03:09] <nico> thanks
[09:03:21] <nico> ^stresses^reinforces
[09:03:23] <nico> :)
[09:03:27] <marcos> bows
[09:04:17] <nico> also, japanese typically mixes three scripts
[09:04:20] <nico> and more
[09:04:47] <Harald Alvestrand> current ICANN guidelines are very permissive.......
[09:04:56] <hartmans> fenton: Note that we asked registries to adopt appropriate guidelines. They did not. We're now trying to help them
[09:04:56] <tlyu> bidirectional typography hurts my head. it hurts my head even more that apparently people who are multilingual in l2r and r2l languages can supposedly read such mixtures readily.
[09:05:23] <fenton> nico: good point. maybe need to have rules about which char sets may mix in a hostname?
[09:05:30] <nico> and all-kanji words are probably quite susceptible to this -- limiting the number of scripts in names doesn't help
[09:05:34] <Harald Alvestrand> I suspect they read them in the same way that Norwegians could read [\] as ÆØÅ in the 80s....
[09:06:16] <fenton> hta: You Norwegians are way too tolerant
[09:06:30] <shep> smb is giving talk at the technical plenary. Plenary starts in about 54 minutes. smb's talk will probably start in the first 30 minutes
[09:06:40] <shep> ooops... wrong room
[09:07:08] <nico> how to judge confusability?
[09:07:11] <hartmans> Jim, jck has a draft int the rfc-editor queue that you should probably read on this issue
[09:07:14] <danwing> Fenton: can't do that. If you prohibit it, you're prohibiting some trademarks from being registered. I'm thinking of a company called 3com and 3M as examples which, as I recall, had difficulties registering 3com.com and 3m.com.
[09:07:17] <tlyu> what's more amusing is that {|} are considered the lowercase forms of [\] despite how they're typed
[09:07:42] <fenton> Sam: will look for that, thanks
[09:08:43] <fenton> Dan: And also the-artist-formerly-known-as-Prince's symbol too?
[09:09:01] <nico> I presume we have no software that can programmatically detect confusability amongst glyphs in standard fonts
[09:09:09] <nico> though it seems doable
[09:09:24] <fenton> nico: probably typesize dependent
[09:09:29] <marcos> UT36 has published lists, though
[09:10:32] <tlyu> but i can forsee some legitimate uses for domains containing archaic characters...
[09:10:34] <danwing> I don't remember what Prince's symbol looked like. Apparently nobody could buy his albums in Amazon and he changed back to "Prince" anyway. ;-)
[09:11:14] <nico> tlyu: no doubt similar to the above 3com example
[09:11:21] <Harald Alvestrand> he didn't try to buy the Unicode consortium to register it......
[09:12:02] --- jeroen has left
[09:12:16] <fenton> I don't understand the problem with 3com and 3m...they're in the same character set, right?
[09:12:20] <smb> he changed back to Prince when the contract that got in the way expired
[09:12:52] --- jeroen has become available
[09:12:58] <nico> I could see wanting mathematical symbols in a name (think of mathematica or something)
[09:13:16] <nico> fenton: the DNS label starting with a digit, I think that was the issue
[09:13:24] <tlyu> are the rendered characters shown excluded as well?
[09:13:45] <nico> that's my impression
[09:13:51] <tlyu> many of "archaic" are valid IPA characters
[09:13:55] <leifj> nico: mathematicians would just register \TeX expressions
[09:13:58] <nico> IPA?
[09:13:59] <marcos> Slide 13, excluded, yes.
[09:14:17] <nico> leifj: we're talking about corporations who wish to advertise widely
[09:14:27] <nico> (even if to a narrow audience)
[09:14:27] <Harald Alvestrand> likely not - IPA has its special code page.
[09:14:29] <leifj> nico: thats right
[09:14:36] <Harald Alvestrand> (International Phonetic Alphabet)
[09:14:44] <tlyu> oh so those are archaic glyphs not in the IPA code page?
[09:15:11] <tonyhansen> are these slides available somewhere?
[09:15:35] <jhutz> randy preshun: in the presentation, you talked about the importance of identifying the script of a language
[09:15:48] <fanf> http://www.machshav.com/~smb/unicode_security_considerations.pdf
[09:15:52] <jhutz> randy: there is a document in WGLC which is an update to the language tag registry to identify script in use
[09:16:02] <jhutz> randy: this is the XXX wg in the APP area
[09:16:10] <nico> so, again, what do they recommend?
[09:16:16] <jhutz> ccc: I've been following.... One thing that scares me is....
[09:16:23] --- tanupoo has become available
[09:16:35] <nico> we can't add previously-assigned codepoints to the prohibited tables of stringprep profiles, right?
[09:16:38] <jhutz> ccc: Has there been a study where you follow net and securiy admins around and...
[09:16:49] --- FDupont has become available
[09:16:56] <jhutz> ccc: there's lots of scripts, etc that they've written which could be broken here
[09:17:04] <jhutz> nico, correct
[09:17:09] <jhutz> michel: use normalization
[09:17:15] <nico> so... what should we do?
[09:17:23] <nico> publish a BCP saying "avoid these?
[09:17:32] <nico> or something else?
[09:17:33] <jhutz> ccc: net admins are always dealing with raw data, not doing protocol design
[09:17:39] <danwing> The problem with 3com and 3m is they are trademarks (company names), but because hostnames couldn't start with a digit, they couldn't be registered in DNS. This has obviously been overcome. My point is that we can't prohibit an intermixing of character sets in a domainname because a trademark (company name) may well include a mix of character sets, just as 3com and 3M are a mix of leading digits and letters.
[09:17:40] <jhutz> ccc: they're writing quick scripts, etc
[09:17:45] <Harald Alvestrand> "read UTR#36 and weep"?
[09:18:15] <nico> maybe browsers need "profiles" of their users' language capabilities
[09:18:23] <jhutz> michel: XXX
[09:18:32] <jhutz> michel: at some point you have to normalize everywhere.
[09:18:34] <nico> maybe we need a way to highlight glyphs the user wouldn't expect
[09:18:45] <jhutz> michel: If you apply ASCII principles to unicode, you'll lose
[09:18:47] <nico> but no, the corps who want to use such glyphs will mind
[09:19:05] <jhutz> ddd: I usually don't got to icann meetings, but there was one near me
[09:19:10] <marcos> ddd=Carrasco
[09:19:12] <jhutz> ddd: they know they have a problem
[09:19:26] <jhutz> carrasco: XXX
[09:19:39] --- smb has left
[09:19:41] <jhutz> carrasco: one needs to develop some sort of algorithm for this that can be applied to many things
[09:19:45] <marcos> (better than ddd:XXX)
[09:19:51] <jhutz> carrasco: resist(?) domain names at the beginning
[09:19:53] <tonyhansen> [/thanks fanf]
[09:20:03] <nico> and then there's misspellings
[09:20:05] <jhutz> carrasco: also, used by reg authorities
[09:20:07] <fenton> Dan: OK, so you want to register a domain for the movie "The Russians are Coming" with the backwards R the way it appears on the movie poster.
[09:20:07] <nico> this is nothing new
[09:20:18] <nico> I've seen companies register hundreds of domains
[09:20:24] <jhutz> carrasco: second XXX used by browsers; when not plain ASCII, something "lit up" similar to firefox w/https
[09:20:39] <nico> most being spelling variants of a handful of base names
[09:20:44] <jhutz> michel: I didn't want to be too idn-centric
[09:20:59] <jhutz> michel: much more details on IDN in TR#36
[09:21:11] <jhutz> michel: more to be said. more discussion in icann, ietf, unicode
[09:21:24] <jhutz> michel: people are aware of the issue; no one is sitting on their thumbs
[09:21:32] <jhutz> michel: we want to do the right thing
[09:21:45] <jhutz> carrasco: forgot to mention XXX in web consortium
[09:21:57] <jhutz> carrasco: question to do with i18n. tend to be naster than they look
[09:22:07] <jhutz> carrasco: ???
[09:22:21] <jhutz> [for open mike, I need people to round-robin]
[09:22:32] --- tlr has left: Disconnected
[09:22:36] --- jeroen has left: Replaced by new connection
[09:22:38] --- hugo.santos has left
[09:22:42] <jhutz> paul hoffman: to comment... one thing people forget is unicode is just a character reportoire and rules, not an encoding
[09:22:56] <jhutz> paul: things you're look for might be different encoding... UTF-8, UTF-16, others.
[09:23:16] <jhutz> paul: function looking for something has to look in every possible encoding. Literally perhaps 7-8 _common_ ones
[09:23:25] <jhutz> paul: difference between identifiers and text strings
[09:23:35] <jhutz> paul: much of what michel was saying has to do with identifier names
[09:23:50] --- tonyhansen has left
[09:23:51] <jhutz> paul: identifier name is one thing; "identifier=stringvalue" may be different
[09:23:55] --- tonyhansen has become available
[09:24:08] <jhutz> paul: in programming languages, identifier names might be in different encoding than string values
[09:24:45] <jhutz> hta: I still have a relevant hat for this; I'm a board member of unicode consortium
[09:25:00] <jhutz> hta: would encourage people to jump slowly when doing standings
[09:25:04] <jhutz> standards, that is
[09:25:16] <fanf> [hmm, string values that start with a combining char are probably as bad as identifiers]
[09:25:20] <jhutz> hta: implementors should read UTR36, and when they stop weeping, code appropriately
[09:25:43] <jhutz> hta: for the IETF, right thing is like what we did with IDN. We carry the identifiers.
[09:25:44] --- Xag has become available
[09:25:58] --- Xag has left
[09:25:59] <jhutz> hta: If we decide what identifiers are OK, spend lots of time, erode credibility
[09:26:05] <jhutz> hta: XXX
[09:26:12] --- tanupoo has left: ログアウトしました
[09:26:15] <jhutz> hta: unicode consortium has learned this to its pain
[09:26:42] <jhutz> hta: reason idna is stuck at unicode 3.1 is because things unicode cons said would not be changing, they were
[09:26:52] <jhutz> hta: so wrong, they had to back on their promise
[09:26:57] <marcos> s/3.1/3.2/
[09:27:08] <jhutz> hta: we should all be aware of the problem. to my mind, its' very dangerous for the IETF
[09:27:14] <jhutz> hta: to try to solve these problems in the IETF
[09:27:18] <jhutz> russ: closing microphone
[09:27:32] <jhutz> nico: problem is also bigger in other ways...
[09:27:38] <jhutz> nico: people register misspellings, etc.
[09:27:43] <jhutz> nico: not sure we can solve the problem.
[09:28:02] <jhutz> nico: as I understand, we cannot add prohibited codepoints to exsiting stringprep profiles
[09:28:09] <jhutz> nico: should we have a BCP that says "avoid these" ?
[09:28:27] <jhutz> michel: bad long-term. you'll get pressure from some communities that are not in 3.2
[09:28:47] <jhutz> michel: people will get mad who can't encode their characters (africa)
[09:28:58] <jhutz> michel: we have to create a way for protocols to be able to upgrade themselves
[09:29:09] --- jeroen has become available
[09:29:19] <jhutz> nico: there might be other ways to address the dangers here.
[09:29:28] <jhutz> nico: they're all sort of specific to applications
[09:29:43] <jhutz> nico: have browsers know what glyphs users expect; highlight others
[09:29:58] <jhutz> nico: make thiings smarter so users don't have to type passwords at their banks, etc
[09:30:20] <jhutz> michel: browser vendors have been working togetther on this
[09:30:28] <jhutz> michel: I think communication has been open...
[09:30:33] <jhutz> michel, russ: thank you
[09:30:39] <jhutz> russ: two announcements
[09:30:55] <jhutz> ekr: request from SIPPING chairs...
[09:31:12] <jhutz> ekr: SIP uses security stuff. They have sample call flows from TLS, S/MIME with actual bytes
[09:31:25] <jhutz> ekr: would like to ask someone who knows something about S/MIME and TLS to help work on this problem.
[09:31:41] <jhutz> russ: please - I looked at the certs; not even compliant with SIP recommendations
[09:32:08] <jhutz> steven farrel: EU security research programme. Very few from this sort of community represented
[09:32:30] <jhutz> stephen: would like to encourage people to take part
[09:32:40] --- nico has left
[09:32:43] --- mstjohns has become available
[09:32:43] --- hartmans has left
[09:32:48] <taiji-k> Does the URL for previous speaker's ppt (about X.805) written here?
[09:32:52] --- raeburn has left: Disconnected
[09:32:55] --- Love has left: Logged out
[09:32:56] --- fenton has left
[09:32:57] --- warlord has left
[09:32:59] --- Harald Alvestrand has left
[09:33:01] --- bert has left
[09:33:05] --- shep has left: Logged out
[09:33:05] --- stefans has left
[09:33:21] --- fanf has left: Disconnected
[09:33:54] --- tlyu has left
[09:34:15] --- gr8k@jabber.org has left: Logged out
[09:35:06] --- dumdidum has left: Disconnected
[09:36:11] --- taiji-k has left
[09:36:24] --- danwing has left
[09:36:25] --- Melinda has left
[09:37:22] --- klensin has become available
[09:40:07] --- Peter Koch has left
[09:41:12] --- leifj has left
[09:43:14] --- tonyhansen has left: Disconnected
[09:44:44] --- dumdidum has become available
[09:46:11] <dumdidum> is there any chance of getting the slides from the first presentation (ITU)?
[09:49:23] --- mike has left: Disconnected
[09:49:28] --- FDupont has left: Disconnected
[09:50:50] --- jeroen has left
[09:53:29] --- marcos has left: Disconnected
[09:53:46] --- shima has left
[09:54:43] --- mstjohns has left: Disconnected
[09:55:11] --- klensin has left
[09:56:52] --- shima has become available
[09:57:22] --- shima has left
[09:58:14] --- danwing has become available
[09:58:36] --- mstjohns has become available
[09:59:59] --- Jeffrey Altman has left: Disconnected
[10:00:23] --- weiler has left
[10:01:27] --- Jeffrey Altman has become available
[10:01:33] --- robertml has left
[10:05:05] --- jhutz has left
[10:08:03] --- Love has become available
[10:08:53] --- jeroen has become available
[10:09:38] --- Jeffrey Altman has left
[10:10:22] --- sommerfeld has left
[10:11:09] --- jeroen has left
[10:11:34] --- Love has left
[10:15:04] --- dumdidum has left
[10:18:35] --- danwing has left: Disconnected
[10:25:23] --- bert has become available
[10:25:37] --- danwing has become available
[10:25:50] --- danwing has left
[10:26:13] --- bert has left
[10:28:23] --- mstjohns has left
[11:19:52] --- dumdidum has become available
[11:20:16] --- dumdidum has left