Re: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-13.txt

Thomas Haynes <loghyr@primarydata.com> Tue, 15 August 2017 21:44 UTC

Return-Path: <loghyr@primarydata.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 4653113240B for <nfsv4@ietfa.amsl.com>; Tue, 15 Aug 2017 14:44:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.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 heM83rcZFLDN for <nfsv4@ietfa.amsl.com>; Tue, 15 Aug 2017 14:44:33 -0700 (PDT)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [63.128.21.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C7613219E for <nfsv4@ietf.org>; Tue, 15 Aug 2017 14:44:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1502833471; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=NrKuQEOOfqt197aK7JfUc0jfAQcPeU+L/vfH0fv2p28=; b=JzXvzAh+UyvTUtFe/q3aitnvlwOZ2crFlpabXciuBWpQPXSlLIcD9uy+kvBs6EisngoFmuvdQIjiIMvC5PVniYvJDjkQLD3v0LYGEIW8pTyuKTzsTICrxaih0FytyExIweuYhsSs3hHKRB7df7hlzC1R7K40Ip/QZl/baEMzwd0=
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0085.outbound.protection.outlook.com [207.46.163.85]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-166-9B_hRWSFNsSNnQgbArwLyg-1; Tue, 15 Aug 2017 17:44:29 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1096.namprd11.prod.outlook.com (10.164.166.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.21; Tue, 15 Aug 2017 21:44:25 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.01.1341.020; Tue, 15 Aug 2017 21:44:25 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Dave Noveck <davenoveck@gmail.com>
CC: Spencer Shepler <spencer.shepler@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-13.txt
Thread-Index: AQHTD9D0BrU7fFXJW0yjXv1DRi/8k6J5lYoAgACpqQCAAIkAgIAKg5EAgABZVoCAACFgAIAAOTYA
Date: Tue, 15 Aug 2017 21:44:25 +0000
Message-ID: <C9EF1F87-F62C-4049-8710-D8B9577A9B44@primarydata.com>
References: <150214681284.12459.7958419961024288184@ietfa.amsl.com> <01E22DE7-123E-4765-908E-AF79FD8E4C5E@primarydata.com> <CADaq8jfVy-9LHPxJz818bLKwg0HSmpGLcR2dEsLkidEHZUShuw@mail.gmail.com> <CAFt6Ba=zox9Cyu--WwGtLpF2MQOEjJppaQvjrL+qsTZv918jig@mail.gmail.com> <CADaq8jdZ28Wr+FV4MYMgO8T17mtxnypZFk+H+PoMom_nFNiHMQ@mail.gmail.com> <11E1F753-1A14-439A-BE4F-25FF044BA35B@primarydata.com> <CADaq8je8yiZ_mx6UADhy65h_fXXsUH==VEj6+fGYuKN7r_g91A@mail.gmail.com>
In-Reply-To: <CADaq8je8yiZ_mx6UADhy65h_fXXsUH==VEj6+fGYuKN7r_g91A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1096; 20:0rngxQDdN8KTgeeKULoGVUSgMwwZAlMvbqqCmIo51XhiZcwSgZXOHKaVEQgW6zmGQi1Racr4zidSGx8ly6wocYE0Fia2RSbDAx45fAtIacNI0eXauP+W/eIGKxTVifH6PqdK1bY0Wq73hd7cnacyh6C+vOXZScc5+eXGVPggI00=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b18c65c4-a24d-4824-01b5-08d4e426cc81
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1096;
x-ms-traffictypediagnostic: BY2PR1101MB1096:
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705);
x-microsoft-antispam-prvs: <BY2PR1101MB1096F5CA6CCBE06597B3647BCE8D0@BY2PR1101MB1096.namprd11.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(2016111802025)(20161123564025)(20161123560025)(20161123562025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1096; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1096;
x-forefront-prvs: 04004D94E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(199003)(377424004)(60444003)(189002)(51914003)(377454003)(24454002)(5660300001)(230783001)(14454004)(3660700001)(53546010)(66066001)(105586002)(93886004)(106356001)(6246003)(33656002)(6916009)(966005)(2950100002)(6486002)(2906002)(77096006)(110136004)(97736004)(229853002)(68736007)(36756003)(3280700002)(81166006)(39060400002)(6436002)(8936002)(6506006)(189998001)(83716003)(478600001)(606006)(86362001)(1411001)(7736002)(50986999)(82746002)(81156014)(6512007)(54896002)(6306002)(53936002)(25786009)(4326008)(236005)(99286003)(6116002)(3846002)(76176999)(102836003)(54356999)(2900100001)(101416001)(8676002)(54906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1096; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 21:44:25.4791 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1096
X-MC-Unique: 9B_hRWSFNsSNnQgbArwLyg-1
Content-Type: multipart/alternative; boundary="_000_C9EF1F87F62C40498710D8B9577A9B44primarydatacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/2CLU1iaa_wrQVHpJkQftF0OHYs4>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-13.txt
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, 15 Aug 2017 21:44:36 -0000

On Aug 15, 2017, at 11:19 AM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:

> Wait, I would have held off shipping a v-13 if I had known it reset the last call.

It didn't reset anything.  However, last call ended on 8/11 and now we all have to figure  out what to do about this document.

> I sent out v-13 as a courtesy to the reviewers

OK, thanks.  But I'm really unclear what you want the reviewers to do with it.

There seems to be no point in continung with the review of -12 as if nothing has happened.  My assumption was that you decided to go with a new approach to security in -13 and wanted the review to proceed on that basis, as Spencer indicated should happen given that -13 substantially changed what was in -12.

If that isn't right, it would be best if you supply a -14 that has the document that you would like to get reviewed as the basis for WGLC and if not tell the working group that the document is now no longer ready for WGLC review.




The changes in v13 were in response to the WGLC, including the ones to the security. And
while the churn to the document was substantial, the effective changes to the protocol
were not that substantial.

I do not want to see what would effectively be an open ended WGLC that gets reset
every time a review is made. That sets a precedent I do not want to endorse.









On Tue, Aug 15, 2017 at 12:20 PM, Thomas Haynes <loghyr@primarydata.com<mailto:loghyr@primarydata.com>> wrote:

On Aug 15, 2017, at 4:00 AM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:

There is a need to adress the issue of a last call for flex-files-13.

I previously suggested extending the -12 LC to encompass the -13 and ending on 8/21, but Spencer on 8/8 responded:.

> Thanks for the suggestion, Dave.  However, we will let the timer run on the current last call (ends on Friday).

> Once that is complete, we will start another last call on the version of the I-D that is available then.

Since that last call ended on 8/11, the version available now is -13.so we have to start that new last call.


Wait, I would have held off shipping a v-13 if I had known it reset the last call.

I sent out v-13 as a courtesy to the reviewers.




> Note that this is always the case - if there has been enough change during a last call to warrant another round, then we do another last call.  Not a big deal.

I think it is pretty clear that there has been enough change.  If there is anyone who disagrees, please speak up..

The only remaIning issue is the the end date.  I previously proposed a two-week last call period to enable me to do
a comprehensive review.  Others might want to focus on the security changes in -13 but I skipped a comprehensive
review of -12 because it was always pretty clear there would have to be a -13.

Two weeks from today would be 8/29.  However, it may be simpler to make the end date the following Fridiay, which is 9/1.
Is Tom and the rest of the working group OK with that end date for the -13 WGLC?



On Tue, Aug 8, 2017 at 2:26 PM, spencer shepler <spencer.shepler@gmail.com<mailto:spencer.shepler@gmail.com>> wrote:


Thanks for the suggestion, Dave.  However, we will let the timer run on the current last call (ends on Friday).

Once that is complete, we will start another last call on the version of the I-D that is available then.

Note that this is always the case - if there has been enough change during a last call to warrant another round, then we do another last call.  Not a big deal.

Spencer

On Tue, Aug 8, 2017 at 3:16 AM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:
I can't see reviewing this by 8/11.  I think we will need to reset the WGLC clock.

I thibk it should be extended  to 8/21 to give us two weeks to review the new draft.  Other opinions?

In any case, Spencer S should announce a new date, so everybody is in sync.

On Mon, Aug 7, 2017 at 8:09 PM, Thomas Haynes <loghyr@primarydata.com<mailto:loghyr@primarydata.com>> wrote:
This is a result of the earlier reviews in the WGLC and a desire for an update by said reviewers.

> On Aug 7, 2017, at 4:00 PM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network File System Version 4 WG of the IETF.
>
>        Title           : Parallel NFS (pNFS) Flexible File Layout
>        Authors         : Benny Halevy
>                          Thomas Haynes
>       Filename        : draft-ietf-nfsv4-flex-files-13.txt
>       Pages           : 40
>       Date            : 2017-08-07
>
> Abstract:
>   The Parallel Network File System (pNFS) allows a separation between
>   the metadata (onto a metadata server) and data (onto a storage
>   device) for a file.  The flexible file layout type is defined in this
>   document as an extension to pNFS which allows the use of storage
>   devices in a fashion such that they require only a quite limited
>   degree of interaction with the metadata server, using already
>   existing protocols.  Client side mirroring is also added to provide
>   replication of files.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-13
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-flex-files-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-flex-files-13
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>g/>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org<mailto:nfsv4@ietf.org>
> https://www.ietf.org/mailman/listinfo/nfsv4
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org<mailto:nfsv4@ietf.org>
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org<mailto:nfsv4@ietf.org>
https://www.ietf.org/mailman/listinfo/nfsv4