[06:54:09] --- wyllys has become available
[06:55:57] --- wyllys has left
[11:40:08] --- wyllys has become available
[12:02:39] --- wyllys has left: Logged out
[12:03:33] --- wyllys has become available
[12:23:04] --- LOGGING STARTED
[12:34:37] --- LOGGING STARTED
[12:35:58] --- LOGGING STARTED
[12:51:31] --- Jeffrey Altman has become available
[12:51:47] --- lha has become available
[12:52:39] --- raeburn has become available
[12:53:15] --- warlord has become available
[12:53:59] --- nicow3k has become available
[12:54:17] <Jeffrey Altman> we will start soon. waiting for a speaker and an AD
[12:55:55] <raeburn> "BOF"?
[12:56:01] <nicow3k> heh
[12:56:09] <Jeffrey Altman> http://web.mit.edu/jaltman/www/kitten/ietf62/
[12:56:53] --- jhutz has become available
[12:58:04] --- DougEngert has become available
[12:58:05] --- wyllys has become available
[12:59:33] --- tlyu has become available
[12:59:58] <jhutz> lalala
[13:00:04] <jhutz> the agenda has been bashed
[13:00:19] <jhutz> for folks not in the room, we have audio.
[13:00:42] --- hartmans has become available
[13:00:45] <jhutz> lzhu: SPNEGO bis
[13:01:02] <jhutz> lzhu: sent to IESG; in last call. LC ends Mar 22.
[13:01:12] <jhutz> Implemented in longhorn beta, heimdal,
[13:01:18] <wyllys> realsoonnow...
[13:01:22] <jhutz> currently no open issues
[13:01:43] <jhutz> lzhu: any questions?
[13:01:50] <jhutz> jaltman: no questions
[13:01:57] <jhutz> jaltman: thanks to larry, participants.
[13:02:12] <jhutz> jaltman: first document to come out of this WG; beats milestone by 5 months.
[13:02:23] <jhutz> jeff, are you trying to mock me?
[13:02:25] <wyllys> Big thanks to Larry from here also.
[13:02:36] <jhutz> Next: Nico's Kitten updates
[13:02:56] <Jeffrey Altman> no, I'm not trying to mock you.
[13:03:01] <jhutz> nico: prf extension update
[13:03:18] <jhutz> nico: edits from last meeting folded into -01
[13:03:30] <jhutz> nico: PRF_READY folded into -02
[13:03:42] <jhutz> nico: ready for last call (draft-ietf-kitten-gssapi-prf-02.txt)
[13:03:54] <jhutz> nico: Krb5 GSSAPI - basically the same status.
[13:04:00] <jhutz> nico: edits, PRF folded in.
[13:04:22] <jhutz> nico: no "prf_ready"; don't use prot_ready. instead just "try it and see"; mech will return an error
[13:04:29] <jhutz> nico: if not ready to do PRF.
[13:04:44] <jhutz> nico: ready for last call (draft-ietf-kitten-kb5-gssapi-prf-02.txt)
[13:05:02] <jhutz> nico: GSSAPI domain-based names
[13:05:15] <jhutz> nico: seems ready for WGLC, but has had less review, so wait
[13:05:21] <jhutz> nico: for more comments before starting WGLC.
[13:05:34] <jhutz> nico: domain-based names for GSSAPI
[13:05:42] <jhutz> nico: folded in edits from last meeting
[13:05:59] <jhutz> nico: realm derivation changed - realm is derived from the domain part of domain-based name, not the host part.
[13:06:11] <jhutz> nico: ready for WGLC, but needs more review
[13:06:18] <jhutz> nico: stackable pseudo mechs
[13:06:40] <jhutz> : originally a single individual submission draft-williams-gssapi-stackable-pseudo-mechs-00.txt
[13:07:07] <jhutz> nico: some parts could be useful in other contexts, so split into two WG items: draft-ietf-kitten-extended-mech-inquiry-00.txt draft-ietf-kitten-stackable-pseudo-mechs-00.txt
[13:07:32] <jhutz> nico: extended inquiry API draft - indicate/inquire by attr, display attr
[13:07:58] <jhutz> nico: stackable mech API draft - compose/decompose OID, indicate negotiable mechs, negotiate mechs
[13:08:12] <jhutz> nico: both documents require review,
[13:08:26] <jhutz> nico: stackable mechs are pretty simple.
[13:08:43] <jhutz> nico: no doubt things could have been messed up during the split.
[13:08:45] <jhutz> nico: please review
[13:08:57] <jhutz> nico: guide to GSSAPI v3 - not many changes; just naming draft
[13:09:18] <jhutz> nico: IANA registry draft - currently only has text about what submissions look like. no rules, no initial content.
[13:09:34] <jhutz> nico: talked to IANA - they would like to see a section with allocation rules, and an appendix with initial content.
[13:09:54] <jhutz> nico: [xxx lost track]
[13:10:11] <jhutz> nico: overloaded a lot of information into a single registry. may or may not be the right way to do it; I don't know.
[13:10:21] <jhutz> jaltman: we can sit down and work this out
[13:10:36] <jhutz> jaltman: give us status on channel bindings?
[13:10:48] <jhutz> nico: for ipsec, we still need to decide what channel bindings are going to be.
[13:10:56] <jhutz> nico: draft in kitten tells you. this needs some review.
[13:11:09] <jhutz> nico: draft not ready for last call
[13:12:25] <jhutz> [discussion about where it belongs[
[13:12:41] <jhutz> hartmans: specific channel bindings not in BTNS's charder, and Russ has objected.
[13:12:53] <jhutz> hartmans: I think it should be done as ain individual submission.
[13:13:00] <jhutz> nico: OK, but not what we discussed before.
[13:13:31] <jhutz> [sam is giving a brief process tutorial. I'll try to catch up the back commens]
[13:13:48] <jhutz> Sam doesn't believe channel bindings for specific protocols are in kitten's charter.
[13:13:57] <jhutz> he is uncomfortable with that work being done in nfsv4
[13:14:12] <jhutz> and it's not in btns's charter, and russ objects to putting it there.
[13:14:29] <jhutz> so, he proposes that it be done as an individual submission.
[13:15:49] <jhutz> hartmans: ipsec is about to conclude; not accepting new work
[13:16:09] <jhutz> nico [earlier]: can't bind to a channel unless a channel is defined for ipsec. where is that work going to happen?
[13:16:36] <jhutz> nico: there is nothing in ipsec today that provides what is needed.
[13:17:04] <jhutz> this is getting really hard
[13:17:29] <jhutz> someone want to pick this up for a bit?
[13:17:41] <jhutz> [current discussion is about where which work will happen]
[13:19:33] <jhutz> lha: how can a protocol running on top of gss do channel bindings to gss?
[13:19:39] <jhutz> nico: we don't do that, but we could
[13:19:42] <jhutz> lha: I think you should
[13:19:47] <jhutz> jaltman: anything else?
[13:20:02] <jhutz> hartmans: IANA...
[13:20:15] <jhutz> hartmans: do we want to have discussions on whether that is the direction we want to go?
[13:20:30] <jhutz> hartmans: I've been uneasy about having to register every gss_ symbol with iana
[13:21:47] <jhutz> matt peterson: what was iana's response to being asked to do api registry
[13:21:58] <jhutz> nico: iana doesn't care what is being registered; they just apply rules
[13:22:22] <jhutz> jaltman: what do we want to have done by standards actions, xxx
[13:22:23] --- Mouse has become available
[13:22:36] <jhutz> jaltman: benefit of registries is having a place people can look
[13:23:00] <jhutz> nico: part of this is to allow for vendor-specific extensions
[13:23:18] <wyllys> Nico - speak up!
[13:23:43] <wyllys> no
[13:23:52] <wyllys> its a struggle :)
[13:24:04] <jhutz> next: Sam Hartman on gss naming
[13:24:33] <jhutz> hartmans: draft-ietf-kitten-gss-naming-01.txt
[13:24:46] <jhutz> hartmans: the goal is to be a direction statement to describe the problems we're trying
[13:24:53] <jhutz> hartmans: to solve, and approaches we're considering
[13:25:00] <jhutz> hartmans: received a lot of comments from nico
[13:25:15] <jhutz> hartmans: hoping to get comments from martin, but so far he has never actually
[13:25:22] <jhutz> hartmans: responded directly to this draft
[13:25:34] <jhutz> hartmans: I think -02 will be ready for last call. There is one issue I'd like to get some
[13:25:41] <jhutz> hartmans: discussion on today.
[13:26:14] <jhutz> hartmans: currrently today, names are atoms - indivisible strings with no structure
[13:26:25] <jhutz> hartmans: proposal is to turn them into sets and/or sequences
[13:26:32] <jhutz> hartmans: xxxx missed this
[13:26:45] <jhutz> hartmans: nico & I think we'll probably need to do that anyway
[13:26:57] <jhutz> hartmans: another proposal... allow us to choose the initiator name based on
[13:27:09] <jhutz> hartmans: what target we're talking to. can't currently do that. there is some desire
[13:27:16] <jhutz> hartmans: in kerberos to be able to do that
[13:27:28] <jhutz> hartmans: another issue that came up, which we have no closure on yet...
[13:27:35] <jhutz> hartmans: mechanisms that can assert multiple identities
[13:27:52] <jhutz> hartmans: example - X.509 mech, you may have multiple subjectAltName
[13:28:06] <jhutz> hartmans: you may want to say which of these names you want to claim for a given context
[13:28:21] <jhutz> hartmans: for pure (GSSAPI) v3 mechanisms being used by V3 apps (understand
[13:28:31] <jhutz> hartmans: composite names), you probably don't need it
[13:28:38] <jhutz> hartmans: do we want something like this for v2 applicatioins
[13:28:48] <jhutz> hartmans: I believe if we can solve that issue, we can last call -02
[13:28:58] <jhutz> nico: how to do that is easy
[13:29:06] <jhutz> nico: whether we want to do that is another story
[13:29:20] <jhutz> nico: I believe spkm had a thing where you could assert a Name in its tokens
[13:29:28] <jhutz> nico: from a v3 POV, that's irrelevant
[13:29:38] <jhutz> hartmans: unless someone comes forward and says they want to do that,
[13:29:52] <jhutz> hartmans: we're not going to. If you care, you need to speak up by end of WGLC.
[13:30:06] --- jis has become available
[13:30:18] <jhutz> nico: your draft is informational...
[13:30:28] <jhutz> hartmans: at this time, it doesn't make sense for me to be editor of a document...
[13:30:36] <jhutz> hartmans: maybe if my day job had less management work...
[13:31:03] <jhutz> hartmans: do we want to poll the room, see people interested in being doc editors?
[13:31:20] <jhutz> hartmans: you (nico) would do a good job, but have lots of docs on your plate
[13:31:30] <wyllys> understatement.
[13:31:34] <jhutz> jaltman: I as chair would be more comfortable with load spread out.
[13:31:44] <jhutz> haltman: matt peterson volunteering someone from his organization
[13:31:50] <jhutz> jaltman: anyone else?
[13:32:07] <jhutz> jaltman: next, updates on java and c# bindings
[13:32:18] <jhutz> jaltman: neither of the authors were able to come to this ietf
[13:32:31] <jhutz> draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt
[13:32:38] <jhutz> draft-ietf-kitten-rfc2853bis-00.txt
[13:32:49] <jhutz> jaltman: c# - submitted from novell, new editor
[13:33:00] <jhutz> jaltman: describes how to morph 2853 java bindings for c#
[13:33:20] <nicow3k> heh -- and a day job and a family that wants to see me from time to time :)
[13:33:25] <jhutz> jaltman: very little discussion of this doc. novell is in the process of implementing;
[13:33:35] <jhutz> jaltman: if others are interested, we'd love to hear your opinions
[13:33:52] <nicow3k> I take it Seema is not on jabber, not in this room...
[13:33:56] <jhutz> jaltman: second doc (RFC2853bis) - description of what things in RFC2853 were
[13:34:03] <jhutz> jaltman: implemented differently from what's in the spec.
[13:34:15] <jhutz> jaltman: otherwise, the document is in good shape.
[13:34:22] <jhutz> jaltman: next step is to merge the two drafts.
[13:34:36] <jhutz> nico: do you have an editor for that?
[13:34:46] <jhutz> jaltman: yes; one from Sun (Seema), one from Novell
[13:35:07] <nicow3k> taking over
[13:35:14] <jhutz> hartmans: a little concerned about style/format of these docs
[13:35:19] <nicow3k> sam: I don't think IETF spec by diff works
[13:35:49] <nicow3k> jaltman: the next step is to merge these and rfc2853 into a new doc that would obsolete the old one
[13:36:06] <nicow3k> jaltman: mic is open
[13:36:21] <nicow3k> jaltman: then we'll discuss milestones
[13:36:27] <hartmans> O, boy this could be fun
[13:36:35] <nicow3k> joe salowey: the topics that have been coming up lately
[13:36:58] <nicow3k> joe: ISM WG, enhancements to EAP, EAP has been held to be not applicable
[13:37:09] <nicow3k> joe: we're looking to see if the GSS-API is applicable
[13:37:23] <nicow3k> joe: this is a heads up about interest in this
[13:37:55] <nicow3k> joe: also I'm looking at a number of IETF auth frameworks (SASL, GSS, EAP...), at some point we should look at merging these things
[13:38:18] <nicow3k> joe: some of the GSS v3 enhancements could help (PRF, Naming, ...)
[13:38:47] <nicow3k> sam: so we seem to have some time left
[13:38:54] <nicow3k> sam: joe brought up some interesting points
[13:39:07] <nicow3k> sam: this is very much half-baked, joe's the primary instigator
[13:39:22] <nicow3k> sam: we have a miserable situation in the IETF w/ sec mechs
[13:39:32] <nicow3k> sam: (long list of technologies)
[13:39:42] <nicow3k> sam: and one-off mechs too
[13:39:49] <nicow3k> sam: you know, hash stuff
[13:39:54] <nicow3k> sam: and SSH!
[13:40:13] <nicow3k> sam: and so there's a kind of matrix: if I pick this protocol, what auth techs can I use
[13:40:29] <nicow3k> sam: some are very limited (HTTP has ...) blah, blah
[13:40:49] --- vph has become available
[13:40:53] <nicow3k> sam: and really, the way I want the matrix to look is: regardless of what protocol I pick I can use any mech I want
[13:41:06] <nicow3k> sam: because if I do that I only have to get security right once
[13:41:11] <nicow3k> sam: in my organization
[13:41:21] <nicow3k> sam: so, to get folks thinking about this
[13:41:29] <nicow3k> sam: all these mechs do roughly the same thing
[13:41:37] --- vph has left
[13:41:50] <nicow3k> sam: you're stopped by small problems of standardization and programming
[13:41:59] <nicow3k> sam: we can do the standardization here
[13:42:11] <nicow3k> sam: so I'm going to compare everything to GSS cause we're here now
[13:42:26] <nicow3k> EAP is like GSS but the server send first token
[13:42:31] <nicow3k> no wrap/unwrap
[13:42:42] <nicow3k> the mechs folks use today have a "key fallout"
[13:42:52] <nicow3k> two keys, actually
[13:43:14] <nicow3k> EAP has a better developed sense of ....
[13:43:21] <nicow3k> naming/channel binding
[13:43:36] <nicow3k> their concept of channel binding may map onto our concept of naming
[13:43:54] <nicow3k> their client ID is weaker than our names but more useful
[13:44:05] <nicow3k> there are stackable pseudo-mechs for EAP
[13:44:18] <nicow3k> and when you do that you need channel bindings between layers
[13:44:25] <nicow3k> they call that cryptographic binding
[13:44:44] <nicow3k> they have a description language for the sec properties of their mechs
[13:45:19] <nicow3k> SASL is like GSS< but lacks the PRF, its concept of naming is not as well developed, except when doing GSS it has this funky thing called an authorization ID
[13:45:33] --- Mouse has left
[13:45:37] <nicow3k> SASL supports either the client or server as initiators of the exchange
[13:45:44] <nicow3k> this depends on the protocol and the mechanism
[13:45:54] <nicow3k> I think this is even as bad as implementation dependent
[13:45:56] --- Mouse has become available
[13:46:05] <nicow3k> GSS is a lot like GSS
[13:46:09] <nicow3k> (laughter)
[13:47:00] <nicow3k> For EAP the negotiation model is that the server decides what mech to use
[13:47:27] <nicow3k> for SASL the client generally picks from a list offered by the server w/o downgrade attack ("bidding down")
[13:48:00] <nicow3k> you can abort in the middle of auth
[13:48:05] <nicow3k> for GSS we have SPENGO
[13:48:07] <nicow3k> SPNEGO
[13:48:18] <nicow3k> if you don't know how it works, now's the time to find out!
[13:48:22] <nicow3k> SSH I like
[13:48:33] <nicow3k> the client and server shout at each other offers
[13:49:21] <nicow3k> the client picks one and the server rejects or the key exchange fails the client loses
[13:49:36] <nicow3k> the key exchange ends in two things: a key and an exchange hash
[13:49:52] <nicow3k> and ssh authenticates the server to the client
[13:50:00] <nicow3k> this protocol doesn't have a good concept of naming
[13:50:11] <nicow3k> pubkeys are not named
[13:50:29] <nicow3k> then there's the ssh user authentication protocol
[13:50:53] <nicow3k> this has something like the SASL authz IDthe client tries one mech
[13:51:10] <nicow3k> then the server tells whether we can do this or are done or how to continue
[13:51:55] <nicow3k> the client needs to know what it's tried so it doesn't try again
[13:52:05] <nicow3k> jhutz: this is all implementation dependent
[13:52:47] <nicow3k> jhutz: the client has to keep trying until it can't go on or succeeds
[13:52:52] <nicow3k> back to sam
[13:53:03] <nicow3k> sam: TLS supports pubkey certs, PSK
[13:53:32] <nicow3k> and it supports Kerberos, sortof (details)
[13:53:48] <nicow3k> are there any other actual authentication frameworks in IETF...?
[13:54:04] <nicow3k> MIKEY has some authentication goop
[13:54:27] <nicow3k> uri: MIKEY is good, but it's multicast specific
[13:54:52] <nicow3k> uri: it's auth deals in multicast key distribution -- Kerberos, EAP, etc... wouldn't be aplicable
[13:54:59] <nicow3k> not following
[13:55:05] <nicow3k> (me not following)
[13:55:35] <nicow3k> sam: consider using certs to get access to the multicast stream
[13:55:45] <nicow3k> and consider that MMUSIC uses MIKEY to configure unicast streams
[13:56:00] <nicow3k> if I was an admin I'd be annoyed if MIKEY didn't support the mechanism I wanted
[13:56:17] <nicow3k> (again, not following)
[13:56:47] <nicow3k> sam: I want to be able to use any mechanism in any app
[13:57:14] <nicow3k> jhutz: so you want developers to be able to pick the most applicable framework for their protocol, but be able to use any mech
[13:57:17] <nicow3k> sam: exactly
[13:57:27] <nicow3k> jhutz: so mech gateways
[13:57:32] <nicow3k> sam: that's one way
[13:57:57] <nicow3k> sam: I want a solution, but I'm not particularly interested in any one of them
[13:58:22] <nicow3k> joe: I'd rather see these mechs (new mechs) developed together for all frameworks rather than rely on 'gateways'
[13:58:27] <nicow3k> ...
[13:58:53] <nicow3k> sam: long term I'd like to live in a world where ppl know about gateways and new mechs will work through them all
[13:59:17] <nicow3k> but basically I agree with you that if the gateways are not easily workable, then it might not fly
[13:59:39] <nicow3k> so my assumption is that we can get the gateways to get to the point where they'll meet most folks' needs
[13:59:51] <nicow3k> and then look at mechs-all-at-once
[14:00:09] <nicow3k> joe: it would be more efficient to design the mechs with these different frameworks in mind
[14:00:41] <nicow3k> mark: I don't necessarily want to know what mechs I'll be using, I need to know what capabilities I need and what caps each mech offers
[14:00:49] <nicow3k> mark: nico's draft may be a start point
[14:00:57] <nicow3k> mark: it goes a bit deeper than that
[14:01:08] <nicow3k> mark: we need to be able to plug-in mechs
[14:01:29] <nicow3k> mark: the framework implementations have to be pluggable
[14:01:38] <nicow3k> mark: I'm wondering if the WG can do anything about this
[14:01:58] <nicow3k> markL and refining the semantics of the default mech (GSS_C_NULL_OID)
[14:02:24] <nicow3k> sam and mark argue about sysadmin vs. app policy
[14:03:07] <jhutz> hartmans: I think this is moving into a different topic
[14:03:15] <jhutz> hartmans: I'm happy to do that, but...
[14:03:22] <jhutz> jaltman: joe, any more questions?
[14:03:38] <jhutz> joe: I'd like to explore the idea of developing mechs in parallel.
[14:04:07] <jhutz> hartmans: want to be able to reuse as much of the mech spec and implementation as possible
[14:04:15] <jhutz> hartmans: don't want to have case statements in spec
[14:04:31] <jhutz> uri: it would be good if mechs would just perform a few extra tasks
[14:04:44] <jhutz> uri: export identities, exact crypto protections it uses, key material
[14:04:55] <jhutz> uri: this is why people are looking at eap
[14:05:17] <jhutz> hartmans: we think we have the generic keying material in the GSS PRF
[14:05:22] <jhutz> hartmans: we'd like your review
[14:05:33] <jhutz> uri: already sent some comments
[14:05:47] <jhutz> nico: quick response to uri
[14:06:15] <jhutz> nico: for some mechs, we won't know in advance what it uses.
[14:06:18] <jhutz> nico: e.g. kerberos
[14:06:29] <jhutz> nico: for others, we know up front what it will use
[14:06:37] <jhutz> nico: current gssapi qop concept is badly broken
[14:06:52] <jhutz> uri: in some protocols, access control is based on identity, accessed object,
[14:06:57] <jhutz> uri: and under what sort of protection
[14:07:52] <nicow3k> wow, this is an interesting meeting!
[14:07:53] <jhutz> jaltman: what I was hearing is there's a desire to define a base set of
[14:08:00] <jhutz> jaltman: operations on which things can be built
[14:08:14] <jhutz> jaltman: is that right? if so, where? not in kitten's charter
[14:10:09] --- Mouse has left
[14:10:12] <jhutz> rlbob: another distinguishing factor is integration model
[14:10:31] <jhutz> rlbob: one of sasl's successes is it makes it clear how to integrate into app proto
[14:10:45] <jhutz> rlbob: gssapi - not sure what integration model is
[14:10:51] <jhutz> hartmans: gss is clearly a lot of rope
[14:11:01] <jhutz> hartmans: all of these frameworks meet different app domains
[14:11:22] <jhutz> hartmans: it's interesting that the mechs are very similar, even though the frameworks are very different
[14:11:56] <jhutz> rlbob: maybe different frameworks come from different needed integration models
[14:12:07] <jhutz> hartmans: if you want an easy integration model, use sasl
[14:12:25] <jhutz> hartmans: if you understand your needs really well and have complex requirements, use gss
[14:12:45] * warlord has set the topic to: Kitten (Daughter of CAT) BOF: new topic
[14:12:55] * jis has set the topic to: Nico Williams at Bat
[14:13:16] <lha> Nico on soapbox
[14:13:28] <jhutz> nico: matt, the default mech/mech set don't have to be global config file as in Solaris
[14:13:38] <jhutz> nico: the right default is "whatever mechs you have credentials for"
[14:13:52] <jhutz> nico: the right default mech is "the first one for which you have credentials"
[14:14:15] <jhutz> matt: what if you have creds for more than one mech
[14:14:24] <jhutz> nico: either it's nondeterministic or its the first one
[14:14:37] <jhutz> nico: I know you want this to be app-specific config, but I don't feel
[14:14:49] <jhutz> nico: sympathetic - you can make app provide the right oid
[14:16:14] <jhutz> matt: ...
[14:16:23] <jhutz> nico: what I hear you saying is you want pluggable mechanisms
[14:17:00] <jhutz> nico: we can't tell people to do that. there are monolithic and pluggable multi-mech implementations, and ther eare single-mech implementations
[14:17:22] <jhutz> jaltman: do you have specific platforms in mind?
[14:17:42] <jhutz> matt: for example, aix or some mobile thing, where I want to port my app
[14:18:22] <jhutz> jaltman: you're always going to have something older that doesn't have the functionality
[14:18:39] <jhutz> jaltman: any other open topics
[14:18:46] <jhutz> jaltman: no. so, milestones
[14:19:08] <nicow3k> s/sympathetic/not sympathetic
[14:19:26] <nicow3k> jaltman: milestones
[14:19:53] <nicow3k> jaltman: we're not making the milestone on GSS-API _v2_ clarifications
[14:20:12] <nicow3k> sam: as an individual, it's not clear we want to do v2 clarifications
[14:20:55] <nicow3k> jaltman: is it worth reviewing and clarifying GSS-APIv2u1
[14:20:57] <wyllys> It seems like an extra step and maybe not necessary.
[14:21:15] <nicow3k> jhutz: are you asking if GSS-APIv2u2 is worth doing?
[14:21:33] <nicow3k> jaltman: no, the clarifications would be for inclusion into the v3 document
[14:21:44] <wyllys> oh, thats a little different.
[14:22:10] <nicow3k> jaltman: various little issues
[14:22:10] <nicow3k> that we talked about on the list
[14:22:58] <jhutz> the style here is that we have lots of small things that feed into a v3 doc
[14:23:05] <wyllys> I think no, just do v3. Discussions and issues would be tracked via WG mailing list, I dont think WG should spend extra effort to carve out a separate doc .
[14:23:18] <jhutz> jaltman: producing this informational thing is a milestone leading to input to v3
[14:23:50] <wyllys> thanks jeff.
[14:24:35] <wyllys> (sittin on hands).
[14:25:53] <jhutz> matt volunteered someone
[14:25:57] <wyllys> whew.
[14:26:09] <jhutz> jaltman: I have a volunteer to edit, if legwork is done
[14:26:21] <jhutz> matt volunteered someone to examine the archives to do some of that work
[14:26:31] <jhutz> jaltman: update this milestone to may 2005?
[14:26:38] <jhutz> matt: ok
[14:27:09] <jhutz> jaltman: I don't think we need to edit any others.
[14:27:23] <jhutz> jaltman: we're done
[14:27:30] --- tlyu has left: Logged out
[14:27:33] --- hartmans has left
[14:27:41] --- raeburn has left: Disconnected
[14:28:07] <wyllys> bye.
[14:29:24] --- wyllys has left
[14:30:07] --- warlord has left
[14:44:46] --- jhutz has left: Disconnected
[14:46:44] --- jis has left
[15:30:12] --- raeburn has become available
[15:30:15] --- lha has left: Lost connection
[15:30:33] --- raeburn has left
[15:34:02] --- tlyu has become available
[15:34:13] --- tlyu has left
[16:58:05] --- Jeffrey Altman has left
[17:51:03] --- lukeh has become available
[17:53:30] --- lukeh has left