Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
Kent Watsen <kwatsen@juniper.net> Wed, 27 June 2018 17:16 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 1D4F6124D68 for <netmod@ietfa.amsl.com>; Wed, 27 Jun 2018 10:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 QsC8qvLkddKC for <netmod@ietfa.amsl.com>; Wed, 27 Jun 2018 10:16:25 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 86A9D130E04 for <netmod@ietf.org>; Wed, 27 Jun 2018 10:16:25 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5RHGLB6004186; Wed, 27 Jun 2018 10:16:21 -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=0/V5yVAV4NYrxld24NGm1tN6UinvdbC4FAcsjD8BkKY=; b=rsM1hxntqot+e0EWmpFrBfnrE4/7WuWFu55s9bgAZl2e44SryH1/4BDRuhJDxf+fhz3A A2cdeHsn2Sad89VN0iOpCJAcafJXgMpv63frsF3SjQqemzC4RW/J5AMLIYpVSFda1MQn EF1C9NsoM5elhokKfo3OVn5dgA+LZ8+8n2a4IqXxed3o4zcsG8lzyO2PEkW179c+m/RB +7LxvJ40ON9oDWWPCEZNSN6ehQ55rOOaLyx4PDCvBhICkGw0nyZowaQfV+OgfWaifHEN 2tUwjtUSzGBoIh0FSqcXThG47+9SpEx5eAeX4QcQJH0yUgjFlLbmpdbcCrdxRmh1UTwW hA==
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) by mx0a-00273201.pphosted.com with ESMTP id 2jv7sy8uu1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 10:16:21 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4198.namprd05.prod.outlook.com (52.135.200.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.14; Wed, 27 Jun 2018 17:15:46 +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; Wed, 27 Jun 2018 17:15:46 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "bill.wu@huawei.com" <bill.wu@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
Thread-Index: AQHUCpK0us9UwwoDtU2EaBoFZiTowKRyWwQAgAAxxwCAAF1MgP//xKAAgABO74CAAR8egA==
Date: Wed, 27 Jun 2018 17:15:46 +0000
Message-ID: <E777E7B0-5A9C-4397-83D4-DBA2BA8510AD@juniper.net>
References: <34C78C9F-57A9-4234-8F30-39F69F0B2F04@juniper.net> <20180626.205807.1642470222068426969.mbj@tail-f.com> <21CFADF6-9FB8-4B0B-A7FC-517FDDAF6F8C@juniper.net> <20180626.220807.1407068226011761897.mbj@tail-f.com>
In-Reply-To: <20180626.220807.1407068226011761897.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; BYAPR05MB4198; 7:9t+wpEKeUQEw6eMuvXzx+Ruwp1G5sqQyFcCsuIp8Ng+puI5Xq2xCaC1ejCbOW0TwLrjZ7fjIV0Yxh/M7fLmkh+qpoQGj25xIsNxAfbgvE9pT/xYBhC+Ryv/CSbWVht64zNMJz6JaksdN8qO9lyoQLC9WsolTDdo9gjmCA7o1Vg10ljQYWqURX59spUAhjpcS1xK42tioQnWjTdAjeoB13UEim2zRv6M82pG+YU1sm1BLqNyId32GgUSCRtK73q2Q
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f6ab447b-77f2-424c-6917-08d5dc519f48
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:BYAPR05MB4198;
x-ms-traffictypediagnostic: BYAPR05MB4198:
x-microsoft-antispam-prvs: <BYAPR05MB41983CFC49A95B229160F668A5480@BYAPR05MB4198.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4198; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4198;
x-forefront-prvs: 0716E70AB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(376002)(39860400002)(346002)(51444003)(199004)(189003)(106356001)(36756003)(99286004)(58126008)(478600001)(93886005)(66066001)(4326008)(54906003)(33656002)(6436002)(14454004)(105586002)(53936002)(6246003)(25786009)(316002)(256004)(83716003)(305945005)(2900100001)(68736007)(7736002)(229853002)(82746002)(2906002)(26005)(6116002)(5250100002)(5660300001)(6916009)(102836004)(6506007)(97736004)(86362001)(76176011)(186003)(446003)(486006)(476003)(81156014)(14444005)(6486002)(11346002)(6512007)(8936002)(8676002)(2616005)(3846002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4198; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: AmK7a6s4HLahDe+tRrVehoAIST/rfMobRJmupugPOjGy1mAvPo5QfCq/tZChg7qOL83NtmsCRnM4T1IEbtYldfS16X6xKqIIgsX4rTyVNimahbI51IPF4vJtfNWrTJgGuo+p1Zk8G0SA2a/S8oELqKYO6rvsAQdzdjpNkrmclPMmfUNM5WSGVnEnrdB0NQ/lC3GzFOk+88qJW8dSy3L7YuKQVloWJ6QrbfapfzWxAvjb7/gPbbCk26Jh53PgCIsB57HPCEzqldt5J/WmqDklyvGZkeMNy4meGSX+PkgnFs6Qu7uG7c/qAh2/9FmqCm7eSozIUIEdYoANN5lhLtJNV8UmUEIOZpTcdb46EOpV/3Y=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <93FE8D201D2A4844A31D44DBDC1289D1@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f6ab447b-77f2-424c-6917-08d5dc519f48
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2018 17:15:46.4597 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4198
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_04:, , 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-1806270185
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/q1oYLpSiwGxdU2unLm4DGU-acdE>
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: Wed, 27 Jun 2018 17:16:29 -0000
>> Those are torture tests, but they due illustrate the one case where having >> the '\\n' on the fold column would've been illegal input (and hence the '\' >> was replaced with a 'x'). Great for internal algorithm validation, but >> perhaps unnecessary for the example in the text. Or maybe enhance the >> comments above these lines to explain why they're there? > > I suggest you remove this. Okay. >> > I like the algorithm in the other draft better - it had variable >> > placement of the line break ("\\n" sequence), and variable >> > indentation. >> >> How can you automated variable placement of the line-break, assuming no >> awareness of the file format? Additionally, be aware that variable '\n' >> placement would necessitate pre-scanning the file to ensure *no* line >> ends in a '\\n', as opposed to just the lines that need folding. > > I envision this format being used not just by a program, but also by > humans trying to construct nice looking examples. I really hope humans don't try to do this manually, as the results are error-prone, and it isn't consistent with the goal of integrating validation in the build scripts that compile the drafts, for which automated-folding is needed (see section 3.1). I'm not saying that manual-folding shouldn't be possible, I'm saying that it is ill-advised, and we shouldn't go out of our way to support it. I do not support variable placement of the line-break. [Note: indentation of the beginning of the line is a different issue, and one that I actually support, assuming it is easily automatable] > Also, I would prefer a description of the format, rather than of one > algorithm that produces the format. Okay, we will look into it. >> >> >> - 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). >> > >> > Ok. >> >> I assume that you're okay-ing the proposed footer, but the real question is >> if we should expand the scope of this draft to include artwork-framing also? > > I think I would prefer if there is also a footer. Why? Do you propose the same for all artwork, regardless if it's been folded or not? To me, these are different issues. >> >> >> 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? >> > >> > The draft says: >> > >> > The header is two lines long. >> > >> > The first line is the following 53-character string >> > >> > This is what made me confused. I now understand that the idea is to pad >> > with '='. >> >> Right, the full sentence is: >> >> The first line is the following 53-character string that has been >> padded with roughly equal numbers of equal ('=') characters to reach >> the artwork's maximum line length. >> >> So, leave as is for now? > > Well ... I don't think this text is even correct... The section > describes the header with the first line being 53 characters. But > that is just an example. Maybe: > > The first line is an N-character string on the following form: > > === NOTE: '\' line wrapping per BCP XX (RFC XXXX) === > > where N is the artwork's maximum length (the minimum length is > 53). The string is padded with roughly equal numbers of equal > ('=') characters in the beginning and end to reach the artwork's > maximum line length. Yes, this is better > ... but as I wrote, I'd prefer a variable-length format. Understood, being discussed above. > /martin Kent // contributor
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… joel jaeggli
- [netmod] Call for adoption request of draft-kwats… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Bob Harold
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund