Re: [Teas-ns-dt] Tools to compile the framework draft
"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 06 February 2020 09:21 UTC
Return-Path: <jie.dong@huawei.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id D5B0712024E;
Thu, 6 Feb 2020 01:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1,
RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=unavailable autolearn_force=no
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 8-hYE_vSsVER; Thu, 6 Feb 2020 01:21:52 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210])
(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 DABFE12022D;
Thu, 6 Feb 2020 01:21:51 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107])
by Forcepoint Email with ESMTP id AE83BA1E8389BE447E59;
Thu, 6 Feb 2020 09:21:48 +0000 (GMT)
Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by
LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server
(TLS) id 14.3.408.0; Thu, 6 Feb 2020 09:21:48 +0000
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by
nkgeml703-chm.china.huawei.com (10.98.57.159) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1713.5; Thu, 6 Feb 2020 17:21:45 +0800
Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by
nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004;
Thu, 6 Feb 2020 17:21:45 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Eric Gray <eric.gray@ericsson.com>, Eric Gray
<eric.gray=40ericsson.com@dmarc.ietf.org>, Jari Arkko
<jari.arkko=40ericsson.com@dmarc.ietf.org>, "teas-ns-dt@ietf.org"
<teas-ns-dt@ietf.org>, John E Drake <jdrake@juniper.net>
CC: "draft-ietf-teas-enhanced-vpn@ietf.org"
<draft-ietf-teas-enhanced-vpn@ietf.org>
Thread-Topic: Tools to compile the framework draft
Thread-Index: AQHV2tmHgoMRHYJmwkGIPcrEKsridagL4exQgACx6CCAABEcUIAAI4UAgAEU+fA=
Date: Thu, 6 Feb 2020 09:21:45 +0000
Message-ID: <cb877ff68657455a9ce9dc424ac784c7@huawei.com>
References: <0334D928-B9A9-4F58-AA85-B60085ADEB6E@ericsson.com>
<d152b1cb05a14728a8cc11450e06dd9f@huawei.com>
<BN8PR15MB264451B06BBEB6AD0C523ABA97020@BN8PR15MB2644.namprd15.prod.outlook.com>
<f5aab585ca36478ca247b17af46365db@huawei.com>
<BN8PR15MB2644100DBAB3CC3B930A78FD97020@BN8PR15MB2644.namprd15.prod.outlook.com>
In-Reply-To: <BN8PR15MB2644100DBAB3CC3B930A78FD97020@BN8PR15MB2644.namprd15.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.182.24]
Content-Type: multipart/alternative;
boundary="_000_cb877ff68657455a9ce9dc424ac784c7huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/0u0wdpDRnAtgmCBu_2jbEi7Sgcw>
Subject: Re: [Teas-ns-dt] Tools to compile the framework draft
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 09:21:56 -0000
[CC the authors of VPN+ framework] Hi Eric, My assumption is the deign team framework would reuse or reference existing work when they are useful to avoid duplication and waste of energy. Based on the design team’s discussion, there is consensus that VPN+ framework provide useful text in several sections, some of which are directly used after small modifications, and some sections are referenced to help to provide a complete framework. Quoting from the meeting minutes of January 23: “There was discussion of how author lists and editorship will be aligned. Jari responded that first off, we need to be very clear about source of things, if text or effort from elsewhere is used, that needs to result in acknowledgements or author list entries. Secondly, the design team should have its own editor(s) as a synchronization point and we should not expand the list of editors too far.” Based on this, my request is simple: according to the amount of text reused from VPN+ framework, this needs to be reflected in the author list, if the authors of VPN+ are willing to participate in the design team work. Best regards, Jie From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, February 6, 2020 5:24 AM To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>rg>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>rg>; teas-ns-dt@ietf.org; John E Drake <jdrake@juniper.net> Subject: RE: Tools to compile the framework draft Jie, I think you are either making assumptions that are not common among the design team members, or you are working with a misunderstanding of the intent of the framework draft. There is no intention for there to be an alignment between this draft and the enhanced VPN draft. The intent is to avoid conflict or misalignment with that work – to the extent possible and compatible with the rough consensus of this (possibly over-large) design team for a transport (network) slicing framework – and to refer to the enhanced VPN draft as an example of related work. This is a (perhaps) subtle but not insignificant difference. To the extent possible, ongoing work in this framework draft must be orthogonal to the ongoing work in the enhanced VPN. See additional comments – that try to clarify this – below. From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> On Behalf Of Dongjie (Jimmy) Sent: Wednesday, February 5, 2020 10:25 AM To: Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org<mailto:eric.gray=40ericsson.com@dmarc.ietf.org>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> Subject: Re: [Teas-ns-dt] Tools to compile the framework draft Hi Eric, Please see my replies inline: From: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] On Behalf Of Eric Gray Sent: Wednesday, February 5, 2020 9:40 PM To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> Subject: Re: [Teas-ns-dt] Tools to compile the framework draft Jie, As I recall, this was suggested (I believe, by you) at one of the design team meetings. Jari had answered this suggestion by stating that we should keep the list of “Authors” to a minimum and based on direct contributions to this draft (as opposed to text “lifted” from other drafts and RFCs). [Jie] On that conference call, I volunteered to be one of the editors of the design team framework to help the alignment with the VPN+ framework. Jari said he wanted to keep the list of editors small, and I was OK with that. What I’m suggesting now is to be added as coauthor, based on the contribution to this draft. I’m not sure what you mean by “direct contribution”, to my understanding, the contribution in IETF is evaluated by the text being provided and accepted. Providing text requires more than simply pointing to text. Several people argued that we should re-use text related to (transport) network slicing from the enhanced VPN (or VPN+) draft. This is not a contribution of text any more than “that’s not correct” is a valid (or complete) comment about existing text. At a meeting a few Thursdays ago, John expressed frustration that people had apparently not read the VPN+ draft or it would be obvious that a lot of text from that draft should be used in this framework draft (and – in fact – in a lot of what we are doing in this design team). I pointed out that telling everyone to “go off and read X draft” – even for as essential a reason as to see the shape of the wheel already invented – is hardly an approach that allows for work in parallel. Having everyone do everything, step by step, is not an efficient way to divide a problem into discrete pieces that can be addressed in parallel. So, John offered to annotate the skeleton provided by Jari with specific text to be added from the VPN+ draft. He did so, and asked me to further annotate his annotations. I did so, and presented the results on the following Monday (John was unable to attend that day). John’s proposal – especially as expanded on and annotated by myself – was a “direct contribution.” I then created a branch in GitHub and made the text additions we had proposed and presented. Jari merged these changes prior to the next (Thursday) meeting. Jari’s earlier providing of a framework “skeleton” in GitHub, was obviously a “direct contribution.” In particular, there is a need to leave room for other authors and contributors to be listed. [Jie] Then what is the criteria of adding other authors or contributors? I guess it would also base on the text contribution they make. The answer to this is essentially a brief tutorial on the “inner workings” of the Internet Draft process. There is an upper limit on how many people can be listed on the front page and this has led to the need to provide “graduated authorship” for developing Internet Drafts – i.e. – “Authors”, “Editors and Contributors”, (possibly) “Authors and Contributors”, and (sometimes) “Editors, Authors and Contributors.” Because of the size of the current design team, we will very likely end up with “Editors” and “Contributors.” Because the distinction between an “author” and a “contributor” is a somewhat arbitrary one, we should probably stick with “contributors”, unless and until the level of “contribution” rises to the point where the contributor should be acknowledged as an “author.” What level this occurs at is a judgement call. And it is easier to add people to any list than it is to take them away. As a sort of reference, I am pretty sure all of us have seen somewhat lengthy trade journal publications with one or more editors and a list of contributors, where each “contribution” may be a reasonably lengthy paper that could have been published on its own. See above for what constitutes a text contribution. Before we are done, we will obviously need to ensure that we have properly attributed all sources of text (I anticipate adding a paragraph – along with the usual “thanks for reviewing” paragraph – to the ACK section), but being an author of a draft/RFC used as a source for a subsequent draft/RFC has never been justification for being explicitly listed as an author or contributor in the latter draft/RFC. Otherwise, the list of “Authors” in any present-day draft would be very lengthy. We simply state that (some subset of the) text was taken from the earlier work. [Jie] Please note the coauthors of VPN+ framework draft are also participating in the on-going development of the design team framework, and if you remember I’ve been suggesting to reuse the VPN+ framework from the beginning of our framework discussion. The above case you mentioned usually applies when an earlier work is reused and the original authors no longer participate in the new work. Actually, it applies generally, unless the original authors have taken the extra steps of tailoring their earlier work to fit. That work was done by John and myself. Remember that every (active) participant in the design team is considered a contributor and hopefully you will also remember that several people recommended re-using text from the VPN+ draft. Note that this applies generally to any text deliberately used from any earlier work. There may be small sets of words or phrases that have been unintentionally re-used, or are required either as part of the template or RFC Editor ID requirements, that will most likely not be attributed. All of these considerations are – in part – why there is the IETF “Note Well.” The “direct” contribution in this case was from John Drake, who provided a guide to how to re-use the text from the enhanced VPN draft to fill in the skeletal draft provided by Jari. [Jie] I really appreciate the support and guide from John on the reuse of VPN+ framework, while as I mentioned the major contribution in IETF is the text. The text that John and I contributed, not the text that already existed in the VPN+ draft – which needed alteration to fit. As Jari also stated, all participants in the weekly meetings – or on the mailing list – are contributors to this work. This is justified, because there is an opportunity for those participants to comment on the drafts in progress. The same is true for the definitions draft. By the way, I am evaluating comments from at least two people (Xufeng and yourself) that were made on the mailing list for potential impact on the framework draft. Unfortunately, I am a little busy right at the moment. 😊 [Jie] Looking forward to your feedback on the comments. Still working on that. Among other things… Best regards, Jie -- Eric From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: Tuesday, February 4, 2020 9:46 PM To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; Eric Gray <eric.gray@ericsson.com<mailto:eric.gray@ericsson.com>> Subject: RE: Tools to compile the framework draft Importance: High Hi Jari, Thanks for your effort on this. I checked the current version of the framework draft, many text of VPN+ framework draft is reused in the introduction, framework and security considerations sections, this is good for the alignment between the two drafts. Then it would be reasonable to add the author of VPN+ framework draft also to the author list of this document. Thanks. Best regards, Jie From: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Tuesday, February 4, 2020 5:33 AM To: teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; Eric Gray <eric.gray@ericsson.com<mailto:eric.gray@ericsson.com>> Subject: [Teas-ns-dt] Tools to compile the framework draft I’ve finally managed to set up the framework draft compilation correctly. Struggled with some newer versions of tools. But the one I recommend and the associated makefiles work. See the readme at https://github.com/teas-wg/teas-ns-dt/tree/master/framework<https://protect2.fireeye.com/v1/url?k=dbce027c-8747d86c-dbce42e7-0cc47ad93e2a-2b5fc923eca7e3c9&q=1&e=2f9bbdce-061b-46f3-87c3-307970015ce1&u=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Ftree%2Fmaster%2Fframework> for instructions; you’ll need to install make, kramdown-rfc2629, and xml2rfc but there are instructions. Then type make and the system compiles the .md to .txt automatically. Jari
- [Teas-ns-dt] Tools to compile the framework draft Jari Arkko
- Re: [Teas-ns-dt] Tools to compile the framework d… Eric Gray
- Re: [Teas-ns-dt] Tools to compile the framework d… Eric Gray
- Re: [Teas-ns-dt] Tools to compile the framework d… Dongjie (Jimmy)
- Re: [Teas-ns-dt] Tools to compile the framework d… Eric Gray
- Re: [Teas-ns-dt] Tools to compile the framework d… Dongjie (Jimmy)
- Re: [Teas-ns-dt] Tools to compile the framework d… Eric Gray
- Re: [Teas-ns-dt] Tools to compile the framework d… Dongjie (Jimmy)
- Re: [Teas-ns-dt] Tools to compile the framework d… Jari Arkko
- Re: [Teas-ns-dt] Tools to compile the framework d… Dongjie (Jimmy)