Re: [nfsv4] feedback on draft-ietf-nfsv4-versioning-07
David Noveck <davenoveck@gmail.com> Mon, 31 October 2016 17:25 UTC
Return-Path: <davenoveck@gmail.com>
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 2BA3A129969 for <nfsv4@ietfa.amsl.com>; Mon, 31 Oct 2016 10:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FD_cUNhQ5mra for <nfsv4@ietfa.amsl.com>; Mon, 31 Oct 2016 10:25:41 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D45C129954 for <nfsv4@ietf.org>; Mon, 31 Oct 2016 10:25:41 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id v84so81229700oie.3 for <nfsv4@ietf.org>; Mon, 31 Oct 2016 10:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cikoamsXGBRQhksYkDrBiBLJNwG6YZ+EJFkgZqT5/u4=; b=r6WFo/cZCqagitpmxS/0CNQhjJmEAl+DZcDAHJtb0FiLoQ3D6WtBFEvshCLfeedpoN 7TEeuZxl12hwMVvsThk4H/UYM/sITSX6thQg55rsPbuGAT2d3fn6GllWmNLMHFxCHjDi /V18/lK+mu5ZrkOBUkzlffMv5io0V2UObnOJapDHt7KHq3dG1ZiAzNiowevn4fVyZ274 VYqjS7FHDANNup+b+iNmZowZYarBeR8URYWyLuJdsX0UL2A2q3skkFUq4sNGmK7ZeOVm ekJZHJh1URoyOyDzJM6cXxMLbJl3E2TT7RGH7u7iwDyTl3+bOnKIrHdQs/h4KWYsXHPx CqPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cikoamsXGBRQhksYkDrBiBLJNwG6YZ+EJFkgZqT5/u4=; b=hK4asKS6nnJg8JA1c8HxBlHWYGmg27RuVxbShIc8kWzWqWvfqCIInvUIjx27Tnsy4N fWX2DyDSYS67wWtSTc1/D4Zvv7gJSUmYJX/KO5xVA0ZNgiXWdTteKZ9MgYNZ0sIdRbUX 6D7jXzHfVj5vIElChWEjfz4cirjCouDNtthuJzdfrJotpM6GjPG49w++Th0bLbmpV21d NEMIr8NgXlQ9dKQdqoC2Hl5wH4Sk+7K2OFmr4RzRocDQUeoWORJMWnmg/Rrc314QI9TR sZ15d18+UxuJXM047nyJaFIXEpi7f4lyZwnzpa5KYIAAgYM9cH0JHu8Jrt2hjvURXNta bHPg==
X-Gm-Message-State: ABUngveMdkPgOKSs4m01Kg8KhwR9z/h5VbAyu9DLVQOsJZX3zEvBXBsrG5KfItjvdrFnxTU+vHW98xbjYQlFVw==
X-Received: by 10.157.20.197 with SMTP id r5mr9386443otr.198.1477934740586; Mon, 31 Oct 2016 10:25:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.29.3 with HTTP; Mon, 31 Oct 2016 10:25:39 -0700 (PDT)
In-Reply-To: <20161031020435.GC5869@fieldses.org>
References: <ote01sz4f8tk.fsf@athyra-vm1.us.oracle.com> <CADaq8jcSUO5rkf-4+njbk-O0Fv5gTedTRZnceVJRdz1T4zyH1Q@mail.gmail.com> <ote0oa2668pg.fsf@jurassic.us.oracle.com> <CADaq8jcOwbdc8O7am+tSdpa9hFDFfc5ULkM1qhOt9HPn7m-Ujw@mail.gmail.com> <ote0a8dp8xel.fsf@jurassic.us.oracle.com> <CADaq8jdfjLQz2YxLAROmLK5V5-BMjuHaABeic7mKmfZDtWBn=g@mail.gmail.com> <20161031020435.GC5869@fieldses.org>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 31 Oct 2016 13:25:39 -0400
Message-ID: <CADaq8jfdUr5Qc2xfWafqYFUAN2bh00d7Nch_SaJt_nHbEM3izA@mail.gmail.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Content-Type: multipart/alternative; boundary="001a1141a58036c68005402c7f26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-7J1WVuGbJU1kOzxAI-A8QOBJZE>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] feedback on draft-ietf-nfsv4-versioning-07
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Oct 2016 17:25:44 -0000
> So, that rules out adding attributes? No it doesn't. > (Since you'd have to return new bits in the supported_attribute attribute). I said adding "bit flags" and I think that means a new definition of a previously unknown flag bit. Each bit in the bit mask of supported attribute already has a definition and when I write the text, I'll make sure that it is clear that expanding supported_attrs is not going to change that For example bit 128 means the server supports attribute 128. The further information regarding what attribute that is would be provided by the extension that defines attribute 128, the effect of which is already clear. The point is that the client who does not know about attribute 128 is not going to puzzle over this new bit. He knows it indicates that the server supports some attribute he doesn't know about. On Sun, Oct 30, 2016 at 10:04 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Fri, Oct 28, 2016 at 08:29:26AM -0400, David Noveck wrote: > > l've looked at how bit flags are dealt with in -07 and believe that enum > > extensions can be dealt with similarly. > > They are both constructs where the generated XDR code does not check for > > validity and thus they raise similar issues. > > > > In reviewing the treatment, I have found few gap in the treatment of bit > > flags. Those need to be fixed and I expect that the handling of enum > > extensions will be parallel: > > > > - There is no discussion of adding bit flags in existing responses. > > Instead, it should be made explicit that doing this would require a > new > > minor version. > > So, that rules out adding attributes? (Since you'd have to return new > bits in the supported_attribute attribute). > > --b. > > > - There is no explicit discussion of the fact that, for these > additions, > > the interest cannot be distinguish between an unknown bit flag and one > > which is known but unsupported. This can have implication for how the > > client and server decide on a common XDR variant. I'd hope that this > issue > > can treated in a way that allows a future minor version to better > address > > the issue by reorganizing error codes. My preference would be for > > preservng NFS4ERR_INVAL as indicating an unknown bit/enum, while > allowing > > future versions to address unsupported stuff in a way analogous that > Tom > > did for switches in v4.2, i.e. by creating NFS4ERR_FLAGBIT_NOTSUPP and > > NFS4ERR_ENUMVAL_NOTSUPP. > > > > > > On Thu, Oct 27, 2016 at 2:22 PM, Mike Kupfer <mike.kupfer@oracle.com> > wrote: > > > > > David Noveck <davenoveck@gmail.com> writes: > > > > > > > Regarding extending enums, it is true that -07 seems to allow this > > > without > > > > saying how to mange it in general. It only discusses expanding > switches > > > > and provides specific rules regarding error codes, operation codes, > and > > > > attribute numbers. > > > > > > > > The real problem with allowing general enum extensions is that XDR > > > > implementations do not check that the values in the fields are valid. > > > As a > > > > result, you cannot test that the responder knows about the new > values by > > > > issuing a request containing the new value, as you can with > extensions to > > > > switches. > > > > > > Well, there won't be a check at the RPC layer. But presumably the NFS > > > layer would return something like NFS4ERR_INVAL if it's given a value > it > > > doesn't know about. > > > > > > > As a result, enum fields are essentially ints, and the restriction > to the > > > > values listed in the XDR file is much like an in-spec-text > restriction > > > > regarding the contents of that particular field. I think the spec > should > > > > make clear it that changing the set of allowed values requires a new > > > minor > > > > version. > > > > > > I'm okay with narrowing the scope of what an extension can do. But if > > > we require a minor version bump to change the set of allowed values for > > > an enum, we should do the same for the general case of flag words. > (New > > > attributes could still be added via an extension.) > > > > > > mike > > > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www.ietf.org/mailman/listinfo/nfsv4 > >
- [nfsv4] feedback on draft-ietf-nfsv4-versioning-07 Mike Kupfer
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… David Noveck
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… Mike Kupfer
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… David Noveck
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… J. Bruce Fields
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… Mike Kupfer
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… David Noveck
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… Mike Kupfer
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… J. Bruce Fields
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… David Noveck
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… Trond Myklebust
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… Fields Bruce James
- Re: [nfsv4] feedback on draft-ietf-nfsv4-versioni… David Noveck