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

[David Noveck <[e-mail]>]

On Mon, Jan 13, 2020 at 1:27 PM Benjamin Kaduk <[e-mail]> wrote:

> 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 <[e-mail]> 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.
>

OK.  I think I can address your concerns but it needs to be pointed out
that
in many cases of the  "extra" semanntics we are talking about, the semantics
are clear.  This is true of trunking, referrals and migration.   In the
case of
"replication", we do have a lot of existing uncertainty and I will try to
put in the
kind of text you suggest.

This and related issues have been mentioned in a number of sub-threads and
I intend to
consolidate text addressing  them here.   I'm going to propose that we
address all
these issues by some additions to Section 11.5.4.  Specfically I propose
revsing the
the second paragrapgh and adding a new tthird pragraph so that the last two
paragraphs
read as follows;

   In the event that the occurrence of server failures, communications
   problems, or other difficulties make continued access to the current
   file system impossible or otherwise impractical, the client can use
   the alternate locations as a way to get continued access to its data.

   The alternate locations may be physical replicas of the (typically
   read-only) file system data supplemneted by possible asynchronous
   propagation of updates.  Alternatively, they may provide for the use
   of various forms of server clustering in which multiple servers
   provide alternate ways of accessing the same physical file system.
   How the difference between replicas affects file system transitions
   can be represented within the fs_locations and fs_locations_info
   attributes and how the client deals with file system transition
   issues will be discussed in detail in later sections.

   Although the location attributes provide some information about the
   nature of the inter-replica transition, many aspects of the semantics
   of posible asynchronous updates are not currently described by the
   protocol, making it necessary that clients using replication to
   switch among replicas undergoing change familiarize themselves with
   the semantics of the update approach used.  Because of this lack of
   specificity, many applications may find use of migration more
   appropiate, since, in that case, the server, when effecting the
   transition, has established a point in time such that all updates
   made before that can propagated to the new replica as part of the
   migration event.


-Ben
>