Re: Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)

Hi David,

Lots of good stuff trimmed (and thank you for them!).  Just one comment for
this thread...

On Thu, Jan 02, 2020 at 10:08:23AM -0500, David Noveck wrote:
> On Sun, Dec 22, 2019 at 9:14 PM Benjamin Kaduk <[email protected]> wrote:
> 
> > On Fri, Dec 20, 2019 at 09:46:22AM -0500, David Noveck wrote:
[...]
> > > > In a similar "discuss discuss" vein, Section 11.10.8 describes a
> > > > scenario that does not give much clarity, at a protocol level, into
> > what
> > > > degree of replication synchronization a client can expect from a given
> > > > file system that advertises multiple replicas.  I recognize that this
> > is
> > > > de facto just stating the deployed reality, but it's also hard to feel
> > > > good about having this level of ambiguity in a propsed standard,
> > >
> > > It gets easier over time.  Sigh!  This would be the fourth Proposed
> > > Standard with this issue :-(
> > >
> > > Still I think we can do a bit better by relyimg on the three special
> > cases
> > > listed at
> > > the end of that section and adding something like the following after the
> > > list:
> > >
> > >    When none of these special situations apply, there is no basis,
> > >    within the protool, for the client making assumptions about the
> > >    contents of a replica file ststem and its relationship to previous
> > >    file sytem instances.  This may mean that switching between file
> > >    system that are not read-only is not available, where either the
> >
> > Hmm, do we want to add a descriptor like "nominally identical" to "file
> > systems" (note: plural)
> >
> 
> Will do.
> 
> 
> >
> > >    client does not use or the server does not support the
> > >    fs_locations_info atribute.
> >
> > That helps some.  We might consider a note in the first paragraph (near
> > "The namespace will typically be constructed") about the details of that
> > being configured in an out-of-band manner.
> >
> 
> I don't think details can be provided since this is pretty much up to the
> server although we can make it clear that the server constructs this on
> the basis of what it knows about the file system and their characteristics,
> i.e information not really part of the protocol.
> 
> How about:.
> 
>    The server is responsible for contructing an appropriate namespace.
>    Typically, it is contructed so that applications can choose an
> appropriate
>    level of support, so that in one position in  the namespace a varied set
>    of replicas might  be listed, while in another only those that are
> up-to-date
>    would be considered replicas.
> 
> 
> I'll think about doing that.

I'm not so much concerned about how the server constructs the namespace (as
the current practice leaves that entirely up to the server), but rather how
the client, or some human associated with the client, learns what the
server did.  That is, having a fancy namespace with extra semantics doesn't
do you any good if no one else knows what those semantics are :)
I was just hoping that this document could be more explicit about "this
protocol doesn't give you a way to communicate the extra semantics from
server to client, but you probably want to do it somehow".  I don't mind
giving more details about the types of semantics a server might encode in
the namespace as well, but that's not the direction I was trying to push
in.

-Ben

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4