[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nfsv4] FedFS Meeting Minutes, 10/22/2009



On Thu, Oct 22, 2009 at 04:28:14PM -0400, James Lentini wrote:
> On Thu, 22 Oct 2009, Nicolas Williams wrote:
> > Comments:
> > 
> >  - I'm glad to see the schema using Integer syntax more, and
> >    fedfsNfsInfo gone.
> > 
> >  - Have we reached a consensus on path encoding?
> 
> The plan is to consider this format (and others that people would like 
> to writeup and propose) between now and mid-November and resolve this 
> question with the mid-November draft update.

OK.

> >  - Extensions to the ADMIN protocol for passing NSDB self-signed certs
> >    and/or TAs should be quite trivial: an array (<>) of opaque, each
> >    array element containing a TA in the format that PKIX WG is working
> >    on, and an array (<>) of {NSDB server hostname, opaque cert} in the
> >    create junction and lookup FSN RPCs.
> 
> Including this in the ADMIN protocol is one option. In that approach, 
> I see advantages to creating a separate procedure(s) for managing the 
> TAs. This would allow the TA management operations to be performed 
> independently of the filesystem operations.

Indeed, separate procedures for TA mgmt sounds right.  They should be
OPTIONAL to implement (if not implemented the procedures should return
an error).

An error code would be needed by which the server could say "I couldn't
authenticat the NSDB" at junction-add time.

Speaking of errors, the server should try to resolve FSNs immediately
upon junction creation, and there should be a procedure for getting a
list of FSNs/FSLs that have been unresolvable "lately", as well as
FSN/FSL resolution error counts/stats.  The recent error list/stats part
seems particularly useful: there must be a way to diagnose such
failures, and without a protocol for it the diagnostic procedures will
be vendor-specific.

> Another option to investigate is TAMP.

Yes, but I suspect that the above approach is more likely to work well
for the simple reason that it's more light-weight because it's more
ad-hoc.

Nico
--