Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Kent Watsen <kwatsen@juniper.net> Tue, 26 June 2018 18:06 UTC

Return-Path: <kwatsen@juniper.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 222581310ED for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 11:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 XsNJs_PxqqAB for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 11:06:24 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B41130F06 for <netmod@ietf.org>; Tue, 26 Jun 2018 11:06:24 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5QHNifG028287; Tue, 26 Jun 2018 10:24:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=XGBHpBPDWoNLLMH2NXh3VCgzL/WmDRVfwVNULyXvocE=; b=Xog5CSiLV+DOMqU8jOrOBI8RlO2oRKqe09cHRqZGGrbBfrUMKopG3It280bCAo8ro3oU EWvw2HlS2KfWuFe+eJdE8cXyx4BQhOE+Ccl8z6c3pANPQzOqh+RK6UH7hyKpozcsNOT2 N9V6EXtrwjJqT6cH6RIk5XVfar2zvrEkfHgud1VVL7589nRq28ILkwlUpjX+v4Glab8S NsHcrScTBwVaPQHjYHWJS1LnlSMYc1zb8w22Lz8Pr6YnCrmRy/av47Cdrmtgk71EFpm3 GoYMU9pfHjXv4gPWRbBdSXdFEAetlwaXpJh9hPPIOtF1trdF8jkZNbXNsoww61Y5oE+0 mw==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0b-00273201.pphosted.com with ESMTP id 2jus0a0387-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 26 Jun 2018 10:24:15 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB3989.namprd05.prod.outlook.com (52.135.199.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.17; Tue, 26 Jun 2018 17:24:13 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0906.018; Tue, 26 Jun 2018 17:24:13 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>, "bill.wu@huawei.com" <bill.wu@huawei.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
Thread-Index: AQHUCpK0us9UwwoDtU2EaBoFZiTowKRyWwQAgAAxxwA=
Date: Tue, 26 Jun 2018 17:24:13 +0000
Message-ID: <34C78C9F-57A9-4234-8F30-39F69F0B2F04@juniper.net>
References: <B8F9A780D330094D99AF023C5877DABA9AEB4274@nkgeml513-mbx.china.huawei.com> <20180626.122602.1952551623315308243.mbj@tail-f.com>
In-Reply-To: <20180626.122602.1952551623315308243.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB3989; 7:V8Q7XT1KBu09SbX9MssL08SeFTV983Zx+RFq8KEQvWJES7qsLME1hcsWFoW8f5hq4i6o2oDA/6q0lq6Sd020E38LA9VzFSZPet9ledF0pRICeuyDY5CsNtTVje0W/2zSNm3DpfazIVT4uKXcjQ3nA4YlwOryrU1nHxNja6wZcObOEFc/NVGH7dmGEzsHVwK/WvA+8q45ufl5SjGf/QVvZ9yLghN0CbYkbikR8iOKmYICNw588N7vqCBSR3hFQhcF
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e01fdbd4-e5df-4808-1691-08d5db89a337
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3989;
x-ms-traffictypediagnostic: BYAPR05MB3989:
x-microsoft-antispam-prvs: <BYAPR05MB3989FF5984083FE00C017346A5490@BYAPR05MB3989.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(50582790962513);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB3989; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3989;
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39860400002)(136003)(189003)(199004)(51444003)(478600001)(97736004)(5660300001)(33656002)(305945005)(966005)(2900100001)(102836004)(106356001)(110136005)(2501003)(58126008)(5250100002)(105586002)(2906002)(7736002)(186003)(68736007)(316002)(26005)(6506007)(6512007)(8936002)(76176011)(229853002)(86362001)(6306002)(486006)(8676002)(99286004)(6246003)(53936002)(66066001)(83716003)(6116002)(81156014)(82746002)(3846002)(6436002)(14454004)(6486002)(4326008)(2616005)(11346002)(25786009)(446003)(36756003)(476003)(81166006)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3989; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RAcKsSCUjzg/1PT29+JqQWNzNNPQFZ4pnglTVn5G44lTbuKbXWaFJz9A++RnBYm/s3tjvJkG4YGqI1p46I9lonRqexWAcxNZJV/FjHrEwZpoTCskEN8NLZ/eYaBloLWPK1/rqdpyRuILwzBjLwdk7JpRJ1hEvlwqbuEM0/I47HHEZho187az5tlgTDhWAfihmukwcjHlmOnwGO/WkYmKZ/MGwvL12zfQgDYLP3vLezEe10mhI2A+6RA0sQLSEMmvMpi4szYQhoGsW3PpVMy/eSuAuzLPWvQGdB+78bcm3rlVbrw3Oot4Kv2f+Pna65ffuAwNQ3y6Sg+z0yGyWTrCVYd0kk3Q4M1nY7cOApRCQbs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5515771B6B9E7B4FB118D5135FC2571A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: e01fdbd4-e5df-4808-1691-08d5db89a337
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 17:24:13.6931 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3989
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-26_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806260196
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BnYDdM2FjhIPcct2vc8k8fVrHl8>
Subject: Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 26 Jun 2018 18:06:27 -0000

