A Framework for Network Slices in Networks Built from IETF Technologies
draft-ietf-teas-ietf-network-slices-25

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-teas-ietf-network-slices and RFC 9543, changed IESG state to RFC Published)

[Ballot comment]
Thank you for improving the Security Considerations based on my DISCUSS and refining the language naming this framework.

===

** Section 4.
  IETF Network Slices are created to meet specific requirements,
  typically expressed as bandwidth, latency, latency variation, and
  other desired or required characteristics.

Given that Section 5.1.* mentions security properties as a characteristic of a slice, should security be mentioned here?

** Section 6.2 and 6.3.  This is not my area so I had trouble understanding the framing suggested in this section. 

-- I was under the impression that this text would describe how to manifest _IETF_ network slices using _IETF_ technology.  The text says “There are several IETF-defined mechanisms for expressing the need for a desired logical network.”  However, all of these examples seem hypothetical – NETCONF/RESTCONF are cited but there are no associated models; openconfig-rtgwg-gnmi-spec is an expired, un-adopted document whose details don’t seem to provide a means to express “connectivity intents” (and also not an IETF-defined mechanism); and PCEP is tangible, but I didn’t follow how the TLVs were supposed to be reused in the network slice interface?

-- How are these technologies any different than provisioning a network that isn’t a slice?  Where are the “slice-specific” requirements and needs?

-- What makes this described architecture different than a generic SDN/NVF architecture?

** Section 7.6.
  A customer may request an IETF Network Slice Service that involves a
  set of service functions (SFs)

I might be misunderstanding the level of abstraction at which the SLA/SLI/etc will describe the slice.  I thought SFC would be an implementation detail.  I didn’t see a discussion of SFC in the SLI/SLO/SLE discussion in Section 5.1. 

** Section 10.
      The nature of conformance to isolation
      requests means that it should not be possible to attack an IETF
      Network Slice Service by varying the traffic on other services or
      slices carried by the same underlay network.

I’m not able to understand the security property described by the text.  Is this text trying to say that traffic in one slice is isolated from the other and attack traffic can't move from one slice from one to the other?  That a volumetric attack in one slice can’t affect another?

[Ballot comment]
I have (reluctantly) cleared by DISCUSS about the use of the "IETF" prefix for "IETF Network Slices". I do hope the responsible AD will do as much as they can to help reduce the use of IETF prefixed terms for WG specific purposes.

[Ballot discuss]
I appreciate that this document is not a protocol specification, but a few basic security principles should be cleaned up in an abstract way in Section 10.

-- The need for a strong authentication model is noted.  However, this would need to be paired with an authorization framework too.

-- Data integrity is described as follows:

  Data Integrity of an IETF Network Slice:  A customer wanting to
  secure their data and keep it private will be responsible for
  applying appropriate security measures to their traffic and not
  depending on the network operator that provides the IETF Network
  Slice.
    ...
  It is expected that for data integrity, a customer is
  responsible for end-to-end encryption of its own traffic.

It isn’t clear to me what security property is being referenced.  The bullet is named “data integrity” but the explanation opens with a discussion on the keeping data private which is typically framed as confidentiality.

Is “end-to-end encryption” the mechanism to provide integrity?

[Ballot comment]
I share the concerns raised in the IESG discussion on how the "_IETF_" modifier to network slices could cause issues.

** Section 4.
  IETF Network Slices are created to meet specific requirements,
  typically expressed as bandwidth, latency, latency variation, and
  other desired or required characteristics.

Given that Section 5.1.* mentions security properties as a characteristic of a slice, should security be mentioned here?

** Section 6.2 and 6.3.  This is not my area so I had trouble understanding the framing suggested in this section. 

-- I was under the impression that this text would describe how to manifest _IETF_ network slices using _IETF_ technology.  The text says “There are several IETF-defined mechanisms for expressing the need for a desired logical network.”  However, all of these examples seem hypothetical – NETCONF/RESTCONF are cited but there are no associated models; openconfig-rtgwg-gnmi-spec is an expired, un-adopted document whose details don’t seem to provide a means to express “connectivity intents” (and also not an IETF-defined mechanism); and PCEP is tangible, but I didn’t follow how the TLVs were supposed to be reused in the network slice interface?

-- How are these technologies any different than provisioning a network that isn’t a slice?  Where are the “slice-specific” requirements and needs?

-- What makes this described architecture different than a generic SDN/NVF architecture?

