IETF Logo Mail Archive

Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types

Thomas Haynes <loghyr@primarydata.com> Wed, 16 August 2017 18:11 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 6B04213267B for <nfsv4@ietfa.amsl.com>; Wed, 16 Aug 2017 11:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 o-lGj8e7WE2n for <nfsv4@ietfa.amsl.com>; Wed, 16 Aug 2017 11:11:53 -0700 (PDT)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [216.205.24.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 E077913239A for <nfsv4@ietf.org>; Wed, 16 Aug 2017 11:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1502907111; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=cJmMK4hPEB03v15aadckPemy+ICnMS6sdl7culuF6Fg=; b=ADEFbql4IDTGP2ZeU/RHzLN1D4X2NTC0yjYo+QyoZr33an/mubrVYXr5NK5lgU0RpUskw9iGjty1muFMdCMxrqtOxzegq4axc1OVm3AknbSarNseLxOtH+CQC7cUQ/8GAuTxefB00uDnVBAbz4REsDJAUwB0jkhII2MHxb/YtWQ=
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-17-eZX-AKWcPU6jJFntEujBng-1; Wed, 16 Aug 2017 14:11:50 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1094.namprd11.prod.outlook.com (10.164.166.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.21; Wed, 16 Aug 2017 18:11:48 +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.023; Wed, 16 Aug 2017 18:11:48 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: hch <hch@lst.de>
CC: Chuck Lever <chuck.lever@oracle.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types
Thread-Index: AQHTDHrZiISsN7s3MU64UU3+W1eRPaKGxHEAgACUqACAAAQwgA==
Date: Wed, 16 Aug 2017 18:11:48 +0000
Message-ID: <7825AA72-F3AA-4792-9CF9-F8D0C9AB6176@primarydata.com>
References: <418E308E-5057-499A-B403-38486BDEF772@oracle.com> <20170816090444.GA21357@lst.de> <122CB9C5-9B8C-4310-A05B-D680C3E4CA5B@primarydata.com>
In-Reply-To: <122CB9C5-9B8C-4310-A05B-D680C3E4CA5B@primarydata.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; BY2PR1101MB1094; 20:t2YHcUSRCnvmvSf5uiQx2TLof/bdOKrQqb+yLyZ4mrGNXSt5ruXkRM8SWxjFG83LCkmWk+qGRu6LYM9jgJsLU49K65rt01lqB5Qt1fKOHs30rJmpF+H/289Y8I6boNIs5NicuOtJfAA++hA/SHBWl96x1Rbub+1QMIZrQRFvgfg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ld-processed: 03193ed6-8726-4bb3-a832-18ab0d28adb7,ExtAddr
x-ms-office365-filtering-correlation-id: bd9ef9ea-687f-434b-e23d-08d4e4d242f4
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:BY2PR1101MB1094;
x-ms-traffictypediagnostic: BY2PR1101MB1094:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: <BY2PR1101MB10947E8DC2C51411B46A1743CE820@BY2PR1101MB1094.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)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(2016111802025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1094; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1094;
x-forefront-prvs: 0401647B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(189002)(24454002)(199003)(377454003)(82746002)(6512007)(99286003)(53936002)(2950100002)(6916009)(189998001)(53546010)(6246003)(77096006)(6486002)(110136004)(33656002)(3280700002)(25786009)(102836003)(3846002)(6116002)(83716003)(54906002)(5660300001)(6506006)(6436002)(2906002)(97736004)(101416001)(478600001)(3660700001)(8936002)(66066001)(86362001)(36756003)(68736007)(81166006)(76176999)(50986999)(81156014)(2900100001)(229853002)(54356999)(305945005)(14454004)(105586002)(106356001)(7736002)(8676002)(4326008)(230783001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1094; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <D6548B154A25A140BD55EBE622A016FC@namprd11.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 18:11:48.1661 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1094
X-MC-Unique: eZX-AKWcPU6jJFntEujBng-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/RVlc5f4vE7YBWGn0qJSdjIh0494>
Subject: Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types
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: Wed, 16 Aug 2017 18:11:55 -0000

> On Aug 16, 2017, at 10:56 AM, Thomas Haynes <loghyr@primarydata.com> wrote:
> 
> 
>> On Aug 16, 2017, at 2:04 AM, Christoph Hellwig <hch@lst.de> wrote:
>> 
>> The first thing I noticed is that section 3 claims:
>> 
>> "There have been no published specifications for control protocols as yet."
>> 
>> which I don't think is true any more.  The SCSI layout fully specifies
>> the interaction between the MDS and the storage device, so it should
>> be considered to include a control protocol.
> 
> RFC8154 doesn’t quite say that:
> 
>   The Server to Storage System protocol, called the "Control Protocol",
>   is not of concern for interoperability, although it will typically be
>   the same SCSI-based storage protocol.
> 
> I read that to say that it is possible for someone to implement the SCSI
> layout without using the SCSI-based storage protocol. 
> 


Okay, off of my high horse.

I had already removed the claim above and I have just added a new
paragraph in Section 3.0:

   An example of this last case is the SCSI layout type [RFC8154], which
   extends the block layout type.  The block layout type had a
   requirement for fencing of clients, but did not present a way for the
   control protocol (in this case the SCSI storage protocol) to fence
   the client.  The SCSI layout type remedies that in [RFC8154] and in
   effect has a tightly coupled model.

I think this addresses your point.

v2.23.0 | Report a Bug | By Email