[Federated-fs] Meeting notes

[Ellard, Daniel]

First, my heartfelt apologies to anyone who dialed in and had to listen
to that terrible music we have on our phone system for twelve minutes.
Second, apologies for being late to host the call.  In the future we may
need to push back the meeting time to 2:30 EDT in order to ensure that
this does not happen again -- would that cause a problem for anyone?

Second, for next week week it now appears that my conflicting meeting
has been rescheduled, so the weekly federated-fs conference call will
take place at the usual time (2pm EDT).

Because so many people dropped off before I joined, I'm wondering if
folks would like to have a brief conference call tomorrow to make up for
the lost discussion today.  I can host the meeting at 2pm EDT -- if
you're interested, please send email to this list.  (If nobody responds,
I will not set up the conference bridge, even though I probably do
deserve to sit on hold, listening to that music, for a while...)

I pinged Spencer and Beepy (chairs of the IETF NFS WG) about the status
of adding this work to the WG charter, but they don't have anything new
to report.  They're swamped with other WG stuff right now.  (It's not
*bad* news, it's just not any news at all.)

To follow up on the walk-through of the reqts doc, there were many
suggested changes.  I'd like to finish the walk-through before issuing a
new draft (in order to avoid confusion between things like requirement
numbers, which will change because some of the requirements are going
away).

R1: this requirement is now unnecessary.  However, in the description of
the requirement, there are definitions and concepts introduced that are
necessary elsewhere, so simply deleting the entire requirement is
impossible.  All of the clauses R1a-e are still requirements.  R1c seems
especially confusing (or counter-intuitive) to some readers so this may
require additional explanation.

R2: In its current form, the prose suggests that the interface for
"promoting" a fileset is on the server hosting the fileset.  There is
discussion that it may be better to have this done entirely by the NSDB.
The server does not need to "know" that a fileset is represented by some
FSN.

R2: If this requirement is satisfied by the NSDB, then some of the
sub-requirements are questionable.  There is feeling, however, that
those requirements are probably wrong anyway.  For example, requiring
that when a fileset is taken offline that its FSN->FSL mapping is
removed is simply impractical and creates failure conditions we don't
want to deal with.  (it's OK to require that the server make an effort
to clean up when it makes a mess, but we can't require that no messes
ever occur.)  Similarly, the contract that the promoter must confirm
that an FSN->FSL mapping is valid before promoting it is unenforcable.
The server could crash in the midst of the operation.

R8: This requirement is weakened.  R8a can be removed.  R8b is probably
not necessary (?); it should be replaced with fixed, specified (as part
of the protocol) annotations on the FSLs.  Nobody can remember why R8c
is necessary (any theories) -- it probably served some purpose, but is
it obsolete now?

If anyone has additional notes, please share!

Thanks,
	-Dan