** Section 7.6.
  A customer may request an IETF Network Slice Service that involves a
  set of service functions (SFs)

I might be misunderstanding the level of abstraction at which the SLA/SLI/etc will describe the slice.  I thought SFC would be an implementation detail.  I didn’t see a discussion of SFC in the SLI/SLO/SLE discussion in Section 5.1. 

** Section 10.
      The nature of conformance to isolation
      requests means that it should not be possible to attack an IETF
      Network Slice Service by varying the traffic on other services or
      slices carried by the same underlay network.

I’m not able to understand the security property described by the text.  Is this text trying to say that traffic in one slice is isolated from the other and attack traffic can't move from one slice from one to the other?  That a volumetric attack in one slice can’t affect another?

[Ballot discuss]
I am a bit concerned about the use of "IETF" in "IETF Network Slices", as it carries implications. I understand this was done to distinguish it from other network slices technologies. Although that point is somewhat undone by the "enhanced VPN" draft, which states: In this document (which is solely about IETF technologies) we refer to an "IETF Network Slice" simply as a "network slice".

I'm filing this as DISCUSS to ensure the IESG at least considers this in their telechat call for this document.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-teas-ietf-network-slices-22

Thank you for the work put into this document. It is clearly written and easy to read, even if it is unclear on which layer (2 or 3) the slice is, until deep in the text. I also wonder why this is called "IETF Network Slice" as if it was blessed by the IETF community beyond the consensus on this I-D; should it rather be "IETF considerations on network slices" ?

Please find below some non-blocking COMMENT points.

Special thanks to Vishnu Pavan Beeram for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-teas-ietf-network-slices-21-intdir-telechat-von-hugo-2023-07-21/ (and I have read the email thread with the WG/authors)

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS

## Authors count

This is mainly a note for the IESG as I wonder why for some WG/authors it is OK to have 7 authors and for some other WG/authors 6 is too many. IMHO, it is up to the WG to decide, hence I can only support having 7 authors on this one. I.e., no need for the authors/WG to reply.

## Section 2.3

"Customers" request a service slice but do customers also use this slice ?

Is it a common and accepted use of curled brackets in `{IETF Network Slice Service, connectivity construct, and SLOs/SLEs}` ? Honestly, I cannot understand the difference with normal parenthesis.

## Section 5.1.1.1.

Should security also be part of SLO ? It is only mentioned in section 5.1.2.1.

Is there a difference between the commonly used term of 'jitter' and the 'delay variation' ?

## Section 5.1.2.1.

Is security only limited to 'encryption' (assuming that the end-goal is actually confidentiality with encryption being one means and not then end). Should also be authentication be part of the security ?

## Section 6.1

Does an IETF network slice always require a centralised controller ? AFAICT, MPLS-VPN or EVPN are instances of IETF network slices and they usually do not require any controller.

## RFC 8799

Should RFC 8799 be mentioned in this document ?

[Ballot comment]
# Internet AD comments for draft-ietf-teas-ietf-network-slices-22
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.2.3

* This section didn't really make sense until I got to A.2/3.  Consider
  adding a forward reference (e.g., "see some examples in Appendices A.2/3")
  or something.

## Nits

### S6

* "funcitonal" -> "functional"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-teas-ietf-network-slices-21, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-07-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teas-ietf-network-slices@ietf.org, jgs@juniper.net, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Framework for IETF Network Slices) to Informational RFC


The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'A Framework for
IETF Network Slices'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-07-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes network slicing in the context of networks
  built from IETF technologies.  It defines the term "IETF Network
  Slice" and establishes the general principles of network slicing in
  the IETF context.

  The document discusses the general framework for requesting and
  operating IETF Network Slices, the characteristics of an IETF Network
  Slice, the necessary system components and interfaces, and how
  abstract requests can be mapped to more specific technologies.  The
  document also discusses related considerations with monitoring and
  security.

  This document also provides definitions of related terms to enable
  consistent usage in other IETF documents that describe or use aspects
  of IETF Network Slices.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement in the WG to progress this document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy. However, there were rough consensus calls made on
