IETF Logo Mail Archive

Re: [secdir] [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard

Nico Williams <nico@cryptonector.com> Thu, 04 April 2013 18:50 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA8221F8D40; Thu, 4 Apr 2013 11:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IbXi2z0CAHp; Thu, 4 Apr 2013 11:50:57 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD021F8D1C; Thu, 4 Apr 2013 11:50:57 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 7811C36007C; Thu, 4 Apr 2013 11:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yQzikiiRZQ28Q3cggg6w 9L1F3vo=; b=ierx04cCAY+sR7zonCafRR8tVZ/qyhYrxB0+J/hydq5+ah/RQtnK JeedkF9zAiNu8VFNP/RUJAvxDCBhfObbDP93gvJxSouSdoDks73MQ5eeEEg28yWW KmSzhw+RH5Yr2Se28aSnlp98Cx+ElabWZBSGMkjTAj3YMoNU5+VpYbI=
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 1C25F360014; Thu, 4 Apr 2013 11:50:52 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id k13so3130431wgh.5 for <multiple recipients>; Thu, 04 Apr 2013 11:50:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.11.70 with SMTP id o6mr11523044wjb.29.1365101451215; Thu, 04 Apr 2013 11:50:51 -0700 (PDT)
Received: by 10.217.105.195 with HTTP; Thu, 4 Apr 2013 11:50:51 -0700 (PDT)
In-Reply-To: <alpine.GSO.1.10.1304041234320.9389@multics.mit.edu>
References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> <alpine.GSO.1.10.1303312327530.9389@multics.mit.edu> <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com> <alpine.GSO.1.10.1304041234320.9389@multics.mit.edu>
Date: Thu, 04 Apr 2013 13:50:51 -0500
Message-ID: <CAK3OfOgmO+zqNEwyzcgnVYiGBvPbq3Ka5BxNPFp-f0K-1uLhLw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Cc: "Haynes, Tom" <Tom.Haynes@netapp.com>, "ietf@ietf.org" <ietf@ietf.org>, nfsv4 list <nfsv4@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 18:50:57 -0000

On Thu, Apr 4, 2013 at 12:36 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> In combination with Tom's proposed changes, this table should work well.

I agree.

> Agreed that some text about what qop 0 means is needed.

I yes.  Indeed, maybe we should even remove the qop column and state
that we always use qop 0 unless otherwise stated (and we'll not state
otherwise).

>> KITTEN WG should undertake an extension to replace the broken qop concept.
>
> I worry that such an undertaking would degenerate into a full GSS-API
> rewrite, but regardless that's out of scope for the current discussion.

I don't think so.  We've discussed it [since] on IRC, and it's not
relevant here so I'll not burden the cc'ed with it.  I'll bring
something to KITTEN WG about this *after* the interim meeting that's
coming up, but NFSv4 WG should not wait for it.

Nico
--

v2.23.0 | Report a Bug | By Email