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

Henrik Levkowetz <henrik@levkowetz.com> Wed, 19 August 2020 14:01 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 81E4C3A0AC5; Wed, 19 Aug 2020 07:01:28 -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 pfGinyrm_fsP; Wed, 19 Aug 2020 07:01:25 -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 E53473A0A83; Wed, 19 Aug 2020 07:01:25 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51448 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 1k8OeZ-0008IM-U4; Wed, 19 Aug 2020 07:01:25 -0700
To: "Noveck, David" <David.Noveck@netapp.com>, David Noveck <davenoveck@gmail.com>
References: <MN2PR06MB5597B574955103F5EF543823E15C0@MN2PR06MB5597.namprd06.prod.outlook.com> <c7a93397-bb4b-ce6a-41a8-12486b4ef3fe@levkowetz.com> <137cb358-bfd0-fcbb-b142-b5b1ba5f744c@amsl.com> <MN2PR06MB55971C483A6431B9A8289994E15C0@MN2PR06MB5597.namprd06.prod.outlook.com> <CADaq8jdxaZoYCD=miMTfYe3PvU1EBqiakvEc7QOynO--sx=XxA@mail.gmail.com> <910396c5-1fd1-d6c6-4452-d8be5489ea8a@levkowetz.com> <MN2PR06MB55971F6359F16C47E4676160E15D0@MN2PR06MB5597.namprd06.prod.outlook.com>
Cc: Jean Mahoney <jmahoney@amsl.com>, "tony@att.com" <tony@att.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: <6b6530b1-20d0-6689-01f8-dc4cfc132e9c@levkowetz.com>
Date: Wed, 19 Aug 2020 16:01:15 +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: <MN2PR06MB55971F6359F16C47E4676160E15D0@MN2PR06MB5597.namprd06.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3P35XBCWo1nEQ3b9GfwB7AfgVDJDo5du2"
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, tony@att.com, jmahoney@amsl.com, davenoveck@gmail.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/aFYumR_hyhV7Idm_qVEarU6Usgs>
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: Wed, 19 Aug 2020 14:01:29 -0000

Hi David,

On 2020-08-19 15:25, Noveck, David wrote:
>> That one's 1.7 Mbytes compared to 2.4 Mbytes for rfc8881.xml. At
>> some point you're going to hit the roof of what the server can deal
>> with, and rfc8881 is 694 pages in size, so a bit special.
> 
> That’s a nice way of saying “overweight”. The current plan is to 
> split the document into two halves: draft-ietf-nfsv4-mv1-discussion 
> and draft-ietf-nfsv4-reference

Right, that sounds like a good idea.

>             >    I still can.   If local process is now a
>             > requirement, there should be a way I can simply download the
>             > application to my windows laptop.  The current download procedure is
>             > (at least) an order of magniTude more difficult than that.
> 
>>       The app has a number of dependencies, and assuming one has Python 3.5 or higher installed, running "pip install xml2rfc" is about as simple as it's possible to make an installation.
> 
> That sounds fine. I was referring to the link that Jean provided,
> which has a bunch of other installs. I assume that that is outdated.
> If so, the best/easiest procedure should be provided in the
> instructions.

The additional installs are only required if you need to produce PDF output.
The basic 'pip install xml2rfc' will give you all other functionality.

> 
>> Do you have Python 3.5 or higher installed?
> 
> I did have the version for 64-bit windows installed. I just guessed
> as I couldn’t find this info in the windows settings pages. It turns
> out I guessed wrong and got something totally non-functional. I just
> de-installed it.
> 
>> If so, exactly what is the result if you run "pip install xml2rfc"
>> ?
> 
> Will find out when I get the right one installed.

Ok, cool.


Best,

	Henrik

