Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-artwork-folding-09: (with COMMENT)
Kent Watsen <kent+ietf@watsen.net> Thu, 05 September 2019 22:03 UTC
Return-Path: <0100016d03744774-f6d771b0-9c05-42e5-9e1a-58c018fb0325-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1D120B4E; Thu, 5 Sep 2019 15:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Rqw9QKExMBIG; Thu, 5 Sep 2019 15:03:37 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57EC120B20; Thu, 5 Sep 2019 15:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567721015; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=NF5CG2PyKqF3wVYK2+bK5tOjmp2NiIpN7Cn5aTPrM7o=; b=MzWoID2RyaSRF1juTtfomE/NyKkyzkgjjZqabUqaHA9Zn58z/yFsb1i6Dv8TtU6N k6Y5SKUfYkxAyUzf4GcC0/WfiNrCQ6pcJSMHCWOBJm1Ia2t8VH4gszdlf0hE3tiY5HD cJtxrqwMN7Iml1pS6yjMlafgXZ8SG7O1j2tiKWjI=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d03744774-f6d771b0-9c05-42e5-9e1a-58c018fb0325-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E4E36897-A45C-4C2B-980B-B555B13DA821"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 05 Sep 2019 22:03:35 +0000
In-Reply-To: <156755725979.20611.1246275298689979326.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
To: Adam Roach <adam@nostrum.com>
References: <156755725979.20611.1246275298689979326.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.05-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/UmmCSQhQnyc_8-ECbTQCUoDcvFA>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-artwork-folding-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 22:03:48 -0000
Hi Adam, Thank you for your review. Comments below. Update @ https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 <https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10> Kent // as co-author > On Sep 3, 2019, at 8:34 PM, Adam Roach via Datatracker <noreply@ietf.org> wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-netmod-artwork-folding-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for taking on this work to fill a hole in the tools that > we have for production of RFCs. I have one fairly major comment > and several editorial suggestions. > > --------------------------------------------------------------------------- > > Abstract: > >> This document defines two strategies for handling long lines in >> width-bounded text content. One strategy is based on the historic >> use of a single backslash ('\') character to indicate where line- > > Nit: "historical" Fixed. > --------------------------------------------------------------------------- > > §1: > >> According to the RFC Editor, >> there is currently no convention in place for how to handle long >> lines in such inclusions, other than advising authors to clearly >> indicate what manipulation has occurred. > > This won't age well. Perhaps "Historically, there has been no > RFC-Editor-recommended convention in place for how to handle..." Suggested text incorporated. > --------------------------------------------------------------------------- >> This document defines two strategies for handling long lines in >> width-bounded text content. One strategy is based on the historic >> use of a single backslash ('\') character to indicate where line- > > Nit: "historical" Fixed. > --------------------------------------------------------------------------- > > §7.1.1: > >> NOTE: '\' line wrapping per BCP XXX (RFC XXXX) > > Using this string as the start of the specially-wrapped section > seems somewhat problematic, as it forecloses on the possibility > of also *citing* this BCP at that point in the document. For example, > if I were to use this format, I would definitely want to use a string > more of the format: > > NOTE: '\' line wrapping per BCP XXX ([RFC XXXX]) > > (taking note of the added brackets). > > If this has already been debated in the working group and the current text > is the result of carefully considering this issue and deciding that the > use of the specified string has benefits that outweigh the drawback of > not being able to cite the document per ordinary convention, then don't afford > my suggestion any undue weight. I'm not trying to change a consensus decision. > > But if this is a simple oversight, I think it does need to be given > significant thought. For example, I personally am rather likely to elect to do > things "the old way" in my own documents rather than using this format because > of the awkwardness of properly citing a normative reference. > > This same comment applies to §8.1.1, of course. Unsure. To provide context, YANG modules many times include references to RFCs in artwork sections. I used to put these references inside square brackets, but the RFC Editors would convert them to parentheses. I have since moved to using parentheses, e.g., "(RFC XXXX)", in artwork and haven't experienced any corrections since. Leaving as is for now. > --------------------------------------------------------------------------- > >> Appendix A. POSIX Shell Script: rfcfold > > Please add [POSIX.1-2017] as a reference. I've replaced "POSIX" with "Bash", and added a reference for Bash. Kent // as co-author
- [netmod] Adam Roach's No Objection on draft-ietf-… Adam Roach via Datatracker
- Re: [netmod] Adam Roach's No Objection on draft-i… Erik Auerswald
- Re: [netmod] Adam Roach's No Objection on draft-i… Kent Watsen