IETF Logo Mail Archive

Re: [nfsv4] draft-haynes-nfsv4-versioning-01

"J. Bruce Fields" <bfields@fieldses.org> Thu, 23 October 2014 17:44 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11351A90DF for <nfsv4@ietfa.amsl.com>; Thu, 23 Oct 2014 10:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jL1eIRsZTrZS for <nfsv4@ietfa.amsl.com>; Thu, 23 Oct 2014 10:44:18 -0700 (PDT)
Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732821A9308 for <nfsv4@ietf.org>; Thu, 23 Oct 2014 10:44:16 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from <bfields@fieldses.org>) id 1XhMQn-0005pn-BM; Thu, 23 Oct 2014 13:44:13 -0400
Date: Thu, 23 Oct 2014 13:44:12 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Benny Halevy <bhalevy@primarydata.com>
Message-ID: <20141023174412.GA22339@fieldses.org>
References: <896EE07C-552B-412C-B30E-85A223AAA6B2@primarydata.com> <CAEMWVhsYYTxbw44C+oOmyWTCiMbCf_yOebTBWv0z2W6YHrChSg@mail.gmail.com> <20141023152924.GB16717@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20141023152924.GB16717@fieldses.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/KuQTIKAYyDKql4qOrhlZk0yMeAU
Cc: NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] draft-haynes-nfsv4-versioning-01
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Oct 2014 17:44:20 -0000

On Thu, Oct 23, 2014 at 11:29:24AM -0400, bfields wrote:
> On Thu, Oct 23, 2014 at 09:18:26AM +0300, Benny Halevy wrote:
> > On Thu, Oct 23, 2014 at 7:08 AM, Tom Haynes
> > <thomas.haynes@primarydata.com> wrote:
> > >
> > > So this looks good to go with only two open items for me:
> > >
> > > 1) Are new operations assigned by IANA or by publishing a draft?
> > >
> > > Actually Christoph’s observation, but there seems to be controversy here. :-)
> > >
> > > 2) With respect to callbacks:
> > >
> > >    o  New callbacks will only be sent to clients that have used the new
> > >       features associated with them, allowing existing clients to be
> > >       unaware of their existence.
> > >
> > > What if the new feature is only implemented with callbacks?
> > >
> > > I.e., clients have to be able to respond with not supported as well.
> > 
> > Why wouldn't they be able to respond with "not supported"?
> > Even today some callbacks are (feature) optional, e.g. CB_NOTIFY_DEVICEID
> 
> If they implemented only part of a minor version then they may not even
> know the callback number is assigned in which case they'll return
> NFS4ERR_OP_ILLEGAL.

(And the draft already discusses that case.  OK, I should read it.
Sorry!)

--b.

v2.23.0 | Report a Bug | By Email