a few items after considerable amount of healthy debate and discussion in the WG.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has threatened an appeal. No one has indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document does not propose any protocol extensions. It is an informational
document that discusses the framework for requesting and operating IETF Network
Slices. There are no existing implementations of this framework reported in the
document. There are some solution documents (which are being discussed in the
WG) that adhere to the framework discussed in this document -- these solutions
are being driven by several vendors/operators and are expected to eventually get
implemented in some form.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The framework document briefly indicates some candidate technologies for
realizing IETF Network Slices, including work that is relevant to other WGs
(MPLS, SPRING, IDR, BESS, OPSAWG etc). However, there isn't enough in-depth
detail on any of these relevant technologies to warrant a review from these
other WGs.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has been reviewed by the Routing Directorate.
Please refer to https://mailarchive.ietf.org/arch/msg/teas/LtzlYf_kyzj_xM6CqMCaA5dmNUY/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no section in the document that is written in a formal language, such as
XML code, BNF rules, MIB definitions, CBOS's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, it is the shepherd's opinion that the document is much needed, very clearly
written, complete and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

It is the shepherd's opinion that the document sufficiently addresses all
the issues specified in [6].

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type of publication being requested is "Informational". This is appropriate
because it discusses a framework for requesting and operating IETF Network
Slices. All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The TEAS WG conducts an IPR poll before an individual draft becomes a WG document
and before a WG document goes to last call. The WG process requires IPR compliance
statement from all authors and contributors listed in the document. This process
was duly applied to the document. There are no IPR disclosures associated with this
document. It is to be noted that this document is a product of merging two WG
adopted documents - draft-ietf-teas-ietf-network-slice-definition and
draft-ietf-teas-ietf-network-slice-framework

Pre-WG-Adoption IPR Poll (for draft-ietf-teas-ietf-network-slice-definition):
Please refer to entry dated 2020-08-17 at
https://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/history/

Pre-WG-Adoption IPR Poll (for draft-ietf-teas-ietf-network-slice-framework):
Please refer to entry dated 2020-08-31 at
https://datatracker.ietf.org/doc/draft-nsdt-teas-ns-framework/history/

Pre-WGLC IPR Poll: Please refer to entries dated 2022-10-10 and 2022-10-21 at
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/history/

It is to be noted that we did not receive a response for the pre-WGLC IPR poll
from Eric Gray who is now retired. The draft was updated to note that Eric is
retired. There were no concerns raised about this by anyone in the WG. Please
refer to the following thread for notification on this:
https://mailarchive.ietf.org/arch/msg/teas/3dLnt33YSg8her94YNmaXOZrlOs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The authors/editors and contributors have had sufficient opportunities to express
unwillingness to be listed as such. There are 7 authors (including two editors)
listed on the front page and 6 other contributors listed later in the document.
The document is a result of merging two documents that were put together by a
large design team (appointed by WG chairs). The two documents that were
eventually merged are a result of several rounds of design team meetings with key
contributions from all those who are currently listed as authors. This justifies
the presence of a longer than usual list of authors on the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are no I-D nits that are yet to be resolved.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are no normative references listed in this document. All listed informative
references are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are no normative references listed in this document.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no normative references listed in this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are no normative references listed in this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The publication of this document will not change the status of any existing RFCs.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This draft makes no requests for IANA action.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This draft makes no requests for IANA action.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement in the WG to progress this document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy. However, there were rough consensus calls made on
a few items after considerable amount of healthy debate and discussion in the WG.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has threatened an appeal. No one has indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document does not propose any protocol extensions. It is an informational
document that discusses the framework for requesting and operating IETF Network
Slices. There are no existing implementations of this framework reported in the
document. There are some solution documents (which are being discussed in the
WG) that adhere to the framework discussed in this document -- these solutions
are being driven by several vendors/operators and are expected to eventually get
implemented in some form.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The framework document briefly indicates some candidate technologies for
realizing IETF Network Slices, including work that is relevant to other WGs
(MPLS, SPRING, IDR, BESS, OPSAWG etc). However, there isn't enough in-depth
detail on any of these relevant technologies to warrant a review from these
other WGs.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has been reviewed by the Routing Directorate.
Please refer to https://mailarchive.ietf.org/arch/msg/teas/LtzlYf_kyzj_xM6CqMCaA5dmNUY/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no section in the document that is written in a formal language, such as
XML code, BNF rules, MIB definitions, CBOS's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, it is the shepherd's opinion that the document is much needed, very clearly
written, complete and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

