Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-00.txt

Trond Myklebust <trond.myklebust@fys.uio.no> Mon, 18 October 2010 19:43 UTC

Return-Path: <trond.myklebust@fys.uio.no>
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 143343A6AE3 for <nfsv4@core3.amsl.com>; Mon, 18 Oct 2010 12:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.369
X-Spam-Level:
X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 0G0sX7QQ68nN for <nfsv4@core3.amsl.com>; Mon, 18 Oct 2010 12:43:43 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id E297E3A6ABB for <nfsv4@ietf.org>; Mon, 18 Oct 2010 12:43:42 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <trond.myklebust@fys.uio.no>) id 1P7vdv-0000pP-1T for nfsv4@ietf.org; Mon, 18 Oct 2010 21:45:11 +0200
Received: from c-68-40-206-115.hsd1.mi.comcast.net ([68.40.206.115] helo=[192.168.1.29]) by mail-mx3.uio.no with esmtpsa (SSLv3:CAMELLIA256-SHA:256) user trondmy (Exim 4.69) (envelope-from <trond.myklebust@fys.uio.no>) id 1P7vdu-0001UG-9k for nfsv4@ietf.org; Mon, 18 Oct 2010 21:45:10 +0200
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: nfsv4@ietf.org
In-Reply-To: <20101018174520.D207C3A6CAF@core3.amsl.com>
References: <20101018174520.D207C3A6CAF@core3.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 18 Oct 2010 15:45:07 -0400
Message-ID: <1287431107.3646.15.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 (2.30.3-1.fc13)
Content-Transfer-Encoding: 7bit
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 1035 max rcpts/h 20 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: D7E5E39E3D60876E629CDDBC611B2D25D50E6755
X-UiO-SPAM-Test: remote_host: 68.40.206.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 412 max/h 7 blacklist 0 greylist 0 ratelimit 0
Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv6-00.txt
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/mail-archive/web/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: Mon, 18 Oct 2010 19:43:44 -0000

On Mon, 2010-10-18 at 10:45 -0700, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network File System Version 4 Working Group of the IETF.
> 
> 
> 	Title           : NFS operation over IPv6
> 	Author(s)       : A. RN, et al.
> 	Filename        : draft-ietf-nfsv4-ipv6-00.txt
> 	Pages           : 8
> 	Date            : 2010-10-18
> 
> This Internet-Draft provides the description of problems faced by NFS
> and its various side band protocols, when implemented over IPv6 in
> various deployment scenarios.  Solutions to the various problems are
> also given in the draft and are sought for approval.
> 
> Foreword
> 
> This "forward" section is an unnumbered section that is not included
> in the table of contents.  It is primarily used for the IESG to make
> comments about the document.  It can also be used for comments about
> the status of the document and sometimes is used for the RFC2119
> requirements language statement.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ipv6-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

The RPCBIND requirement (MUST) is definitely unwelcome. The whole point
of giving NFSv4 a fixed port was in order to get rid of the reliance on
portmapping.

There is nothing in the document that justifies the prohibition on using
IPv4 embedded IPv6 addresses.

I don't understand the utility of the paragraph:
                While making a callback to an address received in a NLM
                LOCK call or a NFSv4 SETCLIENTID call, a server MUST
                specify the local interface via which the call needs to
                be made (or let the default zone be selected, if
                supported).
In NFSv4, if the server is calling the client back, then it is the one
initiating the TCP connection. There is no need for (nor is there even a
mechanism for) specifying on which interface the client must reply to
the RPC call.

Cheers
  Trond