IETF Logo Mail Archive

Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 09 August 2017 17:33 UTC

Return-Path: <spencerdawkins.ietf@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 68A66132256; Wed, 9 Aug 2017 10:33:51 -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 G4jajeyOSLGx; Wed, 9 Aug 2017 10:33:49 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 0E876132021; Wed, 9 Aug 2017 10:33:46 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id p68so44319627ywg.0; Wed, 09 Aug 2017 10:33:46 -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=j6pS7iu2VwV//4mf9zvstwWabNEg/Cyi+83oJ1ZRxms=; b=JYn2x8AQ4nE9A6OMziPN14N2twnmBIoV248qm1/EoYH5XCwy8NsIfIVglwJMu2Zt8l Qa4mc2A1LvzwbAcDF3kCsY96+PIDxAGBc7y7VCgCIbayEP1fJVFduXnFU1e2AC1nG/8+ od+hs92SJRiVFvTaPvnID33yw//PNjRjAYOJg4WXCkJnae8bxAKzdEmDGbjG7U+GTn9j juGfihPFwUekvQQXXa1AbpuksPf6OQUMLICuxApXzVYWAdpU9k8qo3oBYR1L5Z2/TTfq z/snlFxYg6Kq/uVDKqyDoll9dmlnQVCigDLqFajE0GrGNp/A6GWcLcwG9ge9kjSAiHVO pUIg==
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=j6pS7iu2VwV//4mf9zvstwWabNEg/Cyi+83oJ1ZRxms=; b=Hz7wEGjj6Ro6Xiy8/hhP7KhnDoozleEErfxHYJbCp3RFvbbv/DF+TyKERIIMsPyt3c pqqkdeo/swPAD9KPAZbXSDJp/AgElvTA5m0UbQCBcLLpDPp2EVcvzMDsIKSOTE6wzTGu y7UA19pnPjZIjz2mWXYZQD651vr2fFR5Ivc3+wYNL1nzEIVf5B7swSyesKxV9lz9hOra 6kWyAOn1ns6acLDXts1rWssPbzU0Fy+LI1r1739wq3xTc8q/ACKoHvgRXapFhDRMCeyj gWga+RdSnAt1LBu/WTrzi7o7Za50EFkCIx+jARXSa3pHmobhF6rNUB+bxxgfol8tawqh KYTg==
X-Gm-Message-State: AHYfb5hSELAC0R1YSF8c8Pkl+mSlqxcf91s99YOAI4PnXB0FSdF6/+WM GxCJTe0TRMupCZFFoTkEKu8a1Y5JKXKI
X-Received: by 10.13.210.67 with SMTP id u64mr7331877ywd.218.1502300025185; Wed, 09 Aug 2017 10:33:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 10:33:44 -0700 (PDT)
In-Reply-To: <CADaq8jdQcHq4oNXgtJH5B4dVawtsgtFiWQFz5V_Hb=M7HD=2cQ@mail.gmail.com>
References: <CAKKJt-fFFyxV=VhJxhe=3P283xZQG_yvdP6AHJkzU6iB=74JCw@mail.gmail.com> <C6965A7A-3A9F-466B-AEB7-73A8C96F3A9D@oracle.com> <CAKKJt-fbpBjz9=z8RqSGseKZxCY3e=rb6TsBZCEmNtPxKe0sdw@mail.gmail.com> <CAKKJt-foDqkhh_Q-pZT2Jqzfm8dCeBbtiRcarHJXtvMPykQFiw@mail.gmail.com> <3358F9D0-DEB8-4E86-835A-5070CD24FEAD@oracle.com> <CADaq8jdQcHq4oNXgtJH5B4dVawtsgtFiWQFz5V_Hb=M7HD=2cQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 09 Aug 2017 12:33:44 -0500
Message-ID: <CAKKJt-c-D_5ihG=A=8_DHyrYawr0MuB2DDPejGMjRAGrmB2FAw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, draft-ietf-nfsv4-rfc5667bis@ietf.org, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e7e3058ed830556557bcd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/979DD67INULpbqnrfyIdPifegIg>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11
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, 09 Aug 2017 17:33:51 -0000

Just to say something more clearly than I actually said it last time (take
2) ...

On Wed, Aug 9, 2017 at 5:53 AM, David Noveck <davenoveck@gmail.com> wrote:

> I think this is OK.  I know that there is reason to worry about SECDIR but
> there is only so much you can usefully do, until they actually have
> something to look at.
>

"Some of my best friends are SECDIR reviewers", so I'd encourage people not
to worry about them. My comments on the original text in this draft
reflected my thought that the text was potentially sending a SECDIR
reviewer down a rabbit hole

I imagine that SECDIR might be worried that direct placement could somehow
> open a hole whereby data might inadvertantly be transferred in the clear.
>
> For example, if I ordered a "Large pizza with direct pepperoni placement"
> :), the pepperoni cannot be directly placed if privcy is in effect, but
> this sort of thing is aprropriately dealt with in RFC8166, as it should be.
>

That's exactly the kind of thing I think SECDIR reviewers should be
thinking about - and working group participants as well.

Thanks for making that clearer than I could.

Spencer

v2.23.0 | Report a Bug | By Email