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                           |
>> ========================================================================
>>
>
>