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

[David Noveck <[e-mail]>]

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.    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.

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.
>