Re: [nfsv4] 3530bis Issue 39: Clarification on renewing sequence IDs

Thomas Haynes <thomas@netapp.com> Sat, 20 November 2010 06:32 UTC

Return-Path: <Thomas.Haynes@netapp.com>
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 F01EB3A68D2 for <nfsv4@core3.amsl.com>; Fri, 19 Nov 2010 22:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.491
X-Spam-Level:
X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 ERyX4yWR1wp6 for <nfsv4@core3.amsl.com>; Fri, 19 Nov 2010 22:32:33 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 5EDCB3A67B0 for <nfsv4@ietf.org>; Fri, 19 Nov 2010 22:32:33 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.59,227,1288594800"; d="scan'208,217"; a="484822159"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 19 Nov 2010 22:33:24 -0800
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAK6XOqA007020; Fri, 19 Nov 2010 22:33:24 -0800 (PST)
Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Nov 2010 22:33:24 -0800
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Nov 2010 01:33:22 -0500
Received: from sureshb-lxp.hq.netapp.com ([10.58.54.184]) by RTPMVEXC1-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Nov 2010 01:33:21 -0500
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-1-542467327"
From: Thomas Haynes <thomas@netapp.com>
In-Reply-To: <03d401cb8875$91577450$b4065cf0$@gmail.com>
Date: Fri, 19 Nov 2010 22:33:16 -0800
Message-Id: <803BB03A-C16E-487C-B3EE-5A79825CF619@netapp.com>
References: <4CACD9BF.2010809@oracle.com> <4CD32C31.3040909@oracle.com> <1288965554.3975.27.camel@heimdal.trondhjem.org> <BF3BB6D12298F54B89C8DCC1E4073D8002945154@CORPUSMX50A.corp.emc.com> <1290100143.7245.9.camel@heimdal.trondhjem.org> <BF3BB6D12298F54B89C8DCC1E4073D8002A5EE45@CORPUSMX50A.corp.emc.com> <1290207533.3135.80.camel@heimdal.trondhjem.org> <B038A121-D2A2-4FAE-B499-309125BBE4C9@netapp.com> <03d401cb8875$91577450$b4065cf0$@gmail.com>
To: Spencer Shepler <spencer.shepler@gmail.com>
X-Mailer: Apple Mail (2.1081)
X-OriginalArrivalTime: 20 Nov 2010 06:33:22.0252 (UTC) FILETIME=[D3E518C0:01CB887C]
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] 3530bis Issue 39: Clarification on renewing sequence IDs
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: Sat, 20 Nov 2010 06:32:35 -0000

On Nov 19, 2010, at 9:41 PM, Spencer Shepler wrote:

> 
> While publishing additions to the WG alias in xml is fine
> with me, please ensure that it is somewhat readable.
> 
> Also, take care not to use github as the publishing mechanism.  I-Ds are
> the place to capture reasonable interim versions of the I-D.
> 
> Spencer
> 

Agreed, just like the 4.1 editors used the nfsv4-editor site to maintain the
source and published the drafts as an I-D. What I did with rfc3530 was to
publish the draft first as an I-D and then to check in a copy of the text file
to github. This allowed the make process to be able to generate consistent
diffs against the published versions.

Without thinking too much, I envision the first draft to be submitted before the
interim meeting and the second draft in time for IETF 80 in Prague.

And just like the 3530bis work, the proper readable format for the xml 
is in the framework adopted for the NFSv4.1 editing process. I have no
plans to deviate from what has been working for us.

https://github.com/loghyr/NFSv4.2

is the initial port of the NFSv4.1 xml to the NFSv4.2 xml. As the README
clearly states, only the XDR xml is currently making. I'll start putting the
framework in place for the specification draft this weekend.