Re: [nfsv4] Hang when trying to process rfc8881 converted to an I-D

Henrik Levkowetz <henrik@levkowetz.com> Tue, 18 August 2020 17:41 UTC

Return-Path: <henrik@levkowetz.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870573A08AA; Tue, 18 Aug 2020 10:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeejD_V-4ffV; Tue, 18 Aug 2020 10:41:54 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5D53A08A9; Tue, 18 Aug 2020 10:41:54 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51827 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1k85cO-0004mO-Vw; Tue, 18 Aug 2020 10:41:53 -0700
To: "Noveck, David" <David.Noveck@netapp.com>, "tony@att.com" <tony@att.com>
References: <MN2PR06MB5597B574955103F5EF543823E15C0@MN2PR06MB5597.namprd06.prod.outlook.com>
Cc: Jean Mahoney <jmahoney@amsl.com>, Chuck Lever <chuck.lever@oracle.com>, nfsv4-chairs <nfsv4-chairs@ietf.org>, "nfsv4-ads@ietf.org" <nfsv4-ads@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <c7a93397-bb4b-ce6a-41a8-12486b4ef3fe@levkowetz.com>
Date: Tue, 18 Aug 2020 19:41:44 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <MN2PR06MB5597B574955103F5EF543823E15C0@MN2PR06MB5597.namprd06.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Gi6SOTMRQPk8W5OGUnANejjFHBUUCfFE0"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: nfsv4@ietf.org, nfsv4-ads@ietf.org, nfsv4-chairs@ietf.org, chuck.lever@oracle.com, jmahoney@amsl.com, tony@att.com, David.Noveck@netapp.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/uFqG9MWqTVKvpvPrxicF-WiOVcc>
Subject: Re: [nfsv4] Hang when trying to process rfc8881 converted to an I-D
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 18 Aug 2020 17:41:58 -0000

Hi David,

On 2020-08-18 17:34, Noveck, David wrote:
> I’m trying to use xml2rfc to process an I-D essentially duplicating
> the contents of rfc8881.xml.   The goal is to have a starting point
> for the working group to enable work on an rfc5661bis.  So far, it
> seems that xml2rfc always hangs/times out/aborts when I try this ☹

Yes, the online service at xml2rfc.ietf.org takes about 13 minutes to
process the 2.4 Mbytes xml file, which stretches far beyond the web
server timeout.  It's an old machine.  Unfortunately, I think this
document is too large to process with the online service as it currently
exists.

Processing the original rfc8881.xml on my desktop, I get a processing
time of 1m 15s.

> I’m using Jean’s instructions (originally directed to another
> purpose) on how to do this but they don’t seem to work:
> 
> *   Remove number="8881" from the <rfc> element.
> *   Remove the <seriesInfo> element

Yup, those are good instructions.

After doing so, the processing time on my desktop is slightly under 1m.

Additionally, in order to make it easier to work with the XML, I would
recommend doing 'unprep' on the xml, in order to undo the full expansion
of all attributes etc. which is done before publication.  Doing so will
give you less verbose XML.

On the command-line, that would be:

   $ xml2rfc --unprep rfc8881b.xml 
    Unprepping rfc8881b.xml
    Created file rfc8881b.plain.xml

Renaming that to draft-ietf-nfsv4-rfc5661bis.xml, I got this on my
desktop machine:

   $ time xml2rfc draft-ietf-nfsv4-rfc5661bis.xml 
   /home/henrik/src/xml2rfc/trunk/cli/draft-ietf-nfsv4-rfc5661bis.xml(36): Warning: The document date (2020-08-01) is more than 3 days away from today's date
    Created file draft-ietf-nfsv4-rfc5661bis.txt

   real	0m45.022s
   user	0m44.020s
   sys	0m0.210s


Best regards,

	Henrik

> In fairness to Jean, let me note that this suggestion were made
> before a big set of last-minute changes were made to the .xml file
> just before actual rfc publication.   I’m pretty sure these happened
> after author sign-off.  These include new v3 elements, that, as far
> as I can determine, have never been documented: <toc>, <boilerplate>,
> <copyright>.

> I think we need to get this resolved as soon as possible.  Some
> possibilities:
> 
> *   Debug xml2rfc so it handles a file prepared using Jean’s
> approach.   I can provide rfc8881asID.xml if that would be helpful in
> debugging this.

> *   Provide updated instructions on how to convert an RFC to a
> corresponding I-D.   I’ve tried deleting the <toc> element, deleting
> the entire <boilerplate> element but so far no luck ☹

> *   Provide an .xml that includes all the substantive changes made
> during the process of preparing the RFC for publication, but none of
> the ones that happened after the authors signed off.  I may be naïve,
> but I feel it is worth trying Jean’s procedure on that .xml file.