IETF Logo Mail Archive

Re: [nfsv4] Opsdir last call review of draft-ietf-nfsv4-flex-files-15

Thomas Haynes <loghyr@primarydata.com> Thu, 04 January 2018 21:48 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 2A53F126E01 for <nfsv4@ietfa.amsl.com>; Thu, 4 Jan 2018 13:48:24 -0800 (PST)
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 fBlyI2zEdTm4 for <nfsv4@ietfa.amsl.com>; Thu, 4 Jan 2018 13:48:21 -0800 (PST)
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 64B22126B6E for <nfsv4@ietf.org>; Thu, 4 Jan 2018 13:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1515102499; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=OTl3PLjweqkTq/mVDwGmshhNILd+PCgUEi4RZNixxvI=; b=XqnwjaJXPJhubP9UMwlHHX6sWqjZQBQWM5E0VJXxvDkI8Iu6fWQaXtJSyDmWEMEUTNw8GdqMMLcRE8RERpxJN9egpNnlrjre9JN5NXA+RzOHfTZs3LjOi1BJUlMvlzmotr+D86SabboZX8JSeoSfQzhpVFWSPD3qtfTEHjxzXq0=
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0180.outbound.protection.outlook.com [216.32.181.180]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-101-_k7LXjCaM4a9zIHE1K4mbQ-1; Thu, 04 Jan 2018 16:48:16 -0500
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.20.366.8; Thu, 4 Jan 2018 21:48:13 +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.20.0366.009; Thu, 4 Jan 2018 21:48:12 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Linda Dunbar <ldunbar@huawei.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-nfsv4-flex-files.all@ietf.org" <draft-ietf-nfsv4-flex-files.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Opsdir last call review of draft-ietf-nfsv4-flex-files-15
Thread-Index: AQHThYzWnhovRR0XAk6Yf4msZZkwTKNkQFSA
Date: Thu, 04 Jan 2018 21:48:12 +0000
Message-ID: <E8076B58-C176-4684-B6A4-19F6091DF339@primarydata.com>
References: <151509179800.23726.16296513657477216313@ietfa.amsl.com>
In-Reply-To: <151509179800.23726.16296513657477216313@ietfa.amsl.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; 7:8yT4hy/BBBK0XNQMor7qt0BYFFEjXw7i2MoSPpVh0eeQck31tXuSpFxsTfPrHqMeg1ZuU68hUn4X/4l1EIYtLPh/Nlcuw/n6aE3pEj93yEU6YW5wxmt79oG0KDjt7eOIaxjmXziDRGxwwdxkEBMPXhf2H9hJe9XP9e6iE26Djwu6WxwkeUGTtirkq2x87RdgLJbKsR9vjwAQm4PKUFF37NkKePnI0SNPc+I+GLSLnJkE5zvdM99EuxcW5swtQi7r; 20:fOOkAdHEElbmmo8VQHrkz5SAir8OH2vC71qNcqusyWvYL4TlS6yRD2jk6DpCuU3f+2tq07yLVjM2dUSFcqAFagxkIToWjN4uNkJ6zQK+vjuYBFrmcCcY2s6/992UPhZZ1E04BQt4J9zSEa0rtLJHxivbi/IgdaYn/YBWL30ILSI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 1dc813ba-dd8f-4037-34e0-08d553bcda91
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:BY2PR1101MB1096;
x-ms-traffictypediagnostic: BY2PR1101MB1096:
x-microsoft-antispam-prvs: <BY2PR1101MB1096D3B69A2DE61305209E03CE1F0@BY2PR1101MB1096.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:BY2PR1101MB1096; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR1101MB1096;
x-forefront-prvs: 054231DC40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(366004)(346002)(39830400003)(24454002)(199004)(189003)(51914003)(54906003)(3846002)(2906002)(8676002)(68736007)(81156014)(53936002)(33656002)(82746002)(6246003)(3660700001)(2900100001)(5660300001)(106356001)(478600001)(3280700002)(4326008)(305945005)(6916009)(14454004)(966005)(105586002)(7736002)(2950100002)(6486002)(77096006)(6512007)(6306002)(6436002)(66066001)(6506007)(8936002)(53546011)(99286004)(230783001)(36756003)(97736004)(86362001)(316002)(102836004)(229853002)(83716003)(25786009)(6116002)(59450400001)(81166006)(76176011)(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;
x-microsoft-antispam-message-info: OUpqvvPQd0pWv7R8wVY+TMRQdiAzz5iZ7lYUK/UbhywVSBjJSbGIPk76xkmuW9exknrSNz9zzjU1OIZ8X88+RQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <1BF04273D05F174F870B6C1DED539FA6@namprd11.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc813ba-dd8f-4037-34e0-08d553bcda91
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 21:48:12.6980 (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: _k7LXjCaM4a9zIHE1K4mbQ-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/WARnm0BWlQIkSszTtZr7N6X7Agg>
Subject: Re: [nfsv4] Opsdir last call review of draft-ietf-nfsv4-flex-files-15
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: Thu, 04 Jan 2018 21:48:24 -0000

Hi Linda,

Thanks for the review.

> On Jan 4, 2018, at 10:49 AM, Linda Dunbar <ldunbar@huawei.com> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I think the document is written very clear. Ready to move forward, except some
> minor Nits. The document used "uids" and "gids" extensively.  I assume that
> "uids" = "User IDs". How about "gids"? does it mean "Group IDs"? it will be
> helpful to expand it at the first occurance in the document.

I can do that.


> In Section 2.2.2
> (Examples of using uids & gids) (Page 9), why saying "owner and group are
> modified.."? what does the value "1066" or "1067" represent (as the value
> "1697" represents the UID of the user "loghyr”)?

1697 is the file size.

However, I agree that the transition from:

   On the storage device, it may be assigned some random synthetic uid/
   gid to deny access:

   -rw-r-----    1 19452   28418    1697 Dec  4 11:31 data_ompha.c

to

   When the file is opened on a client, since the layout knows nothing
   about the user (and does not care), whether loghyr or garbo opens the
   file does not matter.  The owner and group are modified and those
   values are returned.

   -rw-r-----    1 1066    1067     1697 Dec  4 11:31 data_ompha.c

Does not make sense.

I’ve analyzed it and understand the point I was trying to make, but we’ve
gone away from that intent.

I’m going to suggest replacing it with:

   On the storage device, it may be assigned some random synthetic uid/
   gid to deny access:

   -rw-r-----    1 19452   28418    1697 Dec  4 11:31 data_ompha.c

   When the file is opened on a client and accessed, it will try to get a
   layout for the data file. Since the layout knows nothing
   about the user (and does not care), whether the user loghyr or
   garbo opens the file does not matter.  The client has to present
   an uid of 19452 to get write permission. If it presents any other
   value for the uid, then it must give a gid of 28418 to get read
   access.

   Further, if the metadata server decides to fence the file, it may
   change the uid and gid as such:

   -rw-r-----    1 19453   28419    1697 Dec  4 11:31 data_ompha.c




> 
> Linda Dunbar
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>

v2.23.0 | Report a Bug | By Email