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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Apr 2021 10:44:18 +0100

Hi,

According to the Pledge...

Here is the -00 that just pulls in all of the text from the two contributing
documents.

My next step is to rationalise this a bit to avoid duplication and make sure
the sections are in the right order.

Comments are, of course, welcome, but maybe focus on just the editorial work
rather than the technical content (there'll be plenty of time for that
later!).

Hoping to have the -01 within a week.

Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 15 April 2021 01:29
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Traffic Engineering Architecture and
Signaling WG of the IETF.

        Title           : Framework for IETF Network Slices
        Authors         : Adrian Farrel
                          Eric Gray
                          John Drake
                          Reza Rokui
                          Shunsuke Homma
                          Kiran Makhijani
                          Luis M. Contreras
                          Jeff Tantsura
	Filename        : draft-ietf-teas-ietf-network-slices-00.txt
	Pages           : 35
	Date            : 2021-04-14

Abstract:
   <FAb>

   This memo discusses setting up special-purpose network connections
   using existing IETF technologies.  These connections are called IETF
   network slices for the purposes of this memo.  The memo discusses the
   general framework for this setup, the necessary system components and
   interfaces, and how abstract requests can be mapped to more specific
   technologies.  The memo also discusses related considerations with
   monitoring and security.

   This memo is intended for discussing interfaces and technologies.  It
   is not intended to be a new set of concrete interfaces or
   technologies.  Rather, it should be seen as an explanation of how
   some existing, concrete IETF VPN and traffic-engineering technologies
   can be used to create IETF network slices.  Note that there are a
   number of these technologies, and new technologies or capabilities
   keep being added.  This memo is also not intended presume any
   particular technology choice.

   <DAb>

   This document provides a definition of the term "IETF Network Slice"
   for use within the IETF and specifically as a reference for other
   IETF documents that describe or use aspects of network slices.

   The document also describes the characteristics of an IETF network
   slice, related terms and their meanings, and explains how IETF
   network slices can be used in combination with end-to-end network
   slices or independent of them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-ietf-network-slices-00
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Eric Gray <[email-masked]>
Date: Fri, 16 Apr 2021 13:32:56 -0400

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 <[email-masked]> wrote:
> 
> draft-ietf-teas-ietf-network-slices-00.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Apr 2021 19:50:49 +0100

Hi Eric,

Thanks for this.

Some quick answers in line…

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

Appreciate that!

> 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”).

The joys of reading I-Ds :-)

If you look at the ToC, you’ll see that the “unused stuff” is Appendix A, while the Authors are in a subsequent unnumbered section.

XML2RFC automagically puts the Authors in the last section in the document, and unnumbers it.

The Appendix is, indeed, empty in -00. Amazingly, I found a home for all of the text of both documents.

In -01, there are two small subsections of Appendix A containing text that didn’t seem valuable.

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

> Material” section?

I intend to keep Appendix A for a while. Text may be moved out of the main body and into it. That will give people an easy view of what is being removed. Then, when there is no objection to the removal, I will flush the removed material from the Appendix. And so on. Once the document is stable, the Appendix will disappear (likewise the Editor Note in the Introduction).

> 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.

At the risk of invoking Godwin’s Law, I was only obeying orders.

The chairs asked me to retain all of the front page authors from the two contributing documents.

You’re right that that is too many and we need to do something about it.

I am unsure how to reach the required “Less than or equal to five” without upsetting someone.

Hence I am appealing for people to volunteer to be moved from the front page and named as Contributors.

> 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.

Yes, that’s wise.

What I did (similar to the front page authors) was to simply merge the Contributors sections from the two contributing drafts.

Similarly, I merged the Acknowledgements sections.

Again, I would be happy to hear from any of the people who are listed as Contributors that they think they only need to be in the Acknowledgements.

> 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:

Oh, I should have made a table like this to avoid missing text. But, see your comment after the table.

> 9) Security Considerations                       F5.2                                                                   D10

Below this point, the source of the material is not important because it is non-technical.

> 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.

Hooray! Thank you for checking. Looks like I managed to do my job correctly :-)

>  If specific text in any of the sections was omitted, it should have been included in the

> “Unused Material” section

In -00 there is no omitted text (I was surprised). In -01 there is some omitted text. Later versions may have more omitted text.

> 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.

As noted above, the Authors are not omitted, it’s just a formatting quirk.

The Editor’s Note and the Appendix will evolve.

> 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.

Noted.

> 2) Section 5.6 (“Mapping”) may require contextual clarification in the above

>  restructuring; otherwise, the new ordering of content is mostly fine.

Yes, good call.

In -01 I moved that small paragraph to be the second paragraph of 5.3 (was 5.5 in -00 “IETF Network Slice Controller (NSC)”)

> 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.

I am happy to separate them into separate top-level sections. You’ll see this in -02.

> 4) you did not include D11 as a source for the content of IANA Considerations, even

> though it effectively was.

Yes, well. I get old.

> 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).

Looking at the most recently published RFCs, “Acknowledgements”, “Contributors”, and “Authors” should all be unnumbered sections at the end of the document.

I think the RFC Editor normally sorts this out, but I see no reason not to fix it. Look for it in -02.

> 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.

Yes. “Working towards”

They’ll be Informational in -02, and probably disappear soon after.

> The abbreviation “wrt” is most likely not appropriate (spell it out - “with

> respect to”).

Ack. Fixed in -01.

> Everywhere where you currently have “a (or A) IETF …” should be changed to

> read “an (or An) IETF …” 

Indeed, I think I caught all of these in -01.

> I have a raft of technical comments, but will any least wait for the next version before

> delving into those.

Looking forward to it.

Best,

Adrian

On Apr 15, 2021, at 5:44 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote: