Re: [Teas-ns-dt] Tools to compile the framework draft

Eric Gray <eric.gray@ericsson.com> Wed, 05 February 2020 21:24 UTC

Return-Path: <eric.gray@ericsson.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 71F9912083C for <teas-ns-dt@ietfa.amsl.com>; Wed, 5 Feb 2020 13:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 R9k2v1i9XylE for <teas-ns-dt@ietfa.amsl.com>; Wed, 5 Feb 2020 13:24:10 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770055.outbound.protection.outlook.com [40.107.77.55]) (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 E95A01200A4 for <teas-ns-dt@ietf.org>; Wed, 5 Feb 2020 13:24:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G5+CvB5H1C/GMHpQ6/1dReuVTrzVxc56eJQsUay7cmYcmKhuagMKgs95vMzueIDRv0lxIxN/FPdxjmPXCFtaduA8OTYCCJVDPo3P01JplZexMp/1M/z0xiF4ouAvq5RmRr4t4Y2p+u+nJqgMpcgbvriR4dxznMTrQpzszSmq/sdlXSNhChFwxWp+FxZfcyrqFvedDbsm8nzDKr0fB4CawhOFYe763h9ZKBQ1nWA79sYew0P74WOSHU6KX18ilq7WEwgDxCw19rq0ILfKah5UnWDwjTUKehAga/1cOw+ug+5CTDCzud/3nr4hLkGbAuVTQi5UxO2OkxlPvYrjvHXbgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jF/5g16+iupfDdeUWvCHer2azzzwor8a7yUcf5JZ+7o=; b=By5XltWS03Rr/GT0UeXnfxJEXoxHaYVRpY6q6wcabx6CC9yFMqTdYr0mlRFhDfzR2UYVjf9aqXEcgGMAfnXrpTqgQSsPAJlLu4Vf4lssY8+PUK75dvMCFQU3Z9XeNCOty/zbOE9quh7/BzBziwNMknk7GV89WEr7F6ge6xgRK1Pr2uiT4GclPoZdc73TR9kSoHkv0t/RUoVqo5sU0KB7LTKb3M475rxJlZMsSeO1Sa+zlmLBKm6CdrQqCN2+uJW2uvfrXeiyvnHmef9i9ZllAZkaJLyU5onqUHWEDUvmycezvH9Pcah/qoVaYHtQ/CKehvBRLTrrXEfwz1YX+ZA5aw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jF/5g16+iupfDdeUWvCHer2azzzwor8a7yUcf5JZ+7o=; b=ezxevpUzhb/dxkWWKwkRzfvRdSbPZCqun02Ya51wi0St8VVxPpOGZYOUTjSX/pOdJHVW/llpIYnCyAqOO0eJGd/jTuGVRYCsvAtgg5jHg6bNe6GfzSpVoR5lEIh/Sl3XP3j3J9MryhOSD0XnTfUT9L0dQ28MGgUaApxWtGq1pIQ=
Received: from BN8PR15MB2644.namprd15.prod.outlook.com (20.179.138.27) by BN8PR15MB2787.namprd15.prod.outlook.com (20.179.139.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 5 Feb 2020 21:24:06 +0000
Received: from BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::ccb:1069:7649:5349]) by BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::ccb:1069:7649:5349%4]) with mapi id 15.20.2686.035; Wed, 5 Feb 2020 21:24:06 +0000
From: Eric Gray <eric.gray@ericsson.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.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>
Thread-Topic: Tools to compile the framework draft
Thread-Index: AQHV2tmHgoMRHYJmwkGIPcrEKsridagL4exQgACx6CCAABEcUIAAI4UA
Date: Wed, 5 Feb 2020 21:24:06 +0000
Message-ID: <BN8PR15MB2644100DBAB3CC3B930A78FD97020@BN8PR15MB2644.namprd15.prod.outlook.com>
References: <0334D928-B9A9-4F58-AA85-B60085ADEB6E@ericsson.com> <d152b1cb05a14728a8cc11450e06dd9f@huawei.com> <BN8PR15MB264451B06BBEB6AD0C523ABA97020@BN8PR15MB2644.namprd15.prod.outlook.com> <f5aab585ca36478ca247b17af46365db@huawei.com>
In-Reply-To: <f5aab585ca36478ca247b17af46365db@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.gray@ericsson.com;
x-originating-ip: [73.248.143.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b6292ebd-540b-43b9-bc9a-08d7aa81bb69
x-ms-traffictypediagnostic: BN8PR15MB2787:
x-microsoft-antispam-prvs: <BN8PR15MB2787EA177594F0D41C2B6FF897020@BN8PR15MB2787.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0304E36CA3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(366004)(39860400002)(376002)(136003)(189003)(199004)(26005)(8676002)(86362001)(81166006)(81156014)(186003)(966005)(44832011)(53546011)(6506007)(71200400001)(2906002)(8936002)(76116006)(478600001)(110136005)(66574012)(9686003)(7696005)(52536014)(316002)(55016002)(66556008)(33656002)(66946007)(64756008)(5660300002)(66476007)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2787; H:BN8PR15MB2644.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MzDEmns9nK/KAesmakqbwhzYVoFy1rwDfZgsLpKERT6kTPfYDcB1VJEig6CcDk5x8XjmelUbtXt/sYbE+WW/WBi7PYwp3Ifgyt9EIzsYEcen2Dtt1OF180M0ch6obWuEp8qSjq4/lhhts5ULFDzW4DX29IKxVHKgIBW5KH7abXDXmMmxZq7XT8f/fpS+jXPHb0dwvt79X6XBHbeW2v0rl0/Dr+3WP9E+oRAYyKDXgQcNembMFxAwiL8p5GXIbq1Sz84HKCtr82pvq/ZJnrwb+dXOu/IzKINZ13OaGRw+D0QxeioJ1dN+2s5+6QIrXJHu+mj9iefNnqKE1H71Rr7bAmPvTWL6YzqMxIK/g59JFJ6Y2LS4N6KUrAwETTYRl6o96SOQo8JKVOr0Y2aZePT8Ei6u6Vvp70aUCfan6+LWCZl6Lwk4LBr06qmY7eQafESmoz7wTPOOUR+R/DGxpL9eeMuG0ZXroOqIWpEE0A7bWK+R0aRsCvQFqn3HmDdpcYUTPQFBfdOr3kbXuh1ulTBMbA==
x-ms-exchange-antispam-messagedata: mEQ/eploC/gv9i+aN7gWmjN9CqZKZPWpBOVjSuNcJo/v+P9v580UztBregfoJ18CublNNh+OMlE2ZAT6Bmo6tcmylKYE/vL9uEZHP6qbUkA3+V3N9XQoFriSwejnMQC2aAkEwm5dFQuCmk+DiUs4sQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR15MB2644100DBAB3CC3B930A78FD97020BN8PR15MB2644namp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b6292ebd-540b-43b9-bc9a-08d7aa81bb69
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 21:24:06.6547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hzq4VaNGEJ18GnipfbTkJTTRED1kx3mqBDRaIuV6N/K8TVdhTrzfE0b8qsFfkoq0gIRiH/eWZsn3RIBVkDwaDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2787
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/U9popyOnljwFTasPYKQK-nOtnEs>
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: Wed, 05 Feb 2020 21:24:13 -0000

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> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, February 5, 2020 10:25 AM
To: 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: [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