Re: [Teas] First version merged slicing draft [Was: I-D Action: draft-ietf-teas-ietf-network-slices-00.txt]

Eric Gray <ewgray2k@gmail.com> Fri, 16 April 2021 17:33 UTC

Return-Path: <ewgray2k@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7050B3A2D8B for <teas@ietfa.amsl.com>; Fri, 16 Apr 2021 10:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 B1Tz3gb_Kxlp for <teas@ietfa.amsl.com>; Fri, 16 Apr 2021 10:32:59 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB033A2D82 for <teas@ietf.org>; Fri, 16 Apr 2021 10:32:59 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id d1so2249328qvy.11 for <teas@ietf.org>; Fri, 16 Apr 2021 10:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2QH4Te229JybPHLdv9Y8T9bUetnI5QeQTTZ0VDAZ7GM=; b=M49By0j7g5n4ljKpb3akw+DdLFuOCqEn7CWYExwGS6AU2ch5ODsHC5E2EOB1py15Aq ezdFQL/5BOBJ/uFGYG6QfnyFkd+hi1lfP9VVeWSpxSzUiR/zlhpSJtZ4MVdBffLvbmo2 btKU7wbImz6t4qFub+Pv9BdZiezm1Cco66DLPhQN63oHDWveY5sM6qp0Kf3mKbat0/1O Uy8BRtVfi6nZuVWKGaHVkyzT2C4jqrWlvcxCA3Ffvbp3rEvQa01qRSFkCAo/GtjnISSm 3IDFjkbQDDqUs6uwLGniCE2jOxGlDdaGRv42eReV0cZfK5QQwksDbIYF5A1mQDBacFf+ hkUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2QH4Te229JybPHLdv9Y8T9bUetnI5QeQTTZ0VDAZ7GM=; b=hlhMC5LB9SdyU8La/pL9N1kaMagh970Oww5w0ONH1q53DGejLhEFoGOiT49ZZU9xSq ajzd5G4AEzpRj5RO/IAmk3OXVhpDv57998S9E3syIcDhRzsvIFFekZOMZWyV311GPx2e ZltsdHTs4hak3MmroXLt100Etdhu2yGJ41zh8uc1EjzNG9tAsNQYH0LzGFSwbjQG/dW6 YvEBvjP6f9/HPu8tzsxg10+C1/RWzNelLxI6LYWw4a4EN001Hq/BXt7hH4cHLgBurLd1 4bKuix9c+A3QI20yHD7tAJnVVw3XuBfDXzDOvgK/F2MjpI3qY26omUZCKj2fuMQ47gWK eUkg==
X-Gm-Message-State: AOAM532DYWQF2gIPeJdAmXOR1CwbUDay7NIoWGzyycRWx66Syw31wfC4 7MzS0HZBMUnkuNRBDJF3Bxff0Nxro8faqg==
X-Google-Smtp-Source: ABdhPJxXz1en+9LBDsesZ98UtmvdZnp3BFbEzU4wj7Mle10ipEXRVNm6IVGcJQM/PrzgjwWmzpbV1g==
X-Received: by 2002:ad4:50d0:: with SMTP id e16mr9581594qvq.6.1618594378165; Fri, 16 Apr 2021 10:32:58 -0700 (PDT)
Received: from ?IPv6:2601:85:4680:3329:6c2f:c749:8687:a4b2? ([2601:85:4680:3329:6c2f:c749:8687:a4b2]) by smtp.gmail.com with ESMTPSA id g128sm4647197qke.1.2021.04.16.10.32.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Apr 2021 10:32:57 -0700 (PDT)
From: Eric Gray <ewgray2k@gmail.com>
Message-Id: <586D83EF-ADAA-4023-B1A6-4EE876EF0BAA@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_98598410-1658-4998-9B02-49DD8EE63E78"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 16 Apr 2021 13:32:56 -0400
In-Reply-To: <001d01d731db$e8c59260$ba50b720$@olddog.co.uk>
Cc: teas@ietf.org
To: Adrian Farrel <adrian@olddog.co.uk>
References: <001d01d731db$e8c59260$ba50b720$@olddog.co.uk>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8J4FuqSsZ5HVMYKb4Bbl0hUZkgs>
Subject: Re: [Teas] First version merged slicing draft [Was: I-D Action: draft-ietf-teas-ietf-network-slices-00.txt]
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2021 17:33:05 -0000

Hello, Adrian.

Nice work.

As requested, I will reserve comments on the technical content.

A few comments with respect to the editorial process, thus far:

1) You seem to have included “Author” information in the “Unused Material” section.  In fact that appears to be pretty much all there is in that section and - if we actually remove it (as is the expressed intent) - there will not longer be any information relating to “Authors” other than that found in the “Contributors” section.  Interestingly, the only information in this (“Unused Material”) section is the “Author Information” (I suspect - but have not actually completely verified - that this section probably was meant to contain more “stuff”).

