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

David Noveck <davenoveck@gmail.com> Tue, 18 August 2020 19:20 UTC

Return-Path: <davenoveck@gmail.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 CFFE03A0B03; Tue, 18 Aug 2020 12:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 m4rKJZoVyqSA; Tue, 18 Aug 2020 12:20:45 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15303A0AC8; Tue, 18 Aug 2020 12:20:44 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id c10so16151171edk.6; Tue, 18 Aug 2020 12:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rIvZDtrq5pwZdcKE0azH6abF6F9ErBg42ezPU18hkpE=; b=Vgx3nRVRWo3d+IfmQcP+OI3/PsC5dfQbu9lLeeG6U74vGJo8uILFpfAW1k3tkzxNrD yJ4AVwu1Uhv2gMV84B+50etZY/FS3ma/u7A9Rqg/xV+Wc6TbJiwMnAUOpCNcESisnv2t z0GOH9b43pq49OfIk8izJOWOrXhnkMVDcvclYQfyEXW5QMvyrbWLkQlvRmv4+c0AGri5 YV3d5Ukfkr/P/4hANZABU4hDtTFAiHXIvzAfgtdfw3wbkP+68QTkm+q4fkYP/t75w+pN qkvwQ6abgzasPhObColqt8yreuRBet5UdXcbNz4FW0RDzMu7RDjwCOHhU8OAkM9fxYuc u6CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rIvZDtrq5pwZdcKE0azH6abF6F9ErBg42ezPU18hkpE=; b=JSUI0WqUqWWLOoOkSYsHuQs1v+tmwqLRGEr8bsji6KhLJlAU1JrlYd1IKwj0zF3+T1 zHwJaGnJote7I80pglM+7h4PZjMiX2lg2f9Xgl+hdyQJHL1t7DaIk76s6itSd+gFzuau yJWyQ/ffwzVUuR0H2bNQ/YMwloR5n1W+U+LjRpsgS1DEPQHC1b0ytehBLonVAXJxsN2c YCJWCaz8/oHMfaZQwdBW1BGmtwYs8L+X8fczp83iylL7LMPpdYc944+2DO71ai6zdgB2 fd/a+CBEQhwMD3rq11H2eFUJOdRD1B2LH6yw5alQfTgxxxOsF6b0fgtbV9shDhdyZQEN OCaQ==
X-Gm-Message-State: AOAM533g+OINAoJmO5D1kt9Fvytvzs4ipTidh0GO3GFHc/hWjcZX7RYw VpdLjcq3P5+FjkrawAFVNXd4pTfeu1W8kzRrOAU=
X-Google-Smtp-Source: ABdhPJze8af+PSu3wXL9ej1K1leJnMEHujOTXSsPbxjPU8zPyX73J6GaW1RfFv7A1BGSoPqb4bJjG+A90/X8/4J8ff8=
X-Received: by 2002:a50:f687:: with SMTP id d7mr21512415edn.306.1597778443202; Tue, 18 Aug 2020 12:20:43 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <MN2PR06MB55971C483A6431B9A8289994E15C0@MN2PR06MB5597.namprd06.prod.outlook.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 18 Aug 2020 15:20:32 -0400
Message-ID: <CADaq8jdxaZoYCD=miMTfYe3PvU1EBqiakvEc7QOynO--sx=XxA@mail.gmail.com>
To: "Noveck, David" <David.Noveck@netapp.com>
Cc: Jean Mahoney <jmahoney@amsl.com>, Henrik Levkowetz <henrik@levkowetz.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>
Content-Type: multipart/alternative; boundary="0000000000008975f005ad2bc886"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/cNPB8PEBKEDzbQiyRkVuRafe-pQ>
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 19:20:54 -0000

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 <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>
> Sent: Tuesday, August 18, 2020 2:15 PM
> To: Henrik Levkowetz <henrik@levkowetz.com>om>; Noveck, David <
> David.Noveck@netapp.com>gt;; tony@att.com
> Cc: Chuck Lever <chuck.lever@oracle.com>om>; nfsv4-chairs <
> nfsv4-chairs@ietf.org>gt;; nfsv4-ads@ietf.org; 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.
>