Hi Martin,

First, I just posted -05 to address the missing artwork:
https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-05.

See below for more comments.

Kent // contributor


===== original message =====

> Hi,
>
> I support this work.   See below for some comments.
>
> Qin Wu <bill.wu@huawei.com>; wrote:
>> Dear WG,
>> 
>> As you may recall I presented yang-xml-doc-conventions in London.
>> There was strong support for trying to solve the problem and mixed
>> views on the solution, other than that we should do it fast.  In the
>> meanwhile, Kent submitted artwork-folding as an alternative solution.
>> 
>> The authors of the two drafts decided to combine efforts.  After
>> several internal iterations on both drafts, the drafts were becoming
>> more alike than different(both support auto wrapping or auto folding).
>> The artwork-folding draft was selected as a preferred offering basis
>> (i.e., draft-kwatsen-netmod-artwork-folding-04) to the working group
>> to consider for adoption.
>> 
>> The primary feature differences remained are:
>>   - all folded lines continue of column 0 without two character
>>     indentation, i.e., whether auto indentation should be supported.
>
> I really liked the flexible indentation in the other draft.  I suggest
> it is added to this draft.  It enhances readability (if the author
> wants it).

Variable indentation, when the folded-line starts on same column as
the previous line, looks nice.  The current yang-xml-doc-conventions
draft has a fixed two-space indent, which would only look nice sometimes 
while introducing a surprise factor other times.

Variable indent introduces significant complexity; at least, it's beyond
what can be accomplished by a `sed` one-liner, such as in the current 
draft.  A fixed two-space indent is possible (easy), but zero-space 
indent is more common (less surprising) than a fixed indent.



>>   - handle two special case on backslash and space at the end of broken
>>     line in yang-xml-doc-conventions.
>>   - propose to use <WRAPPED TEXT BEGIN><WRAPPED TEXT END> to extract
>>     artwork from I-Ds.
>
> The artwork draft proposes only a header, which means that it is not
> quite clear where the artwork ends.

Interesting point, but I think that artwork-framing is a different problem
from artwork-folding.  If the goal is to support extracting artwork from
txt-based RFC scripts, regardless if the artwork is folded or not, then we
could level-up this draft to that role, while still supporting folding.

If we were to add a footer, maybe something like this:

  ===padding=== End Folding per BCP XX (RFC XXXX) ===padding===

where the "padding" fills in '=' characters until the max-line width is
reached (same as how the header is done).



>> In the artwork draft, section 5.3, you write:
>>
>>   This line is self-describing in
>>   three ways: use of '\' character, identification of BCP/RFC, and
>>   identification of what the maximum line length is for the artwork.
>>
> I was confused about this maximum line length; it seems you define the
> maximum line length ot be 53, but that seems too limiting, and indeed
> in the example in 5.4 the max line length is 69.  (BTW, the example is
> missing in the draft, as is the shell script in Appendix A).   In any
> case, I don't see how the header identifies the max line length.

The draft says that the *minimal* header string is 53-characters).  We
can make it less if needed, but it involves needing to fold the header
itself, which could become messy.  Thoughts?

Per the line just before the one quoted above, this line is '=' padded
on both sides until reaching the max value.  Apparently, this isn't 
clear enough in the text, or do you think it's okay now?

For what it's worth, I originally had the actually fold-column 
(e.g., 69) printed in the header, but it was realized that it was 
noise to the reader (humans don't care about the fold column number),
whereas padding the line out provides visually meaningful information
(e.g., one can hover the cursor over the end and then scroll the
document to find all the folds).



> Also, in section 5.2, the first sentence is:
>
>  Scan the artwork to see if any line exceeds the desired maximum.
>
> But what is the desired maximum?   I assume that the idea is that the
> author first selects a desired max?  Maybe add a line that explains
> this, and again write that 69 is a reasonable value for use in I-Ds
> and RFCs.

Right, the idea is that the author has a target fold-column in mind.
It's an input parameter to the script in the appendix.  The max value
defaults to 69.

I added the following sentence before the "scan" line above:

   Determine the desired maximum line length from input.  If no
   value is explicitly specified, the value "69" SHOULD be used.



> /martin

Kent // contributor