Re: [nfsv4] Proposed Working Group Charter
David Noveck <davenoveck@gmail.com> Tue, 29 August 2017 19:50 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 F1F94132397; Tue, 29 Aug 2017 12:50:26 -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 tSuidujyEjRU; Tue, 29 Aug 2017 12:50:24 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 0C0B51321B0; Tue, 29 Aug 2017 12:50:24 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id d81so25000150ioj.4; Tue, 29 Aug 2017 12:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pfcRWdqWgwxFeqp8qlSoK4byje5hl5P+VVw/Vt9D2As=; b=I8Fh6vAmzNeSvBLFM+pg/A9qfZ/cSKM7rwVRePoPUaCG447wq+J9GNXziD6V6xJNYt saCEn3gZyAmedFnlW6/oDy0yeozjG1PxB6O6JrofZPwyU/3/aty1VpvDHqtQwSfJSfly pkpewJMZ6o7db9jIPtKgNzMyPdD2zDBBOZdnw2lCzdOyh/x1+fVL8s4wMGTyYbxIYRQv yAAZhxEwOVBdrrwthgfpNL2NUGq5Ebx9bxjK2nrZ4j3NpVJqs8zxWC3vV35KM0UUagNw EHsbiqOdAL/D5t8olNivF0vbCbbW4jnZxsscCYZ8XB24zdT+P53ZePU3cUTyoUnPy6xE O/aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pfcRWdqWgwxFeqp8qlSoK4byje5hl5P+VVw/Vt9D2As=; b=sEVnDnR35SoNuecgeZUPUb9IS1BCw2rkdseDy7E+l4sxnxIXzy/Xrxc363l9c8vr2X c7wNBhgX2AP2dHTy66c046g+oXWeOeJEMsdvrXndCcdDMqAi51V1LW8x1WpOUDTTXT43 pJRfkWb2rsEfpSNedeSToJ+A32sYmXj9zjg4l2dWNbBXf696FBT10s4kCjHaXeRGN4Fj nPGAM7HoLB7lDq9vXw51Qg0mGPj07zqZwms9s2KR65MYSdiy5woETc1YDB6ynGGDgFxc g87MXj8tlVFGgBTKXJlljtgguSOvD0Ql5q0DQaldDtVtCEqq9LuBGwuK+0ovdofOlElk POmA==
X-Gm-Message-State: AHYfb5io6WqyeEHk1+fKM6PUlKujyeVhyBco32+KW6yT5GZO9sRQc5hQ zL660FlsmkvuVjbu3gyhIuLLx/+jqA==
X-Received: by 10.107.26.203 with SMTP id a194mr5266996ioa.98.1504036223201; Tue, 29 Aug 2017 12:50:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.213 with HTTP; Tue, 29 Aug 2017 12:50:22 -0700 (PDT)
In-Reply-To: <CAFt6BamKDMWfw_-vR0hL1S2ExOP0WK3eADQjAedQLisdkmcmvA@mail.gmail.com>
References: <CADaq8jdNRenxK0yfXC9xpmCidfzuetcrC=dhkK7w2TnehZ6X4g@mail.gmail.com> <CAFt6Ba=qLqJGN2XCy_RE9sMMkU1-TjommK9Zhz7Y6Pvo2+E4hQ@mail.gmail.com> <CAKKJt-eqoPnkUcXLnB+=13S1iDcxkp8jXaDcG6a2kWeiQ9pVug@mail.gmail.com> <CADaq8jeWSUPj6mO9ixvLcacaOJR1X3V+X=ng3Cv2wzHb_d-Niw@mail.gmail.com> <CAKKJt-c+1==KWqL1T8jZaVT1LBL7OvfV2gf3Lq-pY+aXF5xg=A@mail.gmail.com> <CADaq8jd8KtOwKz_T6zNLsbJGR3mL4ySqcytkLodRsrU9zUd4HA@mail.gmail.com> <CAFt6BamSyegRE-DykHUQgXwciQ8CvFr6hRcEb2cW-d-i_2hjwQ@mail.gmail.com> <CAKKJt-eeRRHrLJBnqzKHhjCCL0qpPg3Ep23kSdhi7tEjffCH_w@mail.gmail.com> <CAFt6BamKDMWfw_-vR0hL1S2ExOP0WK3eADQjAedQLisdkmcmvA@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 29 Aug 2017 15:50:22 -0400
Message-ID: <CADaq8jc13DtzPm6GPLpivMzqmp+3eSqa03-Z2nHjzWi5LwTJVg@mail.gmail.com>
To: spencer shepler <spencer.shepler@gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, nfsv4-ads@ietf.org, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fd448d038cd0557e9b862"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/AnVrztIG3_vfYF3NCRWCIqMo5VE>
Subject: Re: [nfsv4] Proposed Working Group Charter
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 29 Aug 2017 19:50:27 -0000
Lokks fine to me as well. On Tue, Aug 29, 2017 at 2:37 PM, spencer shepler <spencer.shepler@gmail.com> wrote: > > Reviewed and this looks good to me, Spencer D. > > Spencer S. > > > On Tue, Aug 29, 2017 at 11:12 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Dear NFSv4 Chairs and working group participants, >> >> >> This is what I've got in the datatracker as version 05-00 of the charter. >> >> It is intended to be what David proposed in this thread, with some >> abbreviation expansions and paraphrasing. I did leave the part about adding >> milestones for deliverables within charter, and we'll see if other ADs >> think that should change. >> >> Please let me know how this looks, and I'll start Internal Review. >> >> Thanks, >> >> Spencer >> >> Network File System version 4 (NFSv4) is the IETF standard for file >> sharing. >> >> To maintain NFS Version 4's utility and currency, the NFSv4 working group >> is >> chartered to maintain the existing NFSv4.0, NFSv4.1, and NFSv4.2 protocols >> and specifications of related ONC components, such as those defining RPC, >> XDR, and RPCSECGSS. >> >> In addition, extensions will be developed, as necessary, to correct >> problems >> with the protocols as currently specified, to accommodate needed file >> system >> semantics, and to respond to technological developments in the areas of >> networking and persistent storage/memory. >> >> Maintenance >> >> The working group's experience has been that, as NFSv4 implementations >> mature >> and deployments continue, clarifications and corrections to existing RFCs >> are needed. >> >> These specification updates help vendors in delivering high-quality and >> interoperable implementations. >> >> The NFSv4 working group is chartered with vetting reported issues and >> determining correctness of submitted errata. >> >> The working group is also responsible for approving changes to RPC- and >> NFS-related IANA registries. >> >> In addition, some areas may need more concentrated work to correct the >> specifications already published, to deal with unanticipated interactions >> between features, or to respond to evolving IESG expectations with regard >> to areas such as security. Since necessary changes in such cases are >> generally not appropriate for the errata system, the working group will >> assist in publication of new RFCs that provide implementation guidance, >> editorial modification or technical updates to existing RFCs. >> >> Since the new NFSv4 versioning framework has been approved, these >> technical >> updates to NFSv4 minor versions could include limited XDR changes. >> >> Extensions >> >> The NFSv4 protocol is designed to allow extension by the definition of >> new operations, new attributes, and new Parallel NFS layout types, as >> well as >> the creation of minor versions. >> >> Similarly, associated ONC protocol components that have a versioning/ >> extension framework can be incrementally extended, when necessary. >> >> The working group will discuss proposals for such extensions and assure >> that they have adequate technical review, including discussion of their >> interaction with existing features, before adopting them as working group >> items and helping to draft specification documents. >> >> Some likely motivations for such extensions would be to: >> >> Maximize NFS performance on advanced network fabrics. >> >> Accommodate new storage technologies. >> >> Provide facilities useful in management of NFS-accessed storage in >> large-scale virtualization environments. >> >> Provide more effective NFS response to security challenges. >> >> New milestones that fall within the scope specified in this charter can >> be added to the list below after working group consensus and upon >> approval by the responsible Area Director. >> >> Proposed Milestones >> >> ======================================================================== >> | Date | Milestone | >> |---------+------------------------------------------------------------| >> | 3/2018 | WGLC for description of use of NVMe in accessing a pNFS | >> | | SCSI Layout | >> | 6/2018 | WGLC for draft-ietf-nfsv4-migration-issues (Informational) | >> | 8/2018 | WGLC for document describing NFSv4.0 trunking discovery | >> | 10/2018 | WGLC for document describing NFSv4.1 trunking discovery | >> | 10/2018 | WGLC for document describing Transparent State Migration | >> | | in NFSv4.1 | >> | 1Q2019 | WGLC for description of CM private data convention | >> | | (Informational) | >> | 1Q2019 | WGLC for pNFS RDMA Layout | >> | 3Q2019 | WGLC for RPC-over-RDMA Version 2 | >> ======================================================================== >> > >
- [nfsv4] Proposed Working Group Charter David Noveck
- Re: [nfsv4] Proposed Working Group Charter spencer shepler
- Re: [nfsv4] Proposed Working Group Charter Spencer Dawkins at IETF
- Re: [nfsv4] Proposed Working Group Charter David Noveck
- Re: [nfsv4] Proposed Working Group Charter Spencer Dawkins at IETF
- Re: [nfsv4] Proposed Working Group Charter David Noveck
- Re: [nfsv4] Proposed Working Group Charter spencer shepler
- Re: [nfsv4] Proposed Working Group Charter Spencer Dawkins at IETF
- Re: [nfsv4] Proposed Working Group Charter spencer shepler
- Re: [nfsv4] Proposed Working Group Charter David Noveck
- Re: [nfsv4] Proposed Working Group Charter Black, David