It is the shepherd's opinion that the document sufficiently addresses all
the issues specified in [6].

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type of publication being requested is "Informational". This is appropriate
because it discusses a framework for requesting and operating IETF Network
Slices. All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The TEAS WG conducts an IPR poll before an individual draft becomes a WG document
and before a WG document goes to last call. The WG process requires IPR compliance
statement from all authors and contributors listed in the document. This process
was duly applied to the document. There are no IPR disclosures associated with this
document. It is to be noted that this document is a product of merging two WG
adopted documents - draft-ietf-teas-ietf-network-slice-definition and
draft-ietf-teas-ietf-network-slice-framework

Pre-WG-Adoption IPR Poll (for draft-ietf-teas-ietf-network-slice-definition):
Please refer to entry dated 2020-08-17 at
https://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/history/

Pre-WG-Adoption IPR Poll (for draft-ietf-teas-ietf-network-slice-framework):
Please refer to entry dated 2020-08-31 at
https://datatracker.ietf.org/doc/draft-nsdt-teas-ns-framework/history/

Pre-WGLC IPR Poll: Please refer to entries dated 2022-10-10 and 2022-10-21 at
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/history/

It is to be noted that we did not receive a response for the pre-WGLC IPR poll
from Eric Gray who is now retired. The draft was updated to note that Eric is
retired. There were no concerns raised about this by anyone in the WG. Please
refer to the following thread for notification on this:
https://mailarchive.ietf.org/arch/msg/teas/3dLnt33YSg8her94YNmaXOZrlOs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The authors/editors and contributors have had sufficient opportunities to express
unwillingness to be listed as such. There are 7 authors (including two editors)
listed on the front page and 6 other contributors listed later in the document.
The document is a result of merging two documents that were put together by a
large design team (appointed by WG chairs). The two documents that were
eventually merged are a result of several rounds of design team meetings with key
contributions from all those who are currently listed as authors. This justifies
the presence of a longer than usual list of authors on the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are no I-D nits that are yet to be resolved.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are no normative references listed in this document. All listed informative
references are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are no normative references listed in this document.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no normative references listed in this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are no normative references listed in this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The publication of this document will not change the status of any existing RFCs.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This draft makes no requests for IANA action.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This draft makes no requests for IANA action.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Pre WGLC IPR Poll responses (First Pass):
Thread: https://mailarchive.ietf.org/arch/msg/teas/ysnNRNf_kYzdrTAV2iwPKZC5aKI/

Adrian Farrel
https://mailarchive.ietf.org/arch/msg/teas/N1aTYh4jGb3pNRDGXxrqbDhcNxg/

John E Drake
https://mailarchive.ietf.org/arch/msg/teas/v9enVjPNB_2Y613dCXjFu05MHBs/

"Rokui, Reza"
https://mailarchive.ietf.org/arch/msg/teas/s6Jx6WZwku9VGVG1LB_40LV3piA/

shunsuke.homma.ietf@gmail.com
https://mailarchive.ietf.org/arch/msg/teas/RJATkFsc75OUzVtTujyeaDhbDHo/

Kiran Makhijani
https://mailarchive.ietf.org/arch/msg/teas/8oI4NB3AA_T7p1GJ-IKzxhJQPjE/

LUIS MIGUEL CONTRERAS MURILLO
https://mailarchive.ietf.org/arch/msg/teas/UndQ73RJ-kz1UN_IMPrnoYHNrzc/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/teas/MJeGgC8wptEda0RCjGNIBjZYNIE/

ewgray@graiymage.com
[Missing]

Jari Arkko
[Missing]

mohamed.boucadair@orange.com
https://mailarchive.ietf.org/arch/msg/teas/6gIg-c6hLujH3Umbubr3X1lq4Rc/

Dhruv Dhody
https://mailarchive.ietf.org/arch/msg/teas/ov2Hgwo7-_enIG84ya9zkX-ghyA/

"Dongjie (Jimmy)"
https://mailarchive.ietf.org/arch/msg/teas/pIOh4YHtqsTt9fL4zYZ6Fe-R7fg/

Xufeng Liu
[Missing]

Request for posting confirmation emailed to previous authors: Adrian Farrel , Eric Gray , Jeff Tantsura , John Drake , Kiran Makhijani , Luis Contreras , Reza Rokui , Shunsuke Homma

Request for posting confirmation emailed to previous authors: Adrian Farrel , Eric Gray , Jeff Tantsura , John Drake , Kiran Makhijani , Luis Contreras , Reza Rokui , Shunsuke Homma