Re: [nfsv4] draft haynes-nfsv4-versioning: Issues relating to opcode assignments etc.
Benny Halevy <bhalevy@primarydata.com> Sun, 02 November 2014 15:07 UTC
Return-Path: <bhalevy@primarydata.com>
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 5CD2B1A8A63 for <nfsv4@ietfa.amsl.com>; Sun, 2 Nov 2014 07:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 JZbr2URWdoOA for <nfsv4@ietfa.amsl.com>; Sun, 2 Nov 2014 07:07:02 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950811A891D for <nfsv4@ietf.org>; Sun, 2 Nov 2014 07:07:02 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id x12so7251809qac.21 for <nfsv4@ietf.org>; Sun, 02 Nov 2014 07:07:01 -0800 (PST)
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:content-type; bh=mFbdBtbV6AMlwPX4HcSFKFDgMg4rHfjWPdWSgmGtwOI=; b=Z9ty4a5zkKJeuH1xBLeUH+T7c9cIDyKRU7QSkRoqSJm3BM1M28CEOcUR48tgAV2gdZ 25Q+FNSDFLIaqoluthfKOvJsoMAMORsJi0FUr7tnUNrsabxHtN49BGIfPtS6kRkGw5gn ROnmvyjfC0RIWL0wKyMOnvHNaH0YuH4EpWO2afgU5aNzZfynlwdPzniYHiyrgrHCim2s AovO0eRfZROjYTL8Tsym9LepUD4QTaYETcaNZkhobNUAF7RT3EiSa2yz5aji9r0OwluZ t9T7tCAeEq4ae5GPuxFLZ/DcCkzUKSwaE+M8xyaU5zAsOZr28C6bRGUmQORpdjrmew3w hC9Q==
X-Gm-Message-State: ALoCoQnafePW77YlMjKGmH2fI0IFWywGaU8RAvNilxO4OygEKZUqOl4XAh4EG8ggvfofkySTafKJ
X-Received: by 10.229.188.1 with SMTP id cy1mr38890595qcb.29.1414940821769; Sun, 02 Nov 2014 07:07:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.75.232 with HTTP; Sun, 2 Nov 2014 07:06:41 -0800 (PST)
In-Reply-To: <CADaq8je8GyUO2AbaWRshQ+dEagnEKFddYswJKUyUc9Q_pVjkkQ@mail.gmail.com>
References: <CADaq8jcGEHYG8Y9+Lj6GBPhePC6vknPXaW9Yh+tbTJ4+bVxvJg@mail.gmail.com> <20141028160114.GC17213@localhost> <CADaq8je8GyUO2AbaWRshQ+dEagnEKFddYswJKUyUc9Q_pVjkkQ@mail.gmail.com>
From: Benny Halevy <bhalevy@primarydata.com>
Date: Sun, 02 Nov 2014 17:06:41 +0200
Message-ID: <CAEMWVhsXDU8ACBEuPnGfFF_NLB56Sq-hiFJaq=XxUZqxQoaqmw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: multipart/alternative; boundary="001a11346d1e0f6d2e0506e195e5"
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/NAYy3t6oPrXTTUzQwQV4RVauV7U
Cc: Nico Williams <nico@cryptonector.com>, Christoph Hellwig <hch@lst.de>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] draft haynes-nfsv4-versioning: Issues relating to opcode assignments etc.
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: Sun, 02 Nov 2014 15:07:04 -0000
David, I generally agree with your approach. One way we can facilitate the provisional allocation process without reverting to energy-draining processes is maintaining an informational RFC summarizing provisional / experimental allocations of Operation numbers, attribute identifiers, enum values, etc as a guide to anyone that wishes to extend the protocol. When a draft is accepted as a Working Group item this could be noted there and eventually when it becomes an RFC the assignments can be made permanent in the sense that they might get obsoleted in the future and specified as not to be used, but never reused for other purposes. Benny
- [nfsv4] draft haynes-nfsv4-versioning: Issues rel… David Noveck
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… Nico Williams
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… David Noveck
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… Nico Williams
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… Benny Halevy
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… David Noveck
- Re: [nfsv4] draft haynes-nfsv4-versioning: Issues… Benny Halevy