Derrick Brashear [shadow@gmail.com/AdiumDF436461] entered the room. (4:59:11 AM)
openafs hackathon discussions (4:59:11 AM)
Derrick Brashear: first topic: extended callbacks
The topic has been set to: openafs hackathon - mountain view (4:59:11 AM)
Derrick Brashear: 1) backfill
Derrick Brashear: needs mcas from keir fraser
Derrick Brashear: miniosi - from the aborted trace project
Derrick Brashear: using only threads, sync, timers
Derrick Brashear: timers the only one not able to be swapped out for posix
Derrick Brashear: q: can we remove all the external pieces?
jaltman [jaltman@jabber.openafs.org/Home] entered the room. (5:01:27 AM)
Derrick Brashear: a: there may be cross-dependencies
Derrick Brashear: could remove vector, heap, demux
Derrick Brashear: some things e.g. allocator cache probably used indirectly
Derrick Brashear: q: threads and sync. we already have 2 interfaces, what do we gain by adding a third?
Derrick Brashear: a: possibly nothing. could support more platforms with a single api. for posix platforms, value is lower
Derrick Brashear: aside: wanted hooks to get fired when thread was created or destroyed for statistics, population of data structures, also wanted an abstract interface for kernel and userland
Derrick Brashear: also provides an lwp interface
Derrick Brashear: q additional: if we take this, we should move old code to this interface
Derrick Brashear: windows includes a posix threads implementation which supports a subset of the full pthreads
Derrick Brashear: q additional: why use this?
Derrick Brashear: a: additional abstraction needed through codebase
Derrick Brashear: instead of nested pile of ifdefs
Derrick Brashear: provides common data structures; mcas has a similar issue
Derrick Brashear: further q refinement: this is really a process question
Derrick Brashear: shift entire codebase to this api for threads?
Derrick Brashear: simon would rather see extended callbacks start with posix and port later to miniosi 
Derrick Brashear: matt feels this is a regression
Derrick Brashear: matt suggests there is a process question, moving faster versus slower
Derrick Brashear: jumped aside to discuss process question of how to manage pulling code in, how fast and how the process should scale
Derrick Brashear: branch for 1.6 final and master will be accepting new features with the idea of allowing new APIs needed by e.g. extended callbacks to stabilize
Simon Wilkinson [sxw@inf.ed.ac.uk/Adium] entered the room. (5:19:45 AM)
Derrick Brashear: aside discussion on testing and large features which come out of the closet
Derrick Brashear: git branching model for development projects: 
Derrick Brashear: simon's suggested model is that forks live in other trees; when you are ready, cherry-pick into a new tree and push to gerrit
Derrick Brashear: matt: this doesn't solve the problem of getting review of 3rd party changes
Derrick Brashear: summarization of aside: there should be sufficient documentation to make review of large changes possible
Derrick Brashear: simon: for moving forward hopefully you'd have a design discussion, produce a document, have an implementation discussion with openafs-devel, then write the code and iterate
Derrick Brashear: summary of what's in miniosi
Derrick Brashear: instead we'll take miniosi topic to later
Derrick Brashear: xcb protocol
Derrick Brashear: has been reviewed by various people including peter honeyman
Derrick Brashear: in spite of peter's approval, ...
Derrick Brashear: implements full set of operations, viced file ops, can coalesce and sequence messages
Derrick Brashear: will compress and coalesce messages of different types
Derrick Brashear: has implications for synchrony
Derrick Brashear: synchrony is tunable
Derrick Brashear: open question is whether synchrony is implicit in afs consistency model
Derrick Brashear: cache consistency guarantee of afs is incomplete
Derrick Brashear: consistency is not only consideration
Derrick Brashear: jeff's worry: protocol sematic changes depending on fileserver configurartion
Derrick Brashear: matt: if client takes read lock, there is a guarantee that anything delivered before its request is delivered
Derrick Brashear: otherwise, change in sematics can deliver performance improvement by relaxing synchrony
Derrick Brashear: if you have async delivery you get faster termination of short operation
Derrick Brashear: crux of this discussion: there should not be a controlling protocol guarantee that when my store completes there's a guarantee of delivery
Derrick Brashear: there would need to be intent and negotiation of different semantics for store on close
Derrick Brashear: simon worries we are focusing on the current poor cache manager
Derrick Brashear: marcus disagrees, says this is inherent network protocol issue
Derrick Brashear: discussion now on whether sync-on-close, synchronous callback model still makes sense
Derrick Brashear: value in different semantic choices.
Derrick Brashear: marcus: question of tradeoff. when locking is done, assume reasonable semantics given that. otherwise no
Derrick Brashear: simon suggests the perceived semantics of afs being preserved even nominally in the xcb drafts makes it easier to move forward
Derrick Brashear: simon: having a client not be able to do anything else while it's waiting for storedata to complete callbacks is a current software issue. 
Derrick Brashear: an argument i can't summarize because i'm overloading
Derrick Brashear: matt suggests a command line switch to the fileserver
Derrick Brashear: jeff argues the server switch is the wrong way to solve this
Derrick Brashear: derrick suggests a per-fid interface instead of one big switch. matt says jhutz agreed with this sort of design
Derrick Brashear: dewrrick attempts to and probably succeeds in deferring the sync/async
discussion; assuming sync is #defined on, we move back to discussing
only xcb protocol itself and not implementation etails
Derrick Brashear: jeff asks if the draft was updated with the wirtten code in mind; matt says draft 10 covers it
Derrick Brashear: question of what consensus is
Derrick Brashear: there has been no consensus call, but it is probably reasonable to do so soon
Derrick Brashear: jeff sugests the messaging is fine
Derrick Brashear: derrick believes ignoring the issues outside the protocol e.g. synchrony things are fine
Derrick Brashear: jeff contends no discussion between last october and this july, but the synchrony issue, the one which is contentious now, is the only one receiving discussion, there may be consensus otherwise
Derrick Brashear: apologies for the gap in the notes
Derrick Brashear: anyway, asynchrony question with regard to other issues
Derrick Brashear: currently for non-xcb clients, delivery is still sync
Derrick Brashear: nominally possible to change that and queue without protocol impact
Derrick Brashear: question of whether it's acceptable for one client to cause performance for everyone
Derrick Brashear: simon poses ignoring the issue of sync/async delivery will enable this to move forward quickly
Derrick Brashear: possible list of action items:
Derrick Brashear: deal with miniosi (strip to minimal or test with viced and push it first)
Derrick Brashear: disable asynchrony in implementation
Derrick Brashear: edit out mentions of it in draft (and edit in comments about trusting yoru channel)
Derrick Brashear: send out draft for consensus
Derrick Brashear: question of retaining versus reaping callbacks and performance impact for fileservers
Derrick Brashear: process discussion for standardization, development, and implementation
Derrick Brashear: conclusion: more inclusive of community desirable: push more discussion to openafs-devel
jaltman left the room (Disconnected). (7:36:22 AM)
You have disconnected (7:36:39 AM)
You have connected (8:53:31 AM)
Derrick Brashear [shadow@gmail.com/Adium69C52D3B] entered the room. (8:53:31 AM)
openafs hackathon discussions (8:53:31 AM)
Derrick Brashear: matt feels this is a regression
Derrick Brashear: matt suggests there is a process question, moving faster versus slower
Derrick Brashear: jumped aside to discuss process question of how to manage pulling code in, how fast and how the process should scale
Derrick Brashear: branch for 1.6 final and master will be accepting new features with the idea of allowing new APIs needed by e.g. extended callbacks to stabilize
Derrick Brashear: aside discussion on testing and large features which come out of the closet
Derrick Brashear: git branching model for development projects: 
Derrick Brashear: simon's suggested model is that forks live in other trees; when you are ready, cherry-pick into a new tree and push to gerrit
Derrick Brashear: matt: this doesn't solve the problem of getting review of 3rd party changes
Derrick Brashear: summarization of aside: there should be sufficient documentation to make review of large changes possible
Derrick Brashear: simon: for moving forward hopefully you'd have a design discussion, produce a document, have an implementation discussion with openafs-devel, then write the code and iterate
Derrick Brashear: summary of what's in miniosi
Derrick Brashear: instead we'll take miniosi topic to later
Derrick Brashear: xcb protocol
Derrick Brashear: has been reviewed by various people including peter honeyman
Derrick Brashear: in spite of peter's approval, ...
Derrick Brashear: implements full set of operations, viced file ops, can coalesce and sequence messages
Derrick Brashear: will compress and coalesce messages of different types
Derrick Brashear: has implications for synchrony
Derrick Brashear: synchrony is tunable
Derrick Brashear: open question is whether synchrony is implicit in afs consistency model
Derrick Brashear: cache consistency guarantee of afs is incomplete
Derrick Brashear: consistency is not only consideration
Derrick Brashear: jeff's worry: protocol sematic changes depending on fileserver configurartion
Derrick Brashear: matt: if client takes read lock, there is a guarantee that anything delivered before its request is delivered
Derrick Brashear: otherwise, change in sematics can deliver performance improvement by relaxing synchrony
Derrick Brashear: if you have async delivery you get faster termination of short operation
Derrick Brashear: crux of this discussion: there should not be a controlling protocol guarantee that when my store completes there's a guarantee of delivery
Derrick Brashear: there would need to be intent and negotiation of different semantics for store on close
Derrick Brashear: simon worries we are focusing on the current poor cache manager
Derrick Brashear: marcus disagrees, says this is inherent network protocol issue
Derrick Brashear: discussion now on whether sync-on-close, synchronous callback model still makes sense
Derrick Brashear: value in different semantic choices.
Derrick Brashear: marcus: question of tradeoff. when locking is done, assume reasonable semantics given that. otherwise no
Derrick Brashear: simon suggests the perceived semantics of afs being preserved even nominally in the xcb drafts makes it easier to move forward
Derrick Brashear: simon: having a client not be able to do anything else while it's waiting for storedata to complete callbacks is a current software issue. 
Derrick Brashear: an argument i can't summarize because i'm overloading
Derrick Brashear: matt suggests a command line switch to the fileserver
Derrick Brashear: jeff argues the server switch is the wrong way to solve this
Derrick Brashear: derrick suggests a per-fid interface instead of one big switch. matt says jhutz agreed with this sort of design
Derrick Brashear: dewrrick attempts to and probably succeeds in deferring the sync/async
discussion; assuming sync is #defined on, we move back to discussing
only xcb protocol itself and not implementation etails
Derrick Brashear: jeff asks if the draft was updated with the wirtten code in mind; matt says draft 10 covers it
Derrick Brashear: question of what consensus is
Derrick Brashear: there has been no consensus call, but it is probably reasonable to do so soon
Derrick Brashear: jeff sugests the messaging is fine
Derrick Brashear: derrick believes ignoring the issues outside the protocol e.g. synchrony things are fine
Simon Wilkinson [sxw@inf.ed.ac.uk/Adium] entered the room. (8:59:20 AM)
Derrick Brashear: rx/osd
Derrick Brashear: no summary needed of what it is
Derrick Brashear: specs at http://pfanne.rzg.mpg.de/trac/openAFS-OSD/wiki/Specs
Derrick Brashear: covers new RPCs and changes to existing ones
Derrick Brashear: starting with the fileserver
Derrick Brashear: looking at structure on that page
Derrick Brashear: upper 8 bits of osd_id represents number of stripes
Derrick Brashear: example of segment/striping model at http://pfanne.rzg.mpg.de/trac/openAFS-OSD/wiki/Introduction/Technical
Derrick Brashear: jeff: uniq ghenerated by where data is stored?
Derrick Brashear: hartmut: same as before but it wraps at 24 bits, not 32, now
Derrick Brashear: in the world where a t10 disk exists it would be up to the disk to create an object id
Derrick Brashear: the goal is to do things while allowing us to stay protocol-compatible
Derrick Brashear: the osd servers run an rxosd binary. could be the same as a fileserver, should be different partitions
Derrick Brashear: vicepa corresponds to lun 0
Derrick Brashear: osd info stored in the database, the IP of server, partition stored there
Derrick Brashear: as is policy info
Derrick Brashear: in the osd obj: part_id is like a volume number
Derrick Brashear: flag allows us to flag something "archival"
Derrick Brashear: so it doesn't get wiped
Simon Wilkinson: Derrick: Don't use an IP address, use a UUID
Simon Wilkinson: Tom: This assumes what the transport is
Simon Wilkinson: Hartmut would rather use an IP, as its simpler
Simon Wilkinson: (This is to determine OSD location)
Simon Wilkinson: Jeff is proposing to add a referral service, similar to the vldb, which a client can use to find a given OSD, given an opaque identifier from the fileserver.
Simon Wilkinson: Tom is suggesting that the OSD is registered in the vldb
Derrick Brashear: simon is explaining the concept of using the vldb only as a server address mapping service
Simon Wilkinson: Derrick is saying that the vldb would need to be extended to also know about ports
Derrick Brashear: (as was tom)
Derrick Brashear: simon asks whether this should be fixed in a protocol rev and we can go with the code as it exists
Derrick Brashear: jeff suggests we should have a union with the uuid or the address so we don't need to rev the rpc again later
Derrick Brashear: osd numbering is a relic of mrafs numbering but uses high numbers in its space to avoid mrafs number conflicts
Derrick Brashear: simon: can the osdid be the size of an afs uuid?
Derrick Brashear: marcus: does the osdid (ip) have a one to one correspondence with the device id?
Derrick Brashear: hartmut: yes
Derrick Brashear: hartmut: ideally the client has fewer round trips
Derrick Brashear: discussion of how the address information should be handled
Derrick Brashear: consensus seems to be that the structure will provide a means to have uuid in it
Derrick Brashear: hartmut: union of ip or uuid
Derrick Brashear: marcus; input parameter of a mask of what kind of address is acceptable?
Derrick Brashear: simon: avoid ipv6 question for now
Derrick Brashear: the rock is a one time authenticator for one osd to allow access as brokered by fileserver. it's a key for just one file
Derrick Brashear: discussion of requirements for the authentication rock
Derrick Brashear: jeff: the osd service needs to require authentication from the client beyond the authentication rock
Simon Wilkinson: Simon: 200bytes for rock size is too small. The rock should be of variable length
Simon Wilkinson: Tom: Much of osd_obj is invariant, bar the rock
Simon Wilkinson: Now talking about the capabilities structure (which is what's encrypted in the rock)
Simon Wilkinson: Jeff is wondering about expiration
Simon Wilkinson: Now talking about the new 'StartTransaction' and 'EndTransaction' model
Simon Wilkinson: Tom's saying we're conflating authorisation data expiry, with invariant object location metadata
Simon Wilkinson: me: We should work out what needs to be fixed now, rather than what can be deferred for later
Simon Wilkinson: Jeff: everywhere else in the code expires is an absolute timestamp. Should be renamed, or a 64bit number
Simon Wilkinson: (now looking at StartAsyncFetch)
Simon Wilkinson: Hartmut: expires will become a 64bit value
Derrick Brashear: EndAsyncFetch (and #Store) used to release resources to allow blocked changes to be unblocked
Derrick Brashear: readers and writers mtually exclude; one writer, or N readers
Derrick Brashear: (something about possibility of transactional consistency model)
Derrick Brashear: side discussion of how you roll back changes when one stripe can't commit
Derrick Brashear: simon: what happens when one osd is being DoSd and thus some portion of writes is precluded from being stored?
Derrick Brashear: possibility to defer raid5 and all
Derrick Brashear: mirroring will need fileserver rollback on txn failure
Simon Wilkinson: jeff: should we take mirroring off the table for now?
Simon Wilkinson: jeff: remove uuid from getOSDLocation, as the fileserver already knows it
Simon Wilkinson: hartmut: Also remove it from StartAsyncFetch and StartAsyncStore
Derrick Brashear: checkosdconnections lacks way to throttle client trying repeatedly to get it to recheck connections
jaltman [jaltman@jabber.openafs.org/Home] entered the room. (10:46:35 AM)
matt [matt@linuxbox.com/Psi] entered the room. (10:46:38 AM)
Derrick Brashear: jeff: mirroring deferred. when we do, mirrored files will have osd version bumped so they know the data being read is checksummed chunks,
Derrick Brashear: writing requires sending a checksum, the data and another checksum
Derrick Brashear: if the checksum matches the written data  plus the version number (possibly incremental, possibly timestamp based on txn timestamp provided by fileserver) the write succeeded
Derrick Brashear: afterwards the same checksum and dv would be written again
Derrick Brashear: in this model the replicated object is not a stream
Derrick Brashear: matt: couldn't we do it as a stream?
Derrick Brashear: jeff: no guarantee today that if you write data and read it back that you read back what you wrote
Derrick Brashear: hartmut: afs stream write also writes a checksum into a small file (bypassing cache) to allow writes to be verified after the fact
Derrick Brashear: jeff: we will have to decide on a metadata (e.g. header for every block) so client and fileserver can agree
Derrick Brashear: christof: independent of extension for osd?
Derrick Brashear: jeff: other things which read and write the data would need to know what the structure was 
Derrick Brashear: fileserver would construct the data on disk using the checksum mechanism, clients would not need to know how the checksum data was stored
Derrick Brashear: hartmut: osd metadata could also be had for local files and could contain this
Derrick Brashear: tom: parsing that data for this and vicep access would be a client capability
Derrick Brashear: jeff: checksums would not be exposed to vfs
Derrick Brashear: simon: if this is deferred, should we defer this?
Derrick Brashear: jeff: probably
Derrick Brashear: hartmut: let's go back to the slides
Derrick Brashear: volserver
Derrick Brashear: volintInfo unchanged, has an osdPolicy member
Derrick Brashear: simon: do we know no one is using these (spare field) members?
Derrick Brashear: tom: we will need a new version of this data structure
Derrick Brashear: jeff: we want to reuse this
Derrick Brashear: simon: is this part of the on-disk structure?
jhutz@jis.mit.edu/owl: I don't have time to follow this, so I will just interject one comment,
which may be out of context by now...

A few days ago, someone brought up a problem on zephyr that we're fairly
sure turned out to be a Linux VM handling issue that was fixed a few 1.4
releases ago.  The symptom was that the first block/page/chunk of a file
(I forget how much) was all zeroes, and they speculated this was because
some other client had started a write but hadn't written the whole block
yet.
Derrick Brashear: me: yes
Derrick Brashear: jeff: take it to openafs@conference.openafs.org
Derrick Brashear: jhutz, that os
Derrick Brashear: not here
Derrick Brashear: hartmut: new rpc when?
jhutz@jis.mit.edu/owl: ... and thus that their client had read and cached an uninitialized new
chunk.

In reality, that can't happen today, because the cache consistency model
prevents it.
Derrick Brashear: simon: we should come up with a set thursday and promise those within 6 months
Derrick Brashear: jeff: i'd want implementation timeframes and promises
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
Derrick Brashear: tom: if we do async, they'll be in-flight calls
matt: I like activerpcs, too
Derrick Brashear: tom: if there's corruption how do you get data back out of the osds?
Derrick Brashear: hartmut: convertROtoRW
Derrick Brashear: we're basically done
matt: i sent draft to lists, needs moderation.  don't bother telling me about online locatinos
Derrick Brashear: er. don't bother what?
matt: I didn't publish as an internet draft on line, but rather to the list
jhutz@jis.mit.edu/owl: I think we want drafts actually published as internet-drafts, in
the internet-drafts repository.
Simon Wilkinson: We need to solve the RFC-Editor question
jhutz@jis.mit.edu/owl: We do, but that is independent of the internet-drafts question.
jhutz@jis.mit.edu/owl: And, it's more complicated, in some ways, now that RFC-Editor is not a
single entity.
Simon Wilkinson: I just think it's polite to resolve what happens to them before we start squatting on internet-drafts.
jhutz@jis.mit.edu/owl: I'm not sure what you mean by squatting.
not all I-D's are destined to become RFC's.
Note also that the burden we create by submitting I-D's is several orders
of magnitude smaller than the burden created by publishing an RFC.
matt: so could someone moderate?
matt left the room. (12:39:40 PM)
Simon Wilkinson left the room. (12:41:18 PM)
You have disconnected (12:41:34 PM)
You have connected (1:24:09 PM)
Derrick Brashear [shadow@gmail.com/Adium14D58126] entered the room. (1:24:09 PM)
openafs hackathon discussions (1:24:09 PM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
You have disconnected (1:58:17 PM)
You have connected (2:44:11 PM)
Derrick Brashear [shadow@gmail.com/Adium0507F6B5] entered the room. (2:44:11 PM)
openafs hackathon discussions (2:44:11 PM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
You have disconnected (2:53:14 PM)
You have connected (5:02:57 PM)
Derrick Brashear [shadow@gmail.com/Adium050E1963] entered the room. (5:02:57 PM)
openafs hackathon discussions (5:02:57 PM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
You have disconnected (5:05:41 PM)
You have connected (8:11:44 PM)
Derrick Brashear [shadow@gmail.com/Adium04774428] entered the room. (8:11:44 PM)
openafs hackathon discussions (8:11:44 PM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival ers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
Simon Wilkinson [sxw@inf.ed.ac.uk/Adium] entered the room. (8:46:52 PM)
Simon Wilkinson left the room. (8:47:20 PM)
You have disconnected (11:13:15 PM)
You have connected (11:18:54 PM)
Derrick Brashear [shadow@gmail.com/AdiumFCAF4BB0] entered the room. (11:18:54 PM)
openafs hackathon discussions (11:18:54 PM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
You have disconnected (3:48:34 AM)
You have connected (4:15:16 AM)
Derrick Brashear [shadow@gmail.com/AdiumABD14B2A] entered the room. (4:15:17 AM)
openafs hackathon discussions (4:15:17 AM)
jhutz@jis.mit.edu/owl: was an agenda posted anywhere?
Derrick Brashear: yup.
jhutz@jis.mit.edu/owl: where?
Derrick Brashear: don't care right now. i'm not your google. trying to take notes
Derrick Brashear: hartmut: traverse can gather stats. getosdsupport is a dummy; do we suppoort this? getarchcandidates will figures out what needs archival copies created
Derrick Brashear: tom: times in GetArchCaniddtates should have larger timestamps
matt: where did xcb action items get sent?
Derrick Brashear: jeff: should that be an absolute time, even if a delta?
Derrick Brashear: xcb todo list is in an email simon hasn't sent. also in the log of this channel.
Derrick Brashear: hartmut explains how he uses getarchcandidates
Derrick Brashear: jeff says other uses possible
Derrick Brashear: action item: use 64 bit times
Derrick Brashear: hartmut: rpc numbers will need to be rev'd
Derrick Brashear: hartmut: salvage via vol rpc, to allow servicing osds
Derrick Brashear: can correct dize/link counts as needed
matt: log url please?
Derrick Brashear: listobjects allows listing the objects in an osd
Derrick Brashear: somewhere off http://conference.openafs.org/ i assume
matt: first thing I tried didnt go
Derrick Brashear: hartmut: listobjects has a "single" option to tell you which files will be offline if this is offline
Derrick Brashear: not exported, alas. i'll bug russ later
Simon Wilkinson: Looks like this room isn't being logged. I have logs that I can post. Later. Let's not disrupt Derrick's minuting.
Derrick Brashear: discussion of how salvage() compares to salvageserver
jhutz@jis.mit.edu/owl: I have logs also, though they're likely not very pretty.
I'll be happy to send you a set, Matt.
Derrick Brashear: tom: how these features work together (e.g. shadow clones, this) should be investigated
Derrick Brashear: hartmut: splitvolume
Derrick Brashear: variable: interface for get/set on the volserver, unlike gewt/set which uses 2 rpcs
Derrick Brashear: statistic: see what rpcs have been used
Derrick Brashear: tom: statistics we have suffer from being static
Derrick Brashear: no ability to add new stats
Derrick Brashear: simon: rxgen could have an extension, but not in scope for this
Derrick Brashear: hartmut: getpolicyviolations
Derrick Brashear: policies canbe checked to see what's violating what policies via rpc
Derrick Brashear: since e.g. old files will exist
Derrick Brashear: tom: out params of split rpcs?
Derrick Brashear: hartmut: strings. jeff: string parsing then a problem
Derrick Brashear: overview of t10 structures
Derrick Brashear: read and write for rxosd (t10)
Derrick Brashear: writePS and readPS for pseudo striping
Derrick Brashear: discussion of 64 bit times for osd i/o deferred until tomorrow
Derrick Brashear: hardlink rpc in volserver for splitting volumes, for when a split causes a copyonwrite'd vnode to now be in 2 volumes
Derrick Brashear: tom: should we vectorize hardlink so multiple links could be created in a single rpc
Derrick Brashear: hartmut: bulk?
Derrick Brashear: derrick: yes
Derrick Brashear: hartmut: activerpcs
Derrick Brashear: rpc refresh
Derrick Brashear: first topic
Derrick Brashear: uuids everywhere
Derrick Brashear: ali: a client should be idenified by a uuid at all times
Derrick Brashear: tom: both endpoints should have a uuid in the  rpc representing it
Derrick Brashear: jeff: it should be asserted by the rpc auth mechanism, which i will talk about later
Derrick Brashear: simon: same mech as before? (negotiated at a start of a connection)
Derrick Brashear: jeff: yes
Derrick Brashear: tom: leaves a race open
Derrick Brashear: tom: addresses change?
Derrick Bt
Derrick Brashear: simon: then that wants to be part of a security context
Derrick Brashear: s/context/mechanism/
Derrick Brashear: but the discussion here is when there is no security mechanism
Derrick Brashear: jeff: we'd be binding a key to the uuid we already have
Derrick Brashear: simon: has to be established as part of security context
Derrick Brashear: jeff: has to be bound to one
Derrick Brashear: tom: uuid would be passed as in parameters.
Derrick Brashear: jeff: as part of a new connection you'd get a initcallback3 and be able to establish the uuid doesn't match
Derrick Brashear: simon: what happens if a server changes while an rpc is in-flight?
Derrick Brashear: simon: jeff says he wants uuids everywhere but is arguing about this. what do you want?
Derrick Brashear: simon: what happens when there is no security layer
Derrick Brashear: jeff: we what do now is in tellmeaboutyourself
Derrick Brashear: matt: what we do now represents the cache manager
Derrick Brashear: jeff: bound to every connection the machine establishes
Derrick Brashear: digression of what uuid means now
Derrick Brashear: discussion of using uuid as accelerator for looking up connections inside the rx library
Derrick Brashear: server uuids targeted from client rpcs would be able to allow a race to not happen if a server changes under an in-flight rpc
Derrick Brashear: discussion of client rpc on wire
Derrick Brashear: ali: notes the client uuid would help with too many threads blocking in tellmeaboutyourself
Derrick Brashear: simon: is there a use case in client uuids going to the server? worth revving rpcs?
Derrick Brashear: (silence for a beat)
Derrick Brashear: matt: discussion of host uuid assertion, does that matter?
Derrick Brashear: tom: do a dh-negotiation apriori withthe server to get uuids signed
Derrick Brashear: simon: real problem is admins clone machines; you won't fix that
Derrick Brashear: simon: only advantage is during the pre "tellmeaboutyourself" processing window. does that matter?
Derrick Brashear: jeff: you also get capabilities; you need that too
Derrick Brashear: simon: reiterates "do we need it for clients"
Derrick Brashear: tom: (later) union payload of client uuid or nothing. not secure, not assertion
Derrick Brashear: jeff: adds no new information since you can't use it without e.g. capabilities
Derrick Brashear: simon: 2 questions, rx level and application level
Derrick Brashear: application level has full payload, rx level has restricted access
Derrick Brashear: jeff: at application level you've already done the work
Derrick Brashear: simon: so you'd need uuids in the rx header to solve this
Derrick Brashear: simon: are we done?
Derrick Brashear: derrick: everywhere. volume ids? vnodes?
Derrick Brashear: marcus: in acls?
Simon Wilkinson [sxw@inf.ed.ac.uk/Adium] entered the room. (5:03:59 AM)
Derrick Brashear: matt: (asks about a prior topic)
Derrick Brashear: agree we don't talk about client uuids
Derrick Brashear: server uuid as in parameter to avoid data mutating operations going to the wrong server
Derrick Brashear: simon: seems like a layer violation
Derrick Brashear: simon: belongs in the transport
Derrick Brashear: only works in an encrypted layer
Derrick Brashear: and only with per-server keys
Derrick Brashear: marcus: including so cooperating servers dtrt? 
Derrick Brashear: simon: yes
Derrick Brashear: jeff: but today we don't
Derrick Brashear: jeff: unix cm does nothing. windows cm filters with it when it processes callbacks
Derrick Brashear: matt: uuids also used by extended callbacks
Derrick Brashear: jeff: it's in the callback messages. it should be used everywhere
Derrick Brashear: simon: would only go in data-mutating rpcs
Derrick Brashear: tom, jeff: if you do it somewhere you need to do it everywhere
Derrick Brashear: would only apply to shadow clones and stale rws
Derrick Brashear: marcus: comes under "admin shoots self in foot", proposes we ignore
Derrick Brashear: simon: should we be doing this gradually? 
Derrick Brashear: flip switch when enough rpcs are done?
Derrick Brashear: jeff: and are potentially unwilling to accept old rpcs
Derrick Brashear: jeff: create an rx security class which just contains the payload. do it all at once, much cleaner
Derrick Brashear: simon: are we killing this?
Derrick Brashear: yes
Derrick Brashear: tom will propose a new rx clear class which exchanges new uuids
matt [matt@linuxbox.com/Psi] entered the room. (5:17:18 AM)
Derrick Brashear: jeff: do you want uuids for volumes?
Derrick Brashear: ali: why?
Derrick Brashear: tom: so you can serve multiple cells from a server
Derrick Brashear: hartmut: would fit better into a fid
Derrick Brashear: ali: that's the volume id; it'd be cell-specific
Derrick Brashear: jeff: you'd want the volume id to be derived from the cell id
Derrick Brashear: simon: volume uuid would be a huge amount of work
Derrick Brashear: no one wants it now
Derrick Brashear: cell uuids
Derrick Brashear: derrick wants it for in param for callback messages
matt: is the list of behaviors the windows cm does but unix doesn't a list of features that unix cm is supposed to implement also?
Derrick Brashear: probably. ask later
Derrick Brashear: simon: cell uuids not worth considering for this round
Derrick Brashear: pts uuids:
Derrick Brashear: jeff: it would be sids (as jeff also said for cell)
Derrick Brashear: jeff: you'd take the sid, take a sid category and use the pts id as an input
Derrick Brashear: discussion of whether it will enable a larger id space
Derrick Brashear: yes, but no database changed needed yet
Derrick Brashear: would enable binding to AD
Derrick Brashear: jeff will document how this will work
Derrick Brashear: not proposed for today
Derrick Brashear: 64 bit time
Derrick Brashear: jeff: potentially need microsecond level for timing issues for e.g. databases
Derrick Brashear: nothing records time that finely; there are always windowing issues depending on the true timer granularity
Derrick Brashear: jeff proposes 100ns
Derrick Brashear: hartmut: would vnode time fields change to 64 bit?
Derrick Brashear: doesn't have to be now
Derrick Brashear: we'd lose granularity on systems which could not represent better than 32 bit time
Derrick Brashear: discussion of where unix time is moving
Derrick Brashear: jeff will write something for afs3 stds. 
Derrick Brashear: simon asks if we will write a single document
Derrick Brashear: yes
Derrick Brashear: so jeff will contribute to that ocument
Derrick Brashear: simon: new rpcs would just wrap old one with time conversions
Derrick Brashear: rxosd
Derrick Brashear: number of files per volume quota
Derrick Brashear: hartmut: when a volume would use osd they force not too many files, just for archiving, so they use this quota there
Derrick Brashear: obvious use case is for tape storage
Derrick Brashear: what needs to be changed to do this?
Derrick Brashear: hartmut: vol rpcs which which get volint info, rpcs to set quota
Derrick Brashear: just the volintinfo structure, so every rpc which uses it
Derrick Brashear: SetInfo ListVolumes ListOneVolume
Derrick Brashear: simon proposes action item for the changes to the .xg for this
Derrick Brashear: christof will do this
Derrick Brashear: also changes to VolumeStatus, StoreVolumeStatus, FetchVolumeStatus structures and thus GetVolumeStatus SetVolumeStatus
Derrick Brashear: and pioctl changes but those aren't as critical
Derrick Brashear: protocol from fetch status
Derrick Brashear: hartmut: rename residencymask to protocol
Derrick Brashear: actual element (1) filled by fileserver doesn't change
Derrick Brashear: simon: old fetchstatus should stay as is, use new fetchstatus, and don't deal with this; do it in the new rpc
Derrick Brashear: hartmut: new field should be protocol
Derrick Brashear: dataaccessprotocol
Derrick Brashear: after some discussion of the point
Derrick Brashear: osd policy in volumeheaderashear: marcus: wants krb5 for rxk5/rxgk
Derrick Brashear: simon: rxgk wants arbitrary names
Derrick Brashear: simon: you can have an opaque blob
Derrick Brashear: marcus: can you print them?
Derrick Brashear: maybe not
Derrick Brashear: display names are not canonical name
Derrick Brashear: simon: you might need to ship the canonical blob and the rendered display name as per some system
Derrick Brashear: marcus: pts needs to be able to have input and output of names used to apply permissions
Derrick Brashear: simon: you'd have sxw as a user in pts
Derrick Brashear: with all security models, sxw would be associated with the kad name sxw, rxk5 sxw@INF.ED.AC.UK and a gssapi name from whatever gssapi says to it
Derrick Brashear: jeff: you'd be able to bind e.g. jaltman@ATHENA.MIT.EDU to tequila in
the andrew cell
Derrick Brashear: simon: more general need for "how names work with security mech"
documents
Derrick Brashear: marcus: you don't need a general-purpose solutin just for these
matt: hopefully, there is an action item on union topic--I don't know what future discussion we are deferring it to
Derrick Brashear: simon: you want it. marcus: you need to be able to define what the edge
cases are
Derrick Brashear: discussion of why an opaque blob is ok 
Derrick Brashear: marcus: you need to define where the opaque blob comes from
Derrick Brashear: and you don't want them to type in dns
Derrick Brashear: simon: they see the names they see now
Derrick Brashear: unless you do a "show all printed names"
Derrick Brashear: marcus: you'd need a definition of all that stuff
Derrick Brashear: simon: there's be "identifier plus opaque" which you don't know how to render
Derrick Brashear: but it might be a union which is the (opaque) gssapi name plus the displayname
Derrick Brashear: and you print the display name
Derrick Brashear: marcus: right now there is one name attrribute; we want to be able to have more
Derrick Brashear: jeff: there's a description from 2004 afsig of how to do this
Derrick Brashear: simon: (how) does this affect what we're revving?
Derrick Brashear: marcus: do nothing. do what's needed for krb5. do everything.
Derrick Brashear: are the options
Derrick Brashear: simon: it's probably a separate project
Derrick Brashear: discussion of what the options are
Derrick Brashear: jeff: ptserver should be rewritten to use internal or external database
Derrick Brashear: discussion as to whether this should be put aside
Derrick Brashear: jeff: there are resources to do (some of) this work
Derrick Brashear: marcus: 2 things we could do. define new rpc interface
Derrick Brashear: define a way to map it into ldap
Derrick Brashear: marcus: bosserver has notion of list users
Derrick Brashear: jeff: need the ability to confirm the superuser list is even the
canonical thing
Derrick Brashear: marcus: it's baked into lots of servers
Derrick Brashear: simon: will probably remain a list of strings
Derrick Brashear: marcus: volume backup process thinks names are names and instances
Derrick Brashear: simon: afsname in tc_tapeLabel?
Derrick Brashear: derrick: you'd want it to continue being the pts name
Derrick Brashear: simon: name and permanent name for the tape so it's not that
Derrick Brashear: 64 bit volume ids
Derrick Brashear: jeff: no objection to adding, objecting to using
Derrick Brashear: don't want to start using them, how do you downgrade for old clients?
Derrick Brashear: jeff: if we are revving, we should do these now
Derrick Brashear: jeff: up volume, vnode uniq to 64, but preclude their use beyond 64 bits
Derrick Brashear: preserve the -1 and 0 values (0xffffffff and 0) cannot be allocated
Derrick Brashear: discussion of how a 64 bit volume id might be used
Derrick Brashear: (preclude their use beyond 32 bits, above; apologies)
Derrick Brashear: back to prdb names
Derrick Brashear: struct budb_dumpEntry also contains a budb_principal (which is a ktc principcal)
Derrick Brashear: derrick argues it should containa  pts name
Derrick Brashear: no argument
Derrick Brashear: 64 bit quota
Derrick Brashear: simon: affects: fetchvolumestatus, storevolumestatus
Derrick Brashear: so we're already changing these
Derrick Brashear: also would need an extension to the dump format
Derrick Brashear: derrick: VolumeDiskData structure needs to become implementation specific and we need a wire structure
Derrick Brashear: hartmut: hopes it doesn't overlap with his tags
Derrick Brashear: 64 bit block usage
Derrick Brashear: FetchVolumeStatus, StoreVolumeStatus and the volintInfo and volintXInfo structure-taking things
Derrick Brashear: simon: dump may have extent issues also, needs to be confirmed
Derrick Brashear: vice statistics also need block size changes
Derrick Brashear: volume level fetchstatus
Derrick Brashear: jeff: (abstraction violation method in the windows cm)
Derrick Brashear: simon: do it right how?
Derrick Brashear: derrick: return it in the fetchstatus (last update time of volume)
Derrick Brashear: tom: as long as it's a 64 bit time
Derrick Brashear: ali says tom will be doing the volume level fetchstatus
Derrick Brashear: tom demurrs
Derrick Brashear: and points at andrew
Derrick Brashear: per-file acls
jaltman [jaltman@jabber.openafs.org/Home] entered the room. (6:48:53 AM)
Derrick Brashear: the dfs rpcs can't simply be used
Derrick Brashear: the vlsf fileset flag can't simply be abused
Derrick Brashear: for legacy clients you just lie about access masks rather than anything else
Derrick Brashear: and can you trust the cm to not lie?
Derrick Brashear: (no)
Derrick Brashear: simon: just need to rev fetch/storeacl with defined semantics for files
Derrick Brashear: rpc signature is identical, new semantics will be defined for the new rpcs
Derrick Brashear: for old, you don't get per-file, you get it via the mask
Derrick Brashear: fetchacl is never used in a client, only storeacl
Derrick Brashear: jeff: issue is whether new fetchstatus return per-file acl or directory acl
Derrick Brashear: jeff: is per-file as of new rpc regiment
Derrick Brashear: regimen
Derrick Brashear: tom: should we consider extending the bit vectors?
Derrick Brashear: simon: shoul they be bit vectors?
Derrick Brashear: derrick: tag-value?
Derrick Brashear: simon: not sure how it would work
Derrick Brashear: simon: could see taking 16 more and then being conservative with them
Derrick Brashear: discussion of site-local bits and what you can do about them
Derrick Brashear: simon: proposes ACL list opaque contains a versionnumber
Derrick Brashear: jeff: want to return the version the tool aking understands
Derrick Brashear: simon: have a tag mapping service per-cell
Derrick Brashear: only for the site local bits
Derrick Brashear: consensus: extending acls to use 32 bits on the wire
Derrick Brashear: affetcs fetchacl, storeacl, fecthstatus
Derrick Brashear: looking at fetchstatus as a whole
Derrick Brashear: there's an interfaceversion in it
Derrick Brashear: should we leave it and make it 2?
Derrick Brashear: no
Derrick Brashear: remove in the rev'd structure
Derrick Brashear: 128 bit filetype? no. kidding. we do need more.
Derrick Brashear: jeff: wants more in windows
Derrick Brashear: symlinks to dfs exist: wants a way to add type infor for these
Derrick Brashear: add additional filetype bits: future draft, not needed to be done now
Derrick Brashear: linkcount: leave as is
Derrick Brashear: length: 64 bits instead of length-hi as 2nd half
Derrick Brashear: 64 bit dv
Derrick Brashear: instead of split
Derrick Brashear: author, owner are pts ids, make 64 bit
Derrick Brashear: (also change storestatus)
Derrick Brashear: mode bits stay the same
Derrick Brashear: parent vnode, uniq become 64 bit
Derrick Brashear: modtimes are 64 bit
Derrick Brashear: 64 bit group
Derrick Brashear: leave errorcode
Derrick Brashear: lock count. currently used. 
Derrick Brashear: it's the number of read locks. 
Derrick Brashear: when the lock count changes there's a callback. this is the new information via fetchstatus
Derrick Brashear: matt: for clients that support it they'd get sync notification, otherwise could still use this
Derrick Brashear: discussion of what information you would want to return here
matt: (asnc)
matt: er, async
Derrick Brashear: "a"sync notification, oops
Derrick Brashear: lockcount can remain the same
Derrick Brashear: dns srv records
Derrick Brashear: we're doing the vlserver, we should do the ptserver and buserver
Derrick Brashear: only questions: what are priority and other?
Derrick Brashear: weight is an input to randomization; pri can't simply be abused
Derrick Brashear: for legacy clients you just lie about access masks rather than anything else
Derrick Brashear: and can you trust the cm to not lie?
Derrick Brashear: (no)
Derrick Brashear: simon: just need to rev fetch/storeacl with defined semantics for files
Derrick Brashear: rpc signature is identical, new semantics will be defined for the new rpcs
Derrick Brashear: for old, you don't get per-file, you get it via the mask
Derrick Brashear: fetchacl is never used in a client, only storeacl
Derrick Brashear: jeff: issue is whether new fetchstatus return per-file acl or directory acl
Derrick Brashear: jeff: is per-file as of new rpc regiment
Derrick Brashear: regimen
Derrick Brashear: tom: should we consider extending the bit vectors?
Derrick Brashear: simon: shoul they be bit vectors?
Derrick Brashear: derrick: tag-value?
Derrick Brashear: simon: not sure how it would work
Derrick Brashear: simon: could see taking 16 more and then being conservative with them
Derrick Brashear: discussion of site-local bits and what you can do about them
Derrick Brashear: simon: proposes ACL list opaque contains a versionnumber
Derrick Brashear: jeff: want to return the version the tool aking understands
Derrick Brashear: simon: have a tag mapping service per-cell
Derrick Brashear: only for the site local bits
Derrick Brashear: consensus: extending acls to use 32 bits on the wire
Derrick Brashear: affetcs fetchacl, storeacl, fecthstatus
Derrick Brashear: looking at fetchstatus as a whole
Derrick Brashear: there's an interfaceversion in it
Derrick Brashear: should we leave it and make it 2?
Derrick Brashear: no
Derrick Brashear: remove in the rev'd structure
Derrick Brashear: 128 bit filetype? no. kidding. we do need more.
Derrick Brashear: jeff: wants more in windows
Derrick Brashear: symlinks to dfs exist: wants a way to add type infor for these
Derrick Brashear: add additional filetype bits: future draft, not needed to be done now
Derrick Brashear: linkcount: leave as is
Derrick Brashear: length: 64 bits instead of length-hi as 2nd half
Derrick Brashear: 64 bit dv
Derrick Brashear: instead of split
Derrick Brashear: author, owner are pts ids, make 64 bit
Derrick Brashear: (also change storestatus)
Derrick Brashear: mode bits stay the same
Derrick Brashear: parent vnode, uniq become 64 bit
Derrick Brashear: modtimes are 64 bit
Derrick Brashear: 64 bit group
Derrick Brashear: new security layer
Derrick Brashear: goals:
Derrick Brashear: better crypto - checksum size, iv gen, fcrypt
Derrick Brashear: users can impersonate server to cm
Derrick Brashear: improve key management
Derrick Brashear: algorithm agility
Derrick Brashear: per servioce keys
Derrick Brashear: permit anonymous cm keying
Derrick Brashear: use of non-kerberos security protocols
Derrick Brashear: provide krb5 as an auth mech
Derrick Brashear: provide x509 as an authentication mech
Derrick Brashear: new: bind client uuid to security context
Derrick Brashear: new: secure the callback channel
Derrick Brashear: rxk5
Derrick Brashear: historical review
Derrick Brashear: started with vab
Derrick Brashear: kad came with afs 3
Derrick Brashear: citi picked apart kad in 1991
Derrick Brashear: marcus suggests the kad in arla does not include the fixes from 1991 from citi
Derrick Brashear: (* derrick disbelieves this)
Derrick Brashear: some date arguing but it doesn't matter; it's behind us
Derrick Brashear: krb5 not well-wedded to marcus' goals
Derrick Brashear: key derivation for example not rich enough semantics in krb5 api
Derrick Brashear: simon: kerberos defines a prf used in 3961
Derrick Brashear: marcus: they're different
Derrick Brashear: simon: unless you call via gssapi you can't have it but mit has one
Derrick Brashear: marcus: standard lacked sufficient definition for interoperability
Simon Wilkinson [sxw@inf.ed.ac.uk/Adium] entered the room. (9:35:38 AM)
Derrick Brashear: simon: api doesn't matter
Derrick Brashear: we don't care. we write our own if we need it
Derrick Brashear: marcus gives a review of how the protocol works from his document
Derrick Brashear: .
jaltman [jaltman@jabber.openafs.org/Home] entered the room. (9:42:15 AM)
Derrick Brashear: point about key derivation and key-per-packet
Derrick Brashear: simon: impact of large-scale key derivation?
Derrick Brashear: marcus: psuedo header used 
Derrick Brashear: simon: what if it loops?
Derrick Brashear: marcus: includes call number. that might just loop
Derrick Brashear: calls after a loop won't be accepted
Derrick Brashear: marcus: krb5 api passes an iv of all zeroes
Derrick Brashear: marcus: advnatage of encrypting at send packet time: you can protect more data
Derrick Brashear: no known sec modules use it
Derrick Brashear: a different key in resend would involve decrypting with old key, re-encrpyting
Derrick Brashear: the data flow rxk5 needs is what rxkad needs
Derrick Brashear: simon: that doesn't matter, just the wire
Derrick Brashear: marcus: sendpacket is done before talking to server
Derrick Brashear: client must decide on its own if/how it will encrypt
Derrick Brashear: no exact mapping of checksum and enc algorithms in krb5
Derrick Brashear: simon: says you're using aes and it gets broken
Derrick Brashear: i want to turn it off
Derrick Brashear: marcus: you'd remove the aes service key
Derrick Brashear: limited support in protocol for identofying levels of support
Derrick Brashear: you mut have a server at least as new as client to support interop
Derrick Brashear: authenticator is constructed in reply, matches closely the rxkad
practice
Derrick Brashear: master key is generated by the client from a source of randomness, not
from the session key
Derrick Brashear: jeff: can server provide randomness as part of challenge?
Derrick Brashear: (to ensure the key is fully as strong as it can bem not merely half as
strong)
Derrick Brashear: server checks authenticator, gets master key, derives keys, discards master key
Derrick Brashear: call numbers are in the authenticator
Derrick Brashear: e.g. "don't allow these to be reused"
Derrick Brashear: objections
Derrick Brashear: jeff: wants more calls per conn
Derrick Brashear: the authenticator needs to accomodate a larger maxcalls
Derrick Brashear: the way you allow a larger maxcalls is by allocating cid in increments of desired maxcalls
Derrick Brashear: if you have the power to negotiate, you can use more calls
Derrick Brashear: just need to allocate cids in the increments of that number of channels
Derrick Brashear: if there was a variable list in the authenticator of the number of calls supported this could be used for that
Derrick Brashear: there could be a maxcalls in the challenge saying what the other direction supports
Derrick Brashear: big stupid argument i don't care about
matt [matt@linuxbox.com/Psi] entered the room. (10:13:46 AM)
Simon Wilkinson: yeh
Derrick Brashear: beaten to death. next point...
Derrick Brashear: no mechanism exists to force a new challenge
Derrick Brashear: jeff suggests we could add one
Derrick Brashear: simon: is there an rxk5 benefit to rechallenge?
Derrick Brashear: consensus: no
Derrick Brashear: rechallenge not a real issue
Derrick Brashear: unless we change per-packet keying
Derrick Brashear: jeff: what does the new get_key function do/take?
Derrick Brashear: marcus takes kvno, comes out of the krb5 ticket header
Derrick Brashear: and the spn, same deal
Derrick Brashear: jeff: what is the performance impact?
Derrick Brashear: marcus: not much different
Derrick Brashear: no accurate measures
Derrick Brashear: tom: hw accelerators the characteristics change
Derrick Brashear: marcus: depends on how many concurrent connections
Derrick Brashear: hard to find good data
Derrick Brashear: rod: you have to work hard to make the hardware work for you
Derrick Brashear: marcus: new cpus have hw crypto in them, special opcodes in new amd chips
Derrick Brashear: just one key context tho
Derrick Brashear: jeff: ncipher supports 1024 keys
Derrick Brashear: marcus: is that nvidia?
Derrick Brashear: jeff: it's a hardware secure module
Derrick Brashear: simon: because of tls it shows up on servers
Derrick Brashear: marcus: you can compile rxk5 against openssl to get hardware crypto
Derrick Brashear: simon: per-key will thrash the hw  leave room for that. there's a dk type to specify hos it's derived
Derrick Brashear: md5 is a poor choice
Derrick Brashear: we should change key derivation 4402
Derrick Brashear: 3961 defines the primitives
Derrick Brashear: just need to ensure there's enough randomness
Derrick Brashear: simon: random to key as defined should do des for you
Derrick Brashear: jeff: should we even support des?
Derrick Brashear: marcus: it would be trivial to eject
Derrick Brashear: no des princ in kdc if so
Derrick Brashear: only piece which is special is the key derivation logic.
Derrick Brashear: marcus: des was to make sure i got packet size calc right. not sure anyone should in production
Derrick Brashear: jeff: do we need des for transition?
Derrick Brashear: marcus: we need it for microsoft
Derrick Brashear: jeff: ?
Derrick Brashear: marcus: microsoft only has rc4, not aes
Derrick Brashear: marcus: rc4 creates per-data key, one use each, and you need a good source of entropy to generate large pool of keys
Derrick Brashear: jeff: you use the subsession key with rc4
Derrick Brashear: marcus: not with basic api
Derrick Brashear: marcus: krb5_c_encberos library what enc types to use, i'd like to eject the enctype to cksum type rtable
Derrick Brashear: "table"
Derrick Brashear: jeff: (brings up first packet, then challenge causing an upgrade, leaking data from first packet)
Derrick Brashear: marcus: minlevel
Derrick Brashear: jeff: in the challenge
Derrick Brashear: marcus: data packet already sent tho
Derrick Brashear: jeff: there's a plain vulerability because the first packet will get resent encrypted
Derrick Brashear: jeff: the authenticator has the checksum type and the drereived key type already, can we use that?
Derrick Brashear: marcus: if we could do this per cell it would be easy
Derrick Brashear: metadiscussion of how to handle e.g. per fileserver or finer-grained security requirements without side effects
Derrick Brashear: jeff: add header jusrt after standard rx header for use just after new security class, including layer in use
Derrick Brashear: simon: prefer it to be new
Derrick Brashear: marcus: incompatible
Derrick Brashear: simon: no, it's in the new security class
Derrick Brashear: makes clear (for new classes) harder; just a modified length and offset
Derrrailer is a draft by itself 
matt: matt:  isn't this an orthogonal security feature
Derrick Brashear: (argument about how it interacts with the rx library)
Derrick Brashear: discussion of whether this should be solvable at authentication time and if it's feasible
Derrick Brashear: matt: perhaps pseudo-calls can be used for this
Derrick Brashear: what's on for tomorrow?
Derrick Brashear: erm
Derrick Brashear: mix
Derrick Brashear: i can't summarize this yet
Derrick Brashear: marcus document section 5.7, we already support larger ticket sizes
Simon Wilkinson: There is no way, in the current rxk5 model, of partly upgrading the servers for a cell
Simon Wilkinson: You have to do all of the servers, before you start updating clients
Simon Wilkinson: You can deploy clients as slowly as you like, providing you are fully committed on the server side
Simon Wilkinson: Jeff: Why not add a per credential setcrypt to the settokens interface?
Simon Wilkinson: Marcus: It would be both neat and appropriate to do it
Simon Wilk/owl: > We can happily require recent versions of MIT Kerberos for rxk5

Ugh.  I'm not in favor of requiring MIT Kerberos.
Simon Wilkinson: Not MIT Kerberos vs Heimdal. MIT Kerberos 1.8 vs MIT Kerberos 1.2
jhutz@jis.mit.edu/owl: Yeah, I have no problem with requiring that the Kerberos not be old.
Derrick Brashear: discussion of what kcf looks like, simon says hcrypto can be used on top of evp
Derrick Brashear: simon: separate kerberos layer from crypto layer
Derrick Brashear: ideally kerberos is heimdal hcrypto
Derrick Brashear: openafs uses heimdal or the crypto layer from k5ssl on top of hcrypto to provide crpyto ops
jhutz@jis.mit.edu/owl: Apparently the answer to my question about "where's the document?"
is that Matt sent a 47K message to the mailing list containing it,
which is stuck in moderation, because you're not supposed to send 47K
documents to the mailing list.
tkeiser [tkeiser@sinenomine.net/6237a256] entered the room. (11:58:45 AM)
Simon Wilkinson: Ah yes. I just replied with the same.
Simon Wilkinson: (not the document, but a pointer to it)
jhutz@jis.mit.edu/owl: It's not in the afs3-stds queue, and also not in my mailbox yet.
Derrick Brashear: ask matt, ideally not disrupting the notes here
jhutz@jis.mit.edu/owl: It's on topic for here.
Derrick Brashear: that's nice.
Simon Wilkinson: Move to openafs@conference.openafs.org
matt: yes, doing that
matt left the room. (12:08:59 PM)
Simon Wilkinson: Make new ubik_SRXSecurityProc which mallocs a block of sufficient size, rather than using an existing one.
matt [matt@linuxbox.com/Psi] entered the room. (12:10:10 PM)
Derrick Brashear: review of code submission ideas
Derrick Brashear: 1) code refactoring should be in 1 patch
Derrick Brashear: then 2) add new functionality
Derrick Brashear: 3) add rxk5
matt left the room. (1:15:01 PM)
You have disconnected (2:00:41 PM)
You have connected (2:03:13 PM)
Derrick Brashear [shadow@gmail.com/AdiumC731213F] entered the room. (2:03:13 PM)
openafs hackathon discussions (2:03:13 PM)
Derrick Brashear: simon: if people want to run des to test, let them
Derrick Brashear: simon: it's up to the kerberos library what enc types to use, i'd like to eject the enctype to cksum type rtable
Derrick Brashear: "table"
Derrick Brashear: jeff: (brings up first packet, then challenge causing an upgrade, leaking data from first packet)
Derrick Brashear: marcus: minlevel
Derrick Brashear: jeff: in the challenge
Derrick Brashear: marcus: data packet already sent tho
Derrick Brashear: jeff: there's a plain vulerability because the first packet will get resent encrypted
Derrick Brashear: jeff: the authenticator has the checksum type and the drereived key type already, can we use that?
Derrick Brashear: marcus: if we could do this per cell it would be easy
Derrick Brashear: metadiscussion of how to handle e.g. per fileserver or finer-grained security requirements without side effects
Derrick Brashear: jeff: add header jusrt after standard rx header for use just after new security class, including layer in use
Derrick Brashear: simon: prefer it to be new
Derrick Brashear: marcus: incompatible
Derrick Brashear: simon: no, it's in the new security class
Derrick Brashear: makes clear (for new classes) harder; just a modified length and offset
Derrick Brashear: simon: any new security class should solve the "no way to write only encryption" 
Derrick Brashear: tom: why can't we do per-volume security?
Derrick Brashear: marcus: we can. vlserver annotation
Derrick Brashear: tom: introduce an error code for insufficient encryption
Derrick Brashear: simon: we can do securing first packet (with minlevel requirements in the security header) and go back to the negotiated level once the challenge response is received
Derrick Brashear: tom: security header/trailer is a draft by itself 
matt: matt:  isn't this an orthogonal security feature
Derrick Brashear: (argument about how it interacts with the rx library)
Derrick Brashear: discussion of whether this should be solvable at authentication time and if it's feasible
Derrick Brashear: matt: perhaps pseudo-calls can be used for this
Derrick Brashear: what's on for tomorrow?
Derrick Brashear: erm
Derrick Brashear: mix
Derrick Brashear: i can't summarize this yet
Derrick Brashear: marcus document section 5.7, we already support larger ticket sizes
Simon Wilkinson: the servers, before you start updating clients
Simon Wilkinson: You can deploy clients as slowly as you like, providing you are fully committed on the server side
Simon Wilkinson: Jeff: Why not add a per credential setcrypt to the settokens interface?
Simon Wilkinson: Marcus: It would be both neat and appropriate to do it
Simon Wilkinson: Jeff: We can happily require recent versions of MIT Kerberos for rxk5
jhutz@jis.mit.edu/owl: > There is no way, in the current rxk5 model, of partly upgrading the
> servers for a cell

That's probably OK, to a point.
I would certainly argue that handling mixed-security-class cells is AFS's
problem to solve, not rxk5's, and should be solved generically.  We had
some discussion in that regard at a previous hackathon.
Simon Wilkinson: Discussion of k5ssl vs heimdal for in kernel crypto
jhutz@jis.mit.edu/owl: > We can happily require recent versions of MIT Kerberos for rxk5

Ugh.  I'm not in favor of requiring MIT Kerberos.
Simon Wilkinson: Not MIT Kerberos vs Heimdal. MIT Kerberos 1.8 vs MIT Kerberos 1.2
jhutz@jis.mit.edu/owl: Yeah, I have no problem with requiring that the Kerberos not be old.
Derrick Brashear: discussion of what kcf looks like, simon says hcrypto can be used on top of evp
Simon Wilkinson left the room. (2:06:28 PM)
jaltman left the room (Disconnected). (2:12:15 PM)
You have disconnected (2:15:32 PM)
You have connected (7:12:37 PM)
Derrick Brashear [shadow@gmail.com/AdiumB3F6A6C1] entered the room. (7:12:37 PM)
openafs hackathon discussions (7:12:37 PM)
Derrick Brashear: simon: if people want to run des to test, let them
Derrick Brashear: simon: it's up to the kerberos library what enc types to use, i'd like to eject the enctype to cksum type rtable
Derrick Brashear: "table"
Derrick Brashear: jeff: (brings up first packet, then challenge causing an upgrade, leaking data from first packet)
Derrick Brashear: marcus: minlevel
Derrick Brashear: jeff: in the challenge
Derrick Brashear: marcus: data packet already sent tho
Derrick Brashear: jeff: there's a plain vulerability because the first packet will get resent encrypted
Derrick Brashear: jeff: the authenticator has the checksum type and the drereived key type already, can we use that?
Derrick Brashear: marcus: if we could do this per cell it would be easy
Derrick Brashear: metadiscussion of how to handle e.g. per fileserver or finer-grained security requirements without side effects
Derrick Brashear: jeff: add header jusrt after standard rx header for use just after new security class, including layer in use
Derrick Brashear: simon: prefer it to be new
Derrick Brashear: marcus: incompatible
Derrick Brashear: simon: no, it's in the new security class
Derrick Brashear: makes clear (for new classes) harder; just a modified length and offset
Derrick Brashear: simon: any new security class should solve the "no way to write only encryption" 
Derrick Brashear: tom: why can't we do per-volume security?
Derrick Brashear: marcus: we can. vlserver annotation
Derrick Brashear: tom: introduce an error code for insufficient encryption
Derrick Brashear: simon: we can do securing first packet (with minlevel requirements in the security header) and go back to the negotiated level once the challenge response is received
Derrick Brashear: tom: security header/trailer is a draft by itself 
matt: matt:  isn't this an orthogonal security feature
Derrick Brashear: (argument about how it interacts with the rx library)
Derrick Brashear: discussion of whether this should be solvable at authentication time and if it's feasible
Derrick Brashear: matt: perhaps pseudo-calls can be used for this
Derrick Brashear: what's on for tomorrow?
Derrick Brashear: erm
Derrick Brashear: mix
Derrick Brashear: i can't summarize this yet
Derrick Brashear: marcus document section 5.7, we already support larger t you like, providing you are fully committed on the server side
Simon Wilkinson: Jeff: Why not add a per credential setcrypt to the settokens interface?
Simon Wilkinson: Marcus: It would be both neat and appropriate to do it
Simon Wilkinson: Jeff: We can happily require recent versions of MIT Kerberos for rxk5
jhutz@jis.mit.edu/owl: > There is no way, in the current rxk5 model, of partly upgrading the
> servers for a cell

That's probably OK, to a point.
I would certainly argue that handling mixed-security-class cells is AFS's
problem to solve, not rxk5's, and should be solved generically.  We had
some discussion in that regard at a previous hackathon.
Simon Wilkinson: Discussion of k5ssl vs heimdal for in kernel crypto
jhutz@jis.mit.edu/owl: > We can happily require recent versions of MIT Kerberos for rxk5

Ugh.  I'm not in favor of requiring MIT Kerberos.
Simon Wilkinson: Not MIT Kerberos vs Heimdal. MIT Kerberos 1.8 vs MIT Kerberos 1.2
jhutz@jis.mit.edu/owl: Yeah, I have no problem with requiring that the Kerberos not be old.
Derrick Brashear: discussion of what kcf looks like, simon says hcrypto can be used on top of evp
Derrick Brashear: simon: separate kerberos layer from crypto layer
Derrick Brashear: ideally kerberos is heimdal hcrypto
rra [rra@jabber.openafs.org/Wanderer] entered the room. (8:27:07 PM)