Is it your intent to delete the section, but not necessarily the content of the “Unused Material” section?

2) There are too many Authors, for this draft version, and I believe the intention was to list many of the current “Authors” as “Contributors” (presumably adding their information to the “Contributors” section) and have a smaller number of Editors.  In writing the previous version of the Framework draft, we used the RFC Editor guidelines as to how many Authors should be included on the first page - and we will clearly need to do this again.

3) The “Contributors” section was a special concession to those folks that contributed more than enough to the draft (and now drafts) to expect to be explicitly listed as more than just acknowledged reviewers and commenters.  The intention in this respect is to be consistent with generally applicable publishing guidelines with respect to properly crediting original contributions.  It would be a good idea to bear this in mind when you determine who to acknowledge where.

4) I like how you identified where - in each of the two source documents - you pulled the current text.  However, I realized that it was possible that either you missed a few, or there are sections in one or the other source drafts that should have been included in the “Unused Material” section.

Looking at the specific “F” and “D” labels you used, what is included, and from where, looks like this:

Draft						Framework					Definition 
======						==========					=========
Abstract						Fab (Framework Abstract)		Dab (Definition Abstract)
1) Introduction					F1							D1
2)Terms & Abbreviations										D2
3) [I-NS] Objectives				F2
3.1) [Definition and Scope of [I-NS]							D3
4) [I-NS] System Characteristics 								D4
	— Similarly for subsections 4.1, 4.1.1, 4.1.2, 4.1.3, 4.2, 4.2.1, and 4.3 —
5) Framework					F3
5.1) [I-NS] Stakeholders										D6
5.2) Management […]			F3.1
5.3) Expressing […]			F3.2
5.4) [I-NS] Structure										D5
5.5) [I-NS) Controller (NSC)		F3.3
5.5.1) [I-NS] Controller Interfaces								D7
5.5.2) North Bound Interface		F3.3.1
5.6) Mapping					F3.4
5.7) Realizing [I-NS]										D8
5.7.1) Underlying Technology		F3.5
6) Applicability of ACTN to [I-NS]	F4
7) Isolation in [I-NS]										D9
7.1) Isolation as a Service [Req…]								D9.1
7.2) Isolation in [I-NS] Realization								D9.2
8) Management Considerations	F5.1
9) Security Considerations		F5.2							D10
9.1) Privacy Considerations		F5.3
10) IANA Considerations			F5.4							[D11]
11) Acknowledgements			F6							D12
12) Contributors				[F?]
13) References				(presumably these came from both source drafts)

Comparing this to the ToC for each of the source drafts, I do not see anything that has been omitted - at least at the section level.  If specific text in any of the sections was omitted, it should have been included in the “Unused Material” section, otherwise, the Author Information should have been included, the “Unused Material” section (Appendix A), and the reference to it in the Editor’s note in the Introduction, should have been omitted.

Some comments with respect to the resulting draft ToC and the sources from which it was taken:
1) I use the abbreviation “I-NS” for convenience in  these comments only - I am not suggesting its use generally.
2) Section 5.6 (“Mapping”) may require contextual clarification in the above restructuring; otherwise, the new ordering of content is mostly fine.
3) "Privacy Considerations” are _not_ a subset of “Security Considerations” (as is implied in the above numbering).  There is significant overlap, yet - contrary to intuition - it is quite possible to have a privacy violation without a concomitant security violation.  In summary, the difference is in the concept of PII (personal identifying information - which does not actually include the freight associated with the intuitive meaning of “personal”); “privacy” may be violated without direct access to security protected data and it applies not only to individual privacy but also to the privacy of classes of users.
4) you did not include D11 as a source for the content of IANA Considerations, even though it effectively was.
5) The way it was setup in the XML (and source MD) for the Framework draft, the “Contributors” section was not a numbered section, very like the Authors section (which you have currently listed as “Unused Material”).  This was (as mentioned earlier) a deliberate result of the XML2RFC tools, for which I had to ask for a tools change (which I understand has now been made part of the most up-to-date XML2RFC tools).
6) Obviously you will need to remove the previous drafts as “normative” references, since they will become “overcome by events” once this draft is setup to replace them.

NITs:
====

The abbreviation “wrt” is most likely not appropriate (spell it out - “with respect to”).

Everywhere where you currently have “a (or A) IETF …” should be changed to read “an (or An) IETF …” (the choice of indefinite article is based on how the following word would be pronounced (even if not actually being pronounced), irrespective of how it is spelled, or what it means (e.g. - if its an acronym).

I have a raft of technical comments, but will any least wait for the next version before delving into those.

—
Eric Gray
 

> On Apr 15, 2021, at 5:44 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> draft-ietf-teas-ietf-network-slices-00.txt