Subject: [RTG-DIR]Rtgdir last call review of draft-ietf-teas-ietf-network-slice-nbi-yang-17
From: Susan Hares via Datatracker <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 13 Jan 2025 09:14:09 -0800
List-Id: Routing Area Directorate <rtg-dir.ietf.org>

Reviewer: Susan Hares
Review result: Has Nits

Hello,

I have been selected to do a routing directorate Last Call review of this draft.

Version:draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt.
Status: Proposed Standard
Summary: Ready with editorial nits.
I agree with Ines who stated "the document is comprehensive and includes good
examples, particularly in the appendices."  The authors should be commended for
a clearly written document on this topic.

As part of the review, I reviewed the Early Reviews from RTG-DIR, Yang-DIR,
SEC-DIR, TSV-ART, and GEN-DIR. I will highlight comments in each of these
reviews that I agree with.  These comments on reviews are to highlight
my view of other reviews as a service for the RTG-AD (Jim Guichard).

The key one of the previous reviews for authors to consider is the GEN-ART
review.

After my comments on these reviews, I provide my editorial nits on -17.
All of my editorial NITS refer to English language usage (see below).

A big thanks to the authors for their hard work on this important draft.

Sue Hares

===========
Earlier RTG-DIR review
Reviewer: Alvaro Retana
Review Date: May 6, 2024
version: draft-ietf-teas-ietf-network-slice-nbi-yang-12

Sue Hares comment: I note Alvaro requested RFC5481 as normative, but I do not
see a follow-up in the email.
https://mailarchive.ietf.org/arch/msg/teas/2oK0a67X1xSWAzmMQwCUJiAODRA/ Perhaps
the authors decided it should not be normative.
-------
Yang-Doctor review:
Reviewer: Ladislav Lhotka
Intended Status: Standards track
Status: Ready with Nits
Comment: Lada commented on clarity of names.
Sue's comment: I did not find the names to be unclear.
-------
SEC-DIR review:
Reviewer: Mike Ounsworth
Version reviewed: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt.
Summary: Ready to publish
Comment: Mike felt the security consideration section was sufficient based on:
1) a secure transport protocol for NM, and
2) the authors indicating which portions of the yang model provide information
that could have privacy concerns. Sue's comment: I find no other security
concerns.
---------------
TSV-ART review
Reviewer:Kyle Rose
Version reviewed: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt.
Kyle's Comments: Kyle asks two key questions:
1) Should the Appendix Examples be validated?
2) Should this yang model be on a wiki - to have it updated?

Sue's Comment:
On 1) The appendix examples are helpful for understanding the model.
My understanding is that putting the examples in the appendix makes them
non-normative. As non-normative examples, the authors are able to give examples
that have not been deployed. If the authors wish to note whether the examples
have been tested, it might be useful.

On 2) Having worked a while with Yang models and Open-Config,
I agree with the publication and posting of this model to the Yang model
repository.

------------
GEN-ART Review
Reviewer: Ines Robles
version: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt.
Commennt: Ines brings up five points:

1- Section 4: What does "dynamic network slice" management?

2- Section 5.2.3: The draft defines precedence rules for SLO/SLE policies. It
would be helpful to explain what happens if policies conflict or are ambiguous.

3 -Section 5.2.6: In "compute-only" mode, the document mentions feasibility
checks. It would be helpful to describe what happens if the checks fail.

4- (Section 5.2.6) Does the YANG model support compute-only mode in
multi-domain setups, and if so, are there any constraints or limitations that
need to be addressed?

5- How does the model scale with an increasing number of slices or handle
frequent modifications to existing slices? It would be helpful to include a
sentence addressing this.

Sue's comment: It would be good for the authors to address these points.
My reading of section 5.2.6 for questions 3 and 4, indicates that
a) the review comes back in the status
b) It is unclear how multiple domain set-ups provide "compute-only" feedback
for portions of the model.

============
My editorial NITS

section 5.2.1 paragraph "**attachment-circuits".
Old text:/
   *  "attachment-circuits": Specifies the list of ACs by which the
      service traffic is received.  This is an optional SDP attribute.
      When an SDP has multiple ACs and some AC specific attributes are
      needed, each "attachment-circuit" can specify attributes, such as
      interface specific IP addresses, service MTU, etc./

Text to fix:
old text: /interface specific IP addresses, service MTU, etc./
New text: /interface specific IP addresses, service MTU, and other attributes./

2) Section 5.2.2, connectivity-type paragraph
Old text:/
   *  "connectivity-type": Indicates the type of the connection group,
      extending "vpn-common:vpn-topology" specified [RFC9181] with the
      NS connectivity type, e.g., P2P and P2MP./

Text to fix:/ NS connectivity type, e.g., P2P and P2MP./
New text:/ NS connectivity type, e.g., P2P or P2MP./

3) Section 6, Model, identity service

Current text:/
     identity service {
       base service-tag-type;
       description
         "The Network Slice Service tag type, which can indicate the
          technical constraints used during service realization,
          for example, Layer 2 or Layer 3 technologies.";
     }/

Fix: / technical constraints used during service realization,
       for example, Layer 2 or Layer 3 technologies.";/
New: /technical constraints used during service realization
      (for example - Layer 2 or Layer 3 technologies).";

4) Section 6 model, traffic-isolation

old text:/
     identity traffic-isolation {
       base service-isolation-type;
       description
         "Specify the requirement for separating the traffic of the
          customer's Network Slice Service from other services,
          which may be provided by the service provider using VPN
          technologies, such as L3VPN, L2VPN, EVPN, etc.";
     }
/
Fix text: / technologies, such as L3VPN, L2VPN, EVPN, etc.";/
new text: / technologies, such as L3VPN, L2VPN, EVPN, or others.";/

5. Section 6, leaf availability.

old text:/
        leaf availability {
           type identityref {
             base availability-type;
           }
           description
             "Service availability level";
         }/

fix text:/"Service availability level";/
new text:/Service availability level.";/

note: My understanding is that the Yang models require a period.
If not, yhou can skip this editorial check.

6. Model 6, container protocols

Old text:/
       container protocols {
                 description
                   "Serves as an augmentation target.
                    Protocols can be augmented into this container,
                    e.g., BGP, static routing.";
               }
       /
text to fix: /e.g., BGP, static routing.";/
New text: /   e.g., BGP or static routing.";/