[Federated-fs] Notes from the conference call, 5/29/2007

[Daniel Ellard]

My notes from the call this afternoon, 5/29/2007.

Attendees:  Daniel Ellard (NetApp), Craig Everhart (NetApp), David Ford
(NetApp), Paul LeMahieu (EMC), David Black (EMC), Renu Tewari (IBM
Research), Manoj Naik (IBM Research).  [If I missed anyone, please let me
know!]

Notes:

- in the RFC2119 boilerplate, we should convey the idea that in many places
in the document where these terms are used they imply a requirement of any
protocol that satisfies the requirements.  This is a requirements document,
not a specification, and so there's a level of indirection here that we
haven't quite captured.

If anyone knows how to convince xml2rfc to emit different prose for this
boilerplate, or has ideas how to make this clearer (or an example RFC that
has the different language) please let me know.

- The sections on "Security Considerations" and "IANA Requirements" are at
the beginning of this draft, but in the usual draft form, they come at the
end.  Was this intentional, and if so, what does it signify?

It wasn't intentional, and it signifies that I have more to learn about
xml2rfc.  I don't know why the sections were ordered in this way, but I will
figure out how to put them in the canonical order.  All future drafts will
have these sections in the usual order.

- The security considerations need to be rewritten to address attacks
against the protocol, not attacks against the system.  RFC3552 should be
used as a guide to the correct form and language to use.

- Attacks against the protocol (particularly attempts to hijack a session
and redirect it somewhere else) can be considered irrelevant if the protocol
is based on secure connections such as provided by TLS or RPC-GSS.  So
mandating that the protocol employ mechanisms such as these avoids a lot of
headaches with security.

At this point discussion dipped down into some details of different secure
connection mechanisms and their merits.  Useful discussion, but perhaps
premature, given that we're still working on the requirements, so I cut this
short.  Once we have settled on the requirements, we can discuss how to
implement them.  We might have to iterate, if we find ourselves with a set
of requirements that can't be satisfied by any known mechanisms and have to
compromise on the requirements in order to get something working.  (I don't
think we want to invent new mechanisms, unless there is no other solution.)

- In section 5, the concept of filesets should be explained in more detail.
Otherwise the reader might jump to the wrong conclusions and be confused
later.  Most readers won't jump ahead to the glossary.

- There is concern that section 5 is not clear enough to be understood by
people who don't already understand the issue.  Unfortunately, everyone on
the call understands the issues, so it's hard to figure out exactly how this
should be explained to the uninitiated.  Suggestions are more than welcome.

- One suggestion is to use examples, perhaps such as the automounter and
DFS, of things that attempt to do the sorts of things we want, but fall
short.  One of the distinctions is that the namespace and the filesystem are
woven together -- instead of the top-level of the namespace being defined
outside of the filesystem (i.e., automounter maps, that live in their own
space, from which hang file systems), the junctions are embedded in the file
system.

Suggestions for wording welcome.  I'm not sure I captured all the ideas.

- In section 6, we should lay out the success criteria -- when do we know
when the protocol is finished?  [probably just allude to the requirements
and assumptions that follow?]

- Section 7.2 could use some ASCII art to show the junction resolution.

- Perhaps 7.3 could use some ASCII art as well (not as necessary).

- Could use some ASCII art in the motivation to illustrate a federation.

IF ANYONE KNOWS OF A GOOD TOOL FOR CREATING ASCII DIAGRAMS, PLEASE LET ME
KNOW.  I have a feeling that a good diagram of a federation with several
servers, NSDB nodes, and clients may expand the frontier of 72-column ASCII
art.

- In R2, the concept of "promotion" must be made more clear.  [perhaps this
term needs to be in the glossary]

- R9: the question came up of whether a referral can redirect to a different
protocol as well as a different server (i.e., "the fileset you're looking
for is over there, but it only speaks NFSv3, so even though you're a CIFS
client, please deal with it somehow.").  Consensus was no.  The client
should assume that uses the same protocol throughout.  The NSDBs don't keep
track of what filesets are accessible via what protocols.  It may be that
some clients can't see some filesets because they're only accessible via a
subset of the protocols.  It is the responsibility of the admins to enforce
an accessibility policy that satisfies their clients.

- Should we have "views", where different clients see different parts of --
or different implementations of objects within -- the namespace, perhaps
keyed on client ID or user ID?  Consensus was no.  We don't have a mechanism
for this in the underlying protocols, and trying to layer this on top of
protocols like NFS (assuming that this is even possible -- it's not obvious)
is far beyond the scope of what we want to do right now.

Comments, remarks, etc?

The next conference call will be Monday, June 11, at 4pm Eastern time.  I'll
have a revised draft by the previous Wednesday (if not earlier).

888-765-3653 conf id 6206056

-Dan