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

[Henrik Levkowetz <[e-mail]>]

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 <[e-mail]>
> 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 <[e-mail]>
>> Sent: Tuesday, August 18, 2020 2:15 PM
>> To: Henrik Levkowetz <[e-mail]>; Noveck, David <
>> [e-mail]>; [e-mail]
>> Cc: Chuck Lever <[e-mail]>; nfsv4-chairs <
>> [e-mail]>; [e-mail]; [e-mail]
>> 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.
>>
>