Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16

"Haynes, Tom" <Tom.Haynes@netapp.com> Wed, 17 April 2013 00:16 UTC

Return-Path: <Tom.Haynes@netapp.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 9BF2B21F96BA; Tue, 16 Apr 2013 17:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level:
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 GZYQEE706gcl; Tue, 16 Apr 2013 17:16:09 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A73A321F96B1; Tue, 16 Apr 2013 17:16:09 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,488,1363158000"; d="scan'208,217"; a="41327775"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 16 Apr 2013 17:16:09 -0700
Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3H0G9V7027416; Tue, 16 Apr 2013 17:16:09 -0700 (PDT)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.213]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 17:16:09 -0700
From: "Haynes, Tom" <Tom.Haynes@netapp.com>
To: Magnus Nyström <magnusn@gmail.com>
Thread-Topic: Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16
Thread-Index: AQHOOaGwbw2pkgFJhUGOof48vd6FlJjaA5kA
Date: Wed, 17 Apr 2013 00:16:08 +0000
Message-ID: <D3C85B3C-1FD3-4ED8-8195-3AEB2B984C89@netapp.com>
References: <CADajj4Zpeis=swQ8OrSWoKYb2f89jfs28UwOeBY76gb12ifLHg@mail.gmail.com>
In-Reply-To: <CADajj4Zpeis=swQ8OrSWoKYb2f89jfs28UwOeBY76gb12ifLHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/alternative; boundary="_000_D3C85B3C1FD34ED881953AEB2B984C89netappcom_"
MIME-Version: 1.0
Cc: "<draft-ietf-nfsv4-rfc3530bis-dot-x@tools.ietf.org>" <draft-ietf-nfsv4-rfc3530bis-dot-x@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16
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: Wed, 17 Apr 2013 00:16:10 -0000

On Apr 14, 2013, at 11:22 PM, Magnus Nyström <magnusn@gmail.com<mailto:magnusn@gmail.com>> wrote:

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, except for the introductory section and standard sections towards the end, it consists entirely of extractable, machine-readable declarations and definitions.

The Security Considerations section simply refers to the rfc2530bis main document. This may be sufficient; however, if the NFSv4.0 XDR definition introduces any new parsing risks (for example, anything related to internationalization?), then it may be better placed in this document.

-- Magnus


Hi Magnus,

That simply becomes too unwieldily.

We have another example of this, RFC 5661 and 5662. I always look at RFC 5661 and I rarely look at RFC 5662.

My expectation is that this is the way others work.

I would prefer to leave the internationalization work back in the main document.

Thanks,
Tom