Re: [nfsv4] Protocol Action: 'RPCSEC_GSS Version 2' to Proposed Standard

Spencer Shepler <shepler@storspeed.com> Thu, 30 October 2008 15:40 UTC

Return-Path: <nfsv4-bounces@ietf.org>
X-Original-To: nfsv4-archive@megatron.ietf.org
Delivered-To: ietfarch-nfsv4-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE6C3A6A28; Thu, 30 Oct 2008 08:40:33 -0700 (PDT)
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8096F3A69E3 for <nfsv4@core3.amsl.com>; Thu, 30 Oct 2008 08:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dVg-9j1KCWH for <nfsv4@core3.amsl.com>; Thu, 30 Oct 2008 08:40:31 -0700 (PDT)
Received: from mail.storspeed.com (mail.storspeed.com [209.163.168.123]) by core3.amsl.com (Postfix) with ESMTP id 8F3173A6951 for <nfsv4@ietf.org>; Thu, 30 Oct 2008 08:40:31 -0700 (PDT)
Received: from [10.1.2.134] ([10.1.2.134]) (authenticated bits=0) by mail.storspeed.com (8.14.1/8.14.1) with ESMTP id m9UFcIUw045116 for <nfsv4@ietf.org>; Thu, 30 Oct 2008 10:38:18 -0500 (CDT) (envelope-from shepler@storspeed.com)
Message-Id: <4CCDCAD6-752E-47E6-A349-8F791F83EB3E@storspeed.com>
From: Spencer Shepler <shepler@storspeed.com>
To: nfsv4@ietf.org
In-Reply-To: <20081030140205.CF1203A6A6A@core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 30 Oct 2008 10:40:22 -0500
References: <20081030140205.CF1203A6A6A@core3.amsl.com>
X-Mailer: Apple Mail (2.929.2)
Subject: Re: [nfsv4] Protocol Action: 'RPCSEC_GSS Version 2' to Proposed Standard
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: nfsv4-bounces@ietf.org
Errors-To: nfsv4-bounces@ietf.org

Yeah!

I would like to extend my thanks to everyone that participated in
the creation of this work and to Mike for being editor of the I-D.

Spencer

On Oct 30, 2008, at 9:02 AM, The IESG wrote:

> The IESG has approved the following document:
>
> - 'RPCSEC_GSS Version 2 '
>   <draft-ietf-nfsv4-rpcsec-gss-v2-06.txt> as a Proposed Standard
>
> This document is the product of the Network File System Version 4  
> Working
> Group.
>
> The IESG contact persons are Lars Eggert and Magnus Westerlund.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-06.txt
>
> Technical Summary
>
> RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS
> version 1 (RPCSEC_GSSv1) except that support for channel
> bindings has been added. The primary motivation for channel
> bindings is to securely take advantage of hardware assisted
> encryption that might exist at lower levels of the networking
> protocol stack, such as at the Internet Protocol (IP) layer
> in the form of IPsec. The secondary motivation is that even
> if lower levels are not any more efficient at encryption than
> the RPCSEC_GSS layer, if encryption is occurring at the lower
> level, it can be redundant at the RPCSEC_GSS level.
>
> Working Group Summary
>
> The working group development and review of this work was
> straightforward. The motivation is well understood and
> agreed upon and no major issues were identified or impeded
> progress during document review.
>
> Document Quality
>
> No existing implementations yet exist but given the author
> and reviewers are knowledgeable about more than one
> implementation of the current RPCSEC_GSS protocol, it is
> believed that the quality of this work is to be considered
> "high".
>
> Personnel
>
> Spencer Shepler (spencer.shepler@gmail.com) is the Document
> Shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed this
> document for the IESG.
>

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