> -----Original Message-----
> From: Henrik Levkowetz <henrik@levkowetz.com>
> Sent: Wednesday, August 19, 2020 7:03 AM
> To: David Noveck <davenoveck@gmail.com>om>; Noveck, David <David.Noveck@netapp.com>
> Cc: Jean Mahoney <jmahoney@amsl.com>om>; tony@att.com; Chuck Lever <chuck.lever@oracle.com>om>; nfsv4-chairs <nfsv4-chairs@ietf.org>rg>; nfsv4-ads@ietf.org; nfsv4@ietf.org
> Subject: Re: [nfsv4] Hang when trying to process rfc8881 converted to an I-D
> 
> Hi David,
> 
> On 2020-08-18 21:20, David Noveck wrote:
>> I was able to process all the earlier .xml files (of similar size) without
>> difficulty.   For example, draft-ietf-nfsv4-rfc5661sesqui-msns-04 and still
>> can without local processing.
> 
> That one's 1.7 Mbytes compared to 2.4 Mbytes for rfc8881.xml.  At some point you're going to hit the roof of what the server can deal with, and rfc8881 is 694 pages in size, so a bit special.
> 
>>    I still can.   If local process is now a
>> requirement, there should be a way I can simply download the
>> application to my windows laptop.  The current download procedure is
>> (at least) an order of magniTude more difficult than that.
> 
> The app has a number of dependencies, and assuming one has Python 3.5 or higher installed, running "pip install xml2rfc" is about as simple as it's possible to make an installation.
> 
> Do you have Python 3.5 or higher installed?
> 
> If so, exactly what is the result if you run "pip install xml2rfc" ?
> 
> 
>         Henrik
> 
> 
>>
>> On Tue, Aug 18, 2020 at 2:40 PM Noveck, David
>> <David.Noveck@netapp.com<mailto:David.Noveck@netapp.com>>
>> wrote:
>>
>>> > [JM] For anyone who wants to use xml2rfc on their own machine, the
>>> download instructions are here:
>>> >
>>> > https://pypi.org/project/xml2rfc/
>>>
>>> Wasn't able to do that in my windows system.   I don't think the problem
>>> is in the instructions but in our I-T's fear (justified or not) of us
>>> downloading what appears to be random, potentially hostile code.
>>>
>>> Running this over the web has been a good way of avoiding these
>>> worries but that doesn't work for me now.
>>>
>>> -----Original Message-----
>>> From: Jean Mahoney <jmahoney@amsl.com<mailto:jmahoney@amsl.com>>
>>> Sent: Tuesday, August 18, 2020 2:15 PM
>>> To: Henrik Levkowetz <henrik@levkowetz.com<mailto:henrik@levkowetz.com>>; Noveck, David <
>>> David.Noveck@netapp.com<mailto:David.Noveck@netapp.com>>; tony@att.com<mailto:tony@att.com>
>>> Cc: Chuck Lever <chuck.lever@oracle.com<mailto:chuck.lever@oracle.com>>; nfsv4-chairs <
>>> nfsv4-chairs@ietf.org<mailto:nfsv4-chairs@ietf.org>>; nfsv4-ads@ietf.org<mailto:nfsv4-ads@ietf.org>; nfsv4@ietf.org<mailto:nfsv4@ietf.org>
>>> Subject: Re: [nfsv4] Hang when trying to process rfc8881 converted to
>>> an I-D
>>>
>>> NetApp Security WARNING: This is an external email. Do not click
>>> links or open attachments unless you recognize the sender and know
>>> the content is safe.
>>>
>>>
>>>
>>>
>>> Thanks, Henrik!
>>>
>>> Some comments inline --
>>>
>>> On 8/18/20 12:41 PM, Henrik Levkowetz wrote:
>>> > 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.
>>>
>>> [JM] For anyone who wants to use xml2rfc on their own machine, the
>>> download instructions are here:
>>>
>>> https://pypi.org/project/xml2rfc/
>>>
>>>
>>> >
>>> >> 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
>>>
>>> [JM]  The non-prepped file is also available here:
>>>
>>> https://www.rfc-editor.org/in-notes/prerelease/rfc8881.notprepped.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
>>>
>>> [JM] There are some other tweaks to make to the <rfc> element to
>>> create a bis I-D (not necessary to produce output, but to ensure that
>>> the header contains correct info):
>>>
>>>
>>> https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i
>>> -use-the-rfc-elemen
>>>
>>>
>>> >
>>> >> 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>.
>>>
>>> [JM] Before publication, a preptool is used to pull all external
>>> content into the final prepped file so that the publication file does
>>> not have external dependencies.  This introduces XML elements like
>>> <toc> and <boilerplate> and the copyright text.
>>>
>>> RFC 7991 covers the v3 vocabulary, but there have been some minor updates.
>>> The latest information can be found here:
>>>
>>>     https://xml2rfc.tools.ietf.org/xml2rfc-doc.html
>>>
>>>
>>> Best regards,
>>>
>>> Jean
>>>
>>>
>>> >> 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.
>>>
>>
> 
>