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

Benjamin Kaduk <kaduk@mit.edu> Mon, 13 January 2020 18:27 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFCB1209E1; Mon, 13 Jan 2020 10:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmspw6Zs9d6p; Mon, 13 Jan 2020 10:27:24 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBBC120946; Mon, 13 Jan 2020 10:27:23 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DIRGlG010915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 13:27:19 -0500
Date: Mon, 13 Jan 2020 10:27:16 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: David Noveck <davenoveck@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, nfsv4-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20200113182716.GH66991@kduck.mit.edu>
References: <157665795217.30033.16985899397047966102.idtracker@ietfa.amsl.com> <CADaq8jegizL79V4yJf8=itMVUYDuHf=-pZgZEh-yqdT30ZdJ5w@mail.gmail.com> <20191223021435.GW35479@kduck.mit.edu> <CADaq8jetpqMbKgVj6xTHYqkeJZXL3WZsVgrRdooYhaK0S8uTVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jetpqMbKgVj6xTHYqkeJZXL3WZsVgrRdooYhaK0S8uTVA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/LqTz3uhD9_4qJfE0ivjZcezthhM>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 18:27:26 -0000

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 <kaduk@mit.edu> 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