Re: [nfsv4] AD review: draft-ietf-nfsv4-rpcsec-gss-v2-03

Lars Eggert <lars.eggert@nokia.com> Mon, 18 August 2008 20:59 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 972283A6A90; Mon, 18 Aug 2008 13:59:04 -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 E8CF23A6D93 for <nfsv4@core3.amsl.com>; Mon, 18 Aug 2008 13:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.225
X-Spam-Level:
X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 36BNRx1ITUZv for <nfsv4@core3.amsl.com>; Mon, 18 Aug 2008 13:59:02 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 194753A6D91 for <nfsv4@ietf.org>; Mon, 18 Aug 2008 13:59:01 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IKx57M018503; Mon, 18 Aug 2008 15:59:06 -0500
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 23:59:05 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 23:59:05 +0300
Received: from [10.121.12.237] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 23:59:04 +0300
Message-Id: <6A3C6C08-6A9D-4CF1-91EB-2BCAEB4A1A55@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: "ext mike@eisler.com" <mike@eisler.com>
In-Reply-To: <13364.198.95.226.230.1219088407.squirrel@webmail.eisler.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Mon, 18 Aug 2008 13:59:00 -0700
References: <13364.198.95.226.230.1219088407.squirrel@webmail.eisler.com>
X-Mailer: Apple Mail (2.926)
X-OriginalArrivalTime: 18 Aug 2008 20:59:04.0611 (UTC) FILETIME=[3F921730:01C90175]
X-Nokia-AV: Clean
Cc: NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] AD review: draft-ietf-nfsv4-rpcsec-gss-v2-03
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

On 2008-8-18, at 12:40, ext mike@eisler.com wrote:
> On Mon, August 11, 2008 3:05 am, Lars Eggert wrote:
>> Section 1, paragraph 0:
>>>   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.
>>
>>   I'd be good to add a citation to [2] for RPCSEC_GSSv1 and RFC5056  
>> for
>>   "channel bindings." We can do that with an RFC Editor Note - send  
>> me
>>   one.
>
> I agree it would be good. But xml2rfc doesn't allow abstracts to  
> have xrefs.

Sorry I was unclear - I was talking about the first sentence in the  
introduction, not the abstract.

(And you could just add the references as raw text - e.g. "[RFC5056]"  
- instead of using xref or having the RFC Editor do this.)

If you agree, I'll add an RFC Editor Note to the datatracker that adds  
these two references to the introduction, and then start the IETF last  
call?

>> Section 7., paragraph 1:
>>>   The security considerations are the same as [2].
>>
>>   This document is all about applying a security mechanism (channel
>>   bindings) to [2]. Surely this raises new security considerations?
>>   If not, please explain why not - this is surely something the  
>> security
>>   directorate will want to know.
>
> Agreed.
>
> Nico provided some useful ideas for security considerations. These
> are now in -04.

Great, thanks!

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