IETF
krb-wg
krb-wg@jabber.ietf.org
Thursday, 28 July 2011< ^ >
leifj has set the subject to: IETF80 KRB-WG | http://ietf80streaming.dnsalias.net/ietf/ietf801.m3u
Room Configuration

GMT+0
[12:03:48] pod joins the room
[12:37:31] hartmans joins the room
[12:38:53] hartmans has set the subject to: krb-wg meeting IETF 81 http://tinyurl.com/ietf81-krb-wg-audio
[12:45:14] jimsch1 joins the room
[12:50:32] jhutz@jis.mit.edu/owl joins the room
[12:52:07] jhutz@jis.mit.edu/owl has set the subject to: krb-wg meeting IETF 81 http://tinyurl.com/ietf81-krb-wg-audio
[12:53:39] jhutz@jis.mit.edu/owl has set the subject to: krb-wg meeting IETF 81 http://tinyurl.com/ietf81-krb-wg-audio
[12:55:12] <jimsch1> When I tried using it the other day it did not pop live until about 5 minutes before the session
[12:57:18] <jhutz@jis.mit.edu/owl> Yup; it works now. That's kind of poor.
[12:58:15] <jhutz@jis.mit.edu/owl> Maybe.
[12:58:28] <jhutz@jis.mit.edu/owl> A small price to pay for a good scribe.
[12:58:29] ghudson@mit.edu/barnowl joins the room
[12:58:42] <jhutz@jis.mit.edu/owl> We got a second screen?
[12:59:17] <jhutz@jis.mit.edu/owl> I thought they were going to start saying no, due to the cost
not of the projector but of getting the screen set up.
[12:59:27] <jimsch1> we have a wall for a screen - but it looks fine
[13:00:17] <jhutz@jis.mit.edu/owl> Stephen's mail went to krb-wg-chairs on May 30
[13:00:56] <jhutz@jis.mit.edu/owl> And I pointed out that we didn't really need a second screen, just a
second projector, and since the IETF owns the projectors...
[13:01:11] SFTCD joins the room
[13:01:19] tlyu joins the room
[13:04:26] <jhutz@jis.mit.edu/owl> It's only had one so far.
[13:04:28] weiyinxing joins the room
[13:06:28] <jhutz@jis.mit.edu/owl> No, last call is done.
[13:06:29] ShoichiSakane joins the room
[13:06:46] <jhutz@jis.mit.edu/owl> I believe WGLC on diediedie is done, and just needs to be sent on.
[13:08:07] semery joins the room
[13:08:23] <ShoichiSakane> Is there any work on DHCP option ? do I have to work on it more ?
[13:08:49] <jhutz@jis.mit.edu/owl> I'm looking into that now.
[13:09:19] <ShoichiSakane> ic, thanks
[13:10:34] <jhutz@jis.mit.edu/owl> Yes, last I checked DHC chairs were Ted Lemon and Ralph Droms.
Then Ralph became an AD, and I don't know who replaced him in DHC
[13:13:01] <SFTCD> DHC: http://tools.ietf.org/wg/dhc/ chairs are there
[13:15:09] tsitkova joins the room
[13:18:22] Simo Sorce joins the room
[13:25:34] Satoru Kanno joins the room
[13:29:49] <ghudson@mit.edu/barnowl> My preference is for looser registration guidelines when there's no
shortage of values; the cost of conflicts is higher than the cost of
having assignments for unclear or bogus purposes.
[13:30:08] <jhutz@jis.mit.edu/owl> Greg, are you present at the meeting?
[13:30:16] <ghudson@mit.edu/barnowl> No.
[13:32:21] <jhutz@jis.mit.edu/owl> The registries in question do describe code points for which the protocol
says what you do with unknown values.
[13:32:43] <jhutz@jis.mit.edu/owl> In some cases, that means ignoring the unknown item; in one, it means
failing authentication.
[13:36:09] tlyu leaves the room
[13:36:10] tlyu joins the room
[13:37:39] <jhutz@jis.mit.edu/owl> You have mail in your mailbox about this (or shortly will).
If you make the two changes mentioned there and submit, I will
start the WGLC post-haste.
[13:38:00] <jhutz@jis.mit.edu/owl> > Hi, my name is WELLKNOWN/ANONYMOUS
Oh, cool; you can use my key-establishment service!
[13:38:24] <jhutz@jis.mit.edu/owl> > You have mail in your mailbox
That to Shoichi
[13:39:41] <ShoichiSakane> i got it
[13:40:05] <SFTCD> TLS extensions policy http://www.ietf.org/mail-archive/web/tls/current/msg07844.html
[13:41:10] <jhutz@jis.mit.edu/owl> Thanks, Thomas, for helping us with this issue.
[13:43:40] <jhutz@jis.mit.edu/owl> Nico said he would not be joining us this morning.
[13:44:02] <ShoichiSakane> Jeff, both section 5 and 6 need to be removed, right ?
[13:44:14] leifj joins the room
[13:44:29] <jhutz@jis.mit.edu/owl> All of section 6, and the second paragraph of section 5
[13:45:02] <Simo Sorce> closer to mic please
[13:46:07] <ShoichiSakane> O.K. and I will submit the new one, then I will ask to dhc wg. thanks
[13:46:09] <jhutz@jis.mit.edu/owl> Thomas needs to adjust his mic, or needs more gain.
Preferably adjust the mic.
[13:46:26] <jhutz@jis.mit.edu/owl> All you need to do is submit the new document.
I will take care of everything else.
[13:46:54] <ShoichiSakane> Oh, alright.
[13:46:56] <jimsch1> What is the use of the PAD-Short-Domain field?
[13:46:56] <Simo Sorce> short domain is used to identify a domain
[13:47:16] <hartmans> Right, but why do I need both a short domain and a long domain.
[13:47:19] <hartmans> Are conflicts OK
[13:47:26] <hartmans> what scope is it unique within?
[13:47:30] <hartmans> What scope can it be used within?
[13:47:35] <hartmans> What uses are permitted?
[13:47:42] <Simo Sorce> the precedent is in the windows world where they have a netbios domain that is used to construct shorter fullly qualified user names
[13:47:57] tidty joins the room
[13:48:06] <hartmans> Our goal should not be to do everything Microsoft has done.
[13:48:12] <Simo Sorce> the scope is local
[13:48:13] <hartmans> I.E. MS did it should not be a justification for anything.
[13:48:24] <hartmans> If you need something for AD interop, e xplain that and how you plan to use it.
[13:48:35] <Simo Sorce> just explaining where it was used to give an idea for those familiar with
[13:49:17] <hartmans> Right.
[13:49:28] <Simo Sorce> I feel the same
[13:49:38] <Simo Sorce> although for interop reasons with Ms it would be useful
[13:49:47] <Simo Sorce> it is also useful for local representation
[13:50:01] <Simo Sorce> but I am not attached to it so if people think it is confusing we can get rid of it
[13:50:50] <Simo Sorce> ack to handling ticket binding first
[13:51:26] <Simo Sorce> that's a proposal from Nico to provide a URI
[13:52:58] <Simo Sorce> for POSIX system you always need the local path so URI is additional
[13:53:02] <Simo Sorce> cannot be instead of
[13:53:07] <Simo Sorce> exactly
[13:54:09] <ghudson@mit.edu/barnowl> I don't think this is burdensome to implementations if they can just
ignore it. What I'm concerned about is how much verbiage we need if
we add this. If there's an HTTP URI, for instance, what do you to? A
DAV mount? Something else?
[13:54:36] <Simo Sorce> more people very welcome
[13:56:21] <Simo Sorce> note that homeDirectory is optional if not provided the local system can create whatever path it wants, but as Sam said it is often encessary if you really share a file system
[13:57:25] <Simo Sorce> I also tend to agree with the first commenter (sorry didn't recognize the voice) about not being just narginally more generic and satying strict to Posix
[13:57:30] <semery> Simo: the schema specifies an absolute home directory. I think having more information to base authorization decisions is better.
[13:57:36] <jimsch1> PAD-Posix-Shell
[13:57:44] <jimsch1> multiple values?
[13:58:03] ShoichiSakane leaves the room
[13:58:22] <jimsch1> Lief - very confusing for a user - if you cannot get the shell you want - you don't want a random shell
[13:58:52] <Simo Sorce> Nico was thiking it was compelling ofr users to get the best shell you can
[13:59:11] ShoichiSakane joins the room
[13:59:15] <Simo Sorce> I think it is a burden for admins and should be locally defined
[13:59:24] <ghudson@mit.edu/barnowl> I don't mind the shells field because it's pretty clear what to do
with it.
[13:59:40] <ghudson@mit.edu/barnowl> But I'm also fine with sticking to 2307 fields.
[13:59:56] <Simo Sorce> I am ok allowing multiple values but not *requiring* to implement it
[14:00:09] <Simo Sorce> ie if client understand a single value the first one is always used and no fallback is done
[14:00:20] <Simo Sorce> same for KDC filling up the field
[14:00:55] <Simo Sorce> the fallback mechanism
[14:01:13] <Simo Sorce> yes
[14:01:31] <Simo Sorce> if client does not want to fallback it always sticks in the first values
[14:01:36] <ghudson@mit.edu/barnowl> That's not necessarily worse than instantiating a passwd entry with a
shell of /bin/false or /bin/cat or something completely unable to act
as a shell.
[14:02:48] <Simo Sorce> users always will get one shell, if client is simpler it is like if all but the first chell is not available
[14:03:07] <Simo Sorce> and yes the point is that in rfc2307 loginSHell is SINGLE-VALUE
[14:03:23] <Simo Sorce> so you can use multiple *only* with a custom schema so far
[14:03:47] <Simo Sorce> I am perfectly fine with sticking with rfc2307
[14:03:52] <jhutz@jis.mit.edu/owl> Can't we handle the limitations of LDAP in LDAP?
[14:04:02] <Simo Sorce> jhutz@jis.mit.edu/owl: yes
[14:04:19] <ghudson@mit.edu/barnowl> Sticking to 2307 where possible is my baseline preference.
[14:04:25] <Simo Sorce> same here
[14:04:44] <jimsch1> Sense of the room is that single value would be better - objections?
[14:04:52] tidty leaves the room
[14:04:57] <Simo Sorce> I submit to room consesus
[14:05:01] <ghudson@mit.edu/barnowl> (Hm, I think I'm a minute or two behind the stream at this point.)
[14:05:03] <leifj> the common deployment model will be KDC fronting LDAP and we don't get to change LDAP limitations here, no
[14:05:23] <jimsch1> Next - PAD-Fullname
[14:05:44] <jimsch1> what does 2307 do here?
[14:05:56] <Simo Sorce> CN
[14:06:21] <Simo Sorce> Fullname is there because gecos is a mess
[14:06:46] <Simo Sorce> and it is not split in attributes because LDAP get's it also wrong
[14:07:06] <Simo Sorce> as it doesn't address names where surnames are not available and multipple names and wahtever
[14:07:46] <jimsch1> How standardized are different gecos fields in implemenations?
[14:08:11] <Simo Sorce> not much
[14:08:20] <Simo Sorce> gecos is free form
[14:08:28] <jhutz@jis.mit.edu/owl> The gecos field in /etc/passwd is structured, and the structure is
partly defined by the OS.
[14:08:38] <jhutz@jis.mit.edu/owl> It is _not_ free form.
[14:08:38] <Simo Sorce> only on some Oss
[14:08:52] <jhutz@jis.mit.edu/owl> It encodes office, phone number, etc.
[14:09:22] <jhutz@jis.mit.edu/owl> It's free-form as far as the passwd database is concerned, but the
"free-form" field has conventions, per-OS, which define its structure
[14:10:10] <jimsch1> Absent agreement to do something different should we stick with 2307?
[14:10:13] <Simo Sorce> that's exactly why I want a separate field that is clearly just Full Name and does not include office phone number
[14:10:25] <Simo Sorce> gecos is in the PAD as a *separate* attribute
[14:10:42] <jimsch1> concensus call?
[14:10:44] <ghudson@mit.edu/barnowl> I support 2307 consistency absent consensus otherwise.
[14:10:44] <Simo Sorce> FullName is not gecos
[14:10:56] <jhutz@jis.mit.edu/owl> Yeah, I'm inclined to agree that a true "Full Name" field is right.
[14:11:13] <leifj> simo: your answer to that consensus call?
[14:11:28] <Simo Sorce> in favor of 2307
[14:11:43] <Simo Sorce> sorry the stream seem very lagged
[14:11:46] <jimsch1> Nextr PAD-AlternateNames
[14:11:55] <jhutz@jis.mit.edu/owl> I am not commenting on this question.
[14:11:56] <ghudson@mit.edu/barnowl> I restarted the stream and am less lagged now.
[14:12:00] <ghudson@mit.edu/barnowl> But I was 1-2 minutes behind before.
[14:12:17] <jimsch1> Sam wants to know what this field is for
[14:12:40] <Simo Sorce> alternatenmaes is for auth purposes
[14:12:51] <Simo Sorce> so user can present the name he is familiar with
[14:12:53] <Simo Sorce> like an email
[14:13:15] <Simo Sorce> the implementation is free to use it or loose it
[14:13:21] <Simo Sorce> Nico suggested to make it a URI
[14:13:40] tlyu leaves the room
[14:13:47] tlyu joins the room
[14:14:32] <Simo Sorce> I am oblivious to the form
[14:14:48] <jimsch1> Next - PAD-Posix-GID
[14:15:32] <jhutz@jis.mit.edu/owl> I'm confused.
To get a ticket, the user has to present a principal name for which
the KDC can issue a ticket. We have a mechanism (see referrals) for
users to present a name other than the principal's canonical one.
[14:15:50] <Simo Sorce> we need to trasmit the gid group name so it will have to be i the list anyway
[14:16:00] <jimsch1> Next - PAD-Groups - should be PAD-Posix-Groups
[14:16:03] <jhutz@jis.mit.edu/owl> GID must not be required to be one of the supplemental groups.
[14:16:04] <jimsch1> Is this naming only?
[14:16:11] <jimsch1> i.e. - name of the field
[14:16:37] <Simo Sorce> oppose PAD-posix-groups because there is proposal to add non-posix groups too
[14:16:44] <Simo Sorce> (useful for interop)
[14:16:59] <jhutz@jis.mit.edu/owl> Are groups there listed by name or gid?
[14:17:14] <Simo Sorce> groups are stuctured
[14:17:24] <Simo Sorce> there is name, gid and potentially a third field
[14:17:30] <Simo Sorce> (type)
[14:17:31] <jhutz@jis.mit.edu/owl> what's the third field?
[14:17:38] <jhutz@jis.mit.edu/owl> Is the gid optional?
[14:17:53] <Simo Sorce> if we allow non-posix groups it will be optinal
[14:18:00] <jhutz@jis.mit.edu/owl> What about cases where you have "some other group" whose primary
ID is neither a name nor a 32-bit integer?
[14:18:01] <Simo Sorce> I think we need more discussion on list too
[14:18:23] <Simo Sorce> I think we need to discuss non-posix groups on mailing list
[14:18:29] <jhutz@jis.mit.edu/owl> If it's going to be optional, then structurally, it needs to be
optional now (even if text currently requires it to be present)
[14:18:33] <Simo Sorce> it was only discussed between me and Nico
[14:18:42] <jimsch1> Next item - ID mapping - sam says we don't talk about this now
[14:19:15] <jimsch1> Need to get people to commit to reviewing this draft - in room and on jabber
[14:20:26] hbhotz joins the room
[14:26:23] <jimsch1> SHow hands if interested in working in this space
[14:26:50] <hbhotz> Generically interested in type of solution.
[14:27:08] <hbhotz> yes
[14:27:13] <jimsch1> Intersted in implemenation
[14:31:13] <ghudson@mit.edu/barnowl> The one with krb-wg in it.
[14:31:14] <tlyu> draft-hudson-krbwg-camellia-cts-02.txt
[14:38:24] <Simo Sorce> are there still restrictions on its implementation ?
[14:38:49] <hartmans> Greg can you give Simo and the chat room the pointer to the ipr disclosure?
[14:40:18] <tlyu> AES related-key attack http://www.impic.org/papers/Aes-192-256.pdf
[14:40:51] <ghudson@mit.edu/barnowl> I actually disagree with Sam that it would be easy to hand-create a
counter mode cipher which would work well with RFC 3961. 128-bit
counter blocks are pretty constraining.
[14:42:52] <Satoru Kanno> Camellia for IPR in Kerberos: https://datatracker.ietf.org/ipr/1304/
[14:45:31] <jhutz@jis.mit.edu/owl> "do we need a fallback" is "do we need a fallback", not "should we use
camellia" or "how should we do camellia" or whatever.
I want to hear the answer to the question Sam actually asked:
"Do we need a fallback to AES" (without regard to what it should be)
[14:47:26] <jhutz@jis.mit.edu/owl> I know there is a lot of latency in the audio, but really, can we please
actually go through the questions Sam is asking, instead of turning
every question into an argument of not that question/
[14:47:41] <jhutz@jis.mit.edu/owl> The answer to "do we need a fallback" is not "isn't DES a fallback?"
It's a boolean question!
[14:47:48] <hartmans> Are there people here for whom determining the answer to the aes questions will be an important factor in whether to adopt this?
[14:48:31] <jhutz@jis.mit.edu/owl> I think it's a relevant factor.
Not necessarily an overriding one.
[14:49:13] <hbhotz> As I've said before, I support having a fallback encryption alg and having a fallback checksum defined.
[14:51:01] <hbhotz> As a separate issue, it sounds like there are good arguments for Camellia in particular.
[14:51:49] <jhutz@jis.mit.edu/owl> To be clear: as an individual, I want a fallback.
I do not have an opinion on whether we ought to adopt camellia.
[14:52:54] <hbhotz> As a US Gov't contractor, I would happier if there were something which was FIPS approved. As an individual I don't care that much.
[14:52:57] tsitkova leaves the room
[14:53:53] <jhutz@jis.mit.edu/owl> Jim's approach involves first waiting 2-3 years for people to finish
enctype documents.
[14:54:06] tsitkova joins the room
[14:54:07] <jhutz@jis.mit.edu/owl> For a fallback, we will want a standards-track document.
[14:55:28] <jhutz@jis.mit.edu/owl> As a practical matter, I don't believe that adopting Camellia now will
mean lots of people will be beating down our door with enctypes.
Preparing an enctype document takes a certain amount of work, which
is a threshold.
[14:55:31] <jimsch1> Adopt Camellia - show of hands
[14:55:31] <ghudson@mit.edu/barnowl> What other algorithms are queueing up?
[14:55:37] <ghudson@mit.edu/barnowl> (Sorry, audio lag.)
[14:56:18] leifj leaves the room
[14:56:56] <jimsch1> I would expect a korean, a russian, a possible second japanese and may be some of the AES finalists
[14:57:07] <ghudson@mit.edu/barnowl> In Kerberos specifically?
[14:57:42] <jhutz@jis.mit.edu/owl> If there really are a bunch of other things queueing up, then I think we
ought to figure out more generally some criteria for deciding what to
adopt. Note that we _have_, in our new charter, criteria for what can
be published as standards track, but we _also_ left the door open to
adopting and publishing as informational a document not meeting those.
[14:58:00] <ghudson@mit.edu/barnowl> I have not seen any other AES finalists create RFCs. SEED and GOST
have. I think we could easily reject GOST on account of having a
64-bit block size. I haven't heard anything about SEED and Kerberos.
[14:59:11] <hartmans> Greg, so you don't support adopting your own draft?
[14:59:21] <ghudson@mit.edu/barnowl> I support adopting my own draft. Sorry, I thought that was implicit.
[14:59:36] <jhutz@jis.mit.edu/owl> OK, here's a potential criterion:
Let's ask if anyone is likely to implement?
[14:59:38] <hbhotz> I responded earlier. +1
[14:59:51] <jhutz@jis.mit.edu/owl> wow this lag is annoying
[14:59:57] <jimsch1> opposes
[15:02:47] <jimsch1> If we do adopt - should the document be standards track? vote
[15:02:52] <jhutz@jis.mit.edu/owl> Speaking as an individual, I think it is worthwhile for the WG to spend
time on an enctype document if people are likely to implement, whether
or not it will be standards track(*). If no one's going to implement,
we shouldn't spend time on it.
(*) Particularly since such an algorithm is a likely choice to be later
promoted to standards track, either as an AFS fallback or otherwise.
[15:03:20] <ghudson@mit.edu/barnowl> I'm in favor of standards track.
[15:04:00] <Simo Sorce> abstain
[15:04:04] <hbhotz> Abstain on "standards track". I think the more interesting question is "mandatory to implement".
[15:04:12] <jhutz@jis.mit.edu/owl> I think Sam is asking the question upside-down.
i won't know whether I think it should be standards track until I know
whether it is the AES fallback and how broadly it ends up being
used/supported in the rest of the IETF and in the community.
[15:04:47] <jhutz@jis.mit.edu/owl> The "mandatory to implement" question is not on the table.
This encrypt will presumably be mandatory to implement for people who
claim to conform to the document that defines it.
[15:08:13] <jimsch1> Looking for document reviewers
[15:08:58] <jhutz@jis.mit.edu/owl> Please channel me.
We are going down a rathole, and it is getting us nowhere.
[15:10:20] <jhutz@jis.mit.edu/owl> I know Sam disagrees with me, but I think the question of whether the
document will be standards track is of minimal interest. The questions
we should be asking ourselves are whether there is any benefir to the
WG spending time on the document. I think there are if it is likely
to be implemented and used, whether or not it is standards track, and
not if it is not.
[15:11:22] <jhutz@jis.mit.edu/owl> Lack of support _is_ a concern to me.
[15:11:47] <hartmans> Anything else Jeff wants us to do on Camellia or should we move on to AES?
[15:11:51] <jhutz@jis.mit.edu/owl> <sigh> I give up.
There is so much lag I can't usefully participate.
[15:11:55] <hartmans> I think we've gotten all the Camellia input we can here
[15:12:22] <ghudson@mit.edu/barnowl> Restarting the stream tends to reduce the lag to 30-60s.
[15:12:22] <jhutz@jis.mit.edu/owl> Even I'm rambling. Bleah
[15:12:36] <jhutz@jis.mit.edu/owl> I think you are right.
[15:12:47] <jhutz@jis.mit.edu/owl> Let's move on, for now.
[15:12:59] <jhutz@jis.mit.edu/owl> We'll finish this on the list, somehow.
[15:14:40] ShoichiSakane leaves the room
[15:14:52] <hartmans> show of hands in favor of having a fallback
[15:15:07] <ghudson@mit.edu/barnowl> In favor.
[15:15:12] <hartmans> against?
[15:15:15] <pod> +1
[15:15:15] <tsitkova> yes, we should
[15:15:16] <jhutz@jis.mit.edu/owl> When I say we need a fallback, I think we should actually have a
second _mandatory_ enctype so that if the first one dies, people
have something they can deploy immediately.
[15:15:19] <hbhotz> Love's not here. His opinion as an implementor would be important IMO.
[15:15:58] <ghudson@mit.edu/barnowl> I think there's value in having a standard for a fallback even if
there aren't implementations everywhere. Having an established
standard shaves 1-2 years off the deployment timeline.
[15:16:15] <ghudson@mit.edu/barnowl> And I think there's sufficient evidence that Camellia is the best
fallback candidate at this time.
[15:17:41] <jhutz@jis.mit.edu/owl> We are no longer talking about Camellia
[15:17:44] <ghudson@mit.edu/barnowl> I have a certain amount of personal FUD about RC4 but none of it has
borne up except the checksum fiasco.
[15:18:47] <ghudson@mit.edu/barnowl> Based on crypto history, I think it's likely that we will have more
warning than "operators need to flip a switch overnight."
[15:19:09] <jhutz@jis.mit.edu/owl> krb4 cross-realm
[15:19:17] <tsitkova> overnight back-up ? but then it won't be tested enough
[15:19:34] hbhotz leaves the room
[15:20:19] <hartmans> show of hands: for needing fallbacks beyond what we have.
[15:20:27] <tsitkova> yes, we need
[15:20:30] <pod> yes
[15:20:33] <ghudson@mit.edu/barnowl> +1
[15:20:41] <jhutz@jis.mit.edu/owl> If you're going to channel greg's opinion, you could also channel my
counterargument
[15:20:41] <hartmans> against?
[15:21:00] <jhutz@jis.mit.edu/owl> I do think we need a fallback beyond 3DES
[15:21:19] <ghudson@mit.edu/barnowl> Agree on channeling. I'm not sure whether I think of krb4 cross-realm
as a vulnerability in a cryptosystem or a protocol.
[15:21:50] <jhutz@jis.mit.edu/owl> That's a fine line. But the point is, it is something that became
public and required, for most operators, a fairly instant switch.
[15:22:39] <ghudson@mit.edu/barnowl> I'm interested in the content of the secdir arguments against having a
fallback, but that's not on topic.
[15:23:06] <jhutz@jis.mit.edu/owl> I am too. I wish I'd been in quebec to attend that meeting.
[15:23:43] <jhutz@jis.mit.edu/owl> No, we're not back to camellia.
We have 5 minutes, and we need to take the camellia question to the list.
Let's frame some questions, then go away and think about them.
[15:23:54] <jhutz@jis.mit.edu/owl> someone channel me
[15:29:54] <jimsch1> Sam Delcares the meeting closed
[15:30:24] semery leaves the room
[15:30:30] jimsch1 leaves the room
[15:30:34] tlyu leaves the room
[15:30:42] <jhutz@jis.mit.edu/owl> GONE
[15:30:48] jhutz@jis.mit.edu/owl leaves the room
[15:31:04] Simo Sorce leaves the room
[15:31:18] weiyinxing leaves the room
[15:31:26] tsitkova leaves the room
[15:31:34] Satoru Kanno leaves the room
[15:31:36] pod leaves the room
[15:39:12] hartmans leaves the room
[15:41:04] SFTCD leaves the room
[17:00:49] hartmans joins the room
[17:01:51] hartmans leaves the room
[17:03:05] semery joins the room
[17:03:10] semery leaves the room
[17:08:16] Satoru Kanno joins the room
[17:17:05] Satoru Kanno leaves the room
[17:17:05] Satoru Kanno joins the room
[17:31:49] Satoru Kanno leaves the room