A YANG Data Model for the RFC 9543 Network Slice Service
draft-ietf-teas-ietf-network-slice-nbi-yang-25

Many thanks to Mike Ounsworth for his secdir review.

I have one small comment: 

Section 7, para 2:  Please replace the last sentence with "The YANG-based management protocols have to use a secure transport layer such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000].  The YANG-based management protocols also have to use mutual authentication." [note:  this change will eventually be in the template.]

# Internet AD comments for draft-ietf-teas-ietf-network-slice-nbi-yang-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

### S6

* If wanted to have a service that was matching on a specific SVLAN + CVLAN
  combination (not just every SVLAN with CVLAN == <value>), would I use
  both `cvlan-id` and `svlan-id` in the list?

Thanks for providing a list of common acronyms!

I have some minor comments from reading the current version:

The text says: “When an IETF Network Slice spans multiple administrative domains, the
   'test-only' mode relies on the NSC to aggregate and validate
   information across these domains.” 
-  Is this the term defined in RFC 9543? (Maybe a specific reference here could be helpful?).

A few NiTs:
/in[I-D.ietf-teas-actn-vn-yang]/  (there is a missing space before the reference).
/but an example could be it is the management interface of the device./but, for example, this could be the management interface of the device./

- In just a few places you use the word “we”, which might be better reworded to avoid any suggestion this is a personal view of the editor, e.g., / In this document, we simply use the term "Network Slice Service" to refer to this concept./ Thus document uses the term "Network Slice Service" to refer to this concept./
/In other examples, we may choose to eliminate it.  /In other examples, this term is eliminated./
/We are introducing the "peer-sap-id" in this example, /This example introduces the "peer-sap-id”/

Thanks to the authors for responding to my comments with clarifications. They are all fully addressed.

Thanks to the WG for this good work.

Section 3, paragraph 5
>    An example of Network Slice Services that contains multiple
>    connectivity constructs is shown in Figure 2.

More of a nit, but since it seems to repeat itself, I would suggest that the document agree on all references to Connectivity Construct and be consistent. I see "Connectivity construct", "connectivity construct", and what I would prefer, "Connectivity Construct" or just "CC". Would suggest putting CC in the terminology section also.

Section 6, paragraph 61
>      typedef percentage {
>        type decimal64 {
>          fraction-digits 5;
>          range "0..100";
>        }
>        description
>          "Percentage to 5 decimal places.";
>      }

Curious to know whether there is a requirement to measure bandwidth down to a percentage value to 5 decimal places? Suffice it to say that this is the first time I am seeing percentage calculation to that precision.

Section 6, paragraph 67
>          leaf-list security {
>            type identityref {
>              base service-security-type;
>            }
>            description
>              "The security functions that the customer requests
>               the operator to apply to traffic between the two SDPs.";
>          }

Why is this a leaf-list? How would one implement more than one security between two SDPs at the same time?

Section 6, paragraph 72
>              leaf ce-mode {
>                type boolean;
>                description
>                  "Indicates that SDP is on the CE.";
>              }

As what? Meaning, does it mean CE when it is set to 'true'? It would help to say that.

Section 6, paragraph 71
>                  leaf ac-ipv4-prefix-length {
>                    type uint8;
>                    description
>                      "The IPv4 subnet prefix length expressed in bits.";
>                  }
>                  leaf ac-ipv6-address {
>                    type inet:ipv6-address;
>                    description
>                      "The IPv6 address of the AC.";
>                  }
>                  leaf ac-ipv6-prefix-length {
>                    type uint8;
>                    description
>                      "The IPv6 subnet prefix length expressed in bits.";
>                  }

Is there a reason why the 'ip-prefix' definition in RFC 6991 cannot be used instead of defining a prefix for IPv4, and one for IPv6?

Section 6, paragraph 70
>              container sdp-monitoring {
>                config false;
>                description
>                  "Container for SDP monitoring metrics.";
>                leaf incoming-bw-value {
>                  type yang:gauge64;
>                  units "bps";
>                  description
>                    "Indicates the absolute value of the incoming
>                     bandwidth at an SDP from the customer network or
>                     from another provider's network.";
>                }
>                leaf incoming-bw-percent {
>                  type percentage;
>                  units "percent";
>                  description
>                    "Indicates a percentage of the incoming bandwidth
>                     at an SDP from the customer network or
>                     from another provider's network.";
>                }
>                leaf outgoing-bw-value {
>                  type yang:gauge64;
>                  units "bps";
>                  description
>                    "Indicates the absolute value of the outgoing
>                     bandwidth at an SDP towards the customer network or
>                     towards another provider's network.";
>                }
>                leaf outgoing-bw-percent {
>                  type percentage;
>                  units "percent";
>                  description
>                    "Indicates a percentage of the outgoing bandwidth
>                     at an SDP towards the customer network or towards
>                     another provider's network.";
>                }
>              }
>            }
>          }

Is there other monitoring information that this model could expose? For example, you are applying QoS on the input and output. What about packets that are dropped because of the QoS policy applied on the input or output?

"B.1.", paragraph 8
>    Figure 20 shows an example YANG JSON data for the body of the Network
>    Slice Service instances request.

These examples are not tagged with <CODE BEGIN> and <CODE ENDS> tags to enable them to be extracted. Can these examples be tagged? I was hoping to verify these examples against the model.

DOWNREF [RFC9543] from this Proposed Standard to Informational RFC9543. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

DOWNREF [I-D.ietf-teas-rfc8776-update] from this Proposed Standard to
draft-ietf-teas-RFC8776-update of unknown standards level. (For IESG
discussion. It seems this DOWNREF was not mentioned in the Last Call and also
seems to not appear in the DOWNREF registry.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "natively"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 5
>      CC: Connectivity construct

s/Connectivity construct/Connectivity Construct/

Section 3, paragraph 4
>    ----: Represents connectivity construct

s/connectivity construct/Connectivity Construct/

Section 2, paragraph 1
> 543]. * Customer Higher-level Operation System: See Section 6.3.1 of [RFC954
>                               ^^^^^^^^^^^^^^^^
The word "operation" doesn't fit in this context. Would it be better to say "Management System"?

Section 4, paragraph 1
> y the customer's higher level operation system to communicate with an NSC fo
>                               ^^^^^^^^^^^^^^^^
The word "operation" doesn't fit in this context. Same suggestion as above for this and more occurances in the document.

Section 5.2, paragraph 4
>  the Network Slice Service. * "geo-location": Indicates SDP location informa
>                                ^^^^^^^^^^^^
This word is normally spelled as one.

Section 6, paragraph 3
> n the bandwidth that can be shared amongst a group of connectivity constructs
>                                    ^^^^^^^
Do not mix variants of the same word ("amongst" and "among") within a single
text.

Section 6, paragraph 24
> ement, if the percentile is set to 95.000 and the 95th percentile one-way de
>                                    ^^^^^^
In English-speaking countries, the correct thousands separator is a comma.

"B.3.", paragraph 7
> o specify a specific SDP belonging to an Network Slice Service. Authors' Addr
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

The list of acronyms is useful, but several of these are domain-specific terms for which the expansion doesn't necessarily help an unfamiliar reader. I wonder if any of these could be augmented with definitions and/or references. Perhaps the list could even be combined with the Terminology section, defining each term and providing an abbreviation where one is commonly used.

The term "IETF Network Slice" (as opposed to "Network Slice" or "RFC 9543 Network Slice") occurs only once in the document other than in the title of draft-ietf-teas-ietf-network-slice-use-cases. I'm unclear what value using "IETF" as a modifier brings here.

Note that the title, abstract and introduction talk about "RFC 9543 Network Slice Service" but the Security Considerations talk about ietf-network-slice-service. Would it make sense to explain somewhere at the top that an "RFC 9543 Network Slice Service" is the same as an "IETF Network Slice Service" ?

Thank you Ines Robles for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-teas-ietf-network-slice-nbi-yang-23
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Vishnu Pavan Beeram for the shepherd's write-up including the WG consensus even if the justification of the intended status is rather light.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### IPR on a YANG data model ?

I am just curious and there is no need to reply, but what kind of IPR can be applied to a data model ? Or is about a service ?

### Section 5.1

The model always ties one SLO and one SLE, wouldn't separate templates for SLO & SLE be more granular and more flexible ? E.g., having a SLE template applicable to multiple slices ? or having a SLO without any SLE ? I note that section 5.2.3 has separate data nodes for SLE & SLO.

Should the examples include path-constraints per the tree above ? (I am not a YANG expert though)

"bound" is uint64, i.e., no decimals ? Is it on purpose ?

### Section 5.2

A tree view of the "slice-service" would probably help the reader.

### Section 5.2.1

As figure 7 contains `rw sdp-ip-address*` I would assume that there can be multiple IP addresses so the sentence `The SDP IP address` should include a plural form.

Figure 9 and text, should 'dscp' be all uppercase character (of course the node itself should be lowercase) ?

### Section 6

Thank you for the dual-stack examples for source/destination-ip-prefix :-)

leaf ac-ipv4-prefix-length and leaf ac-ipv6-prefix-length: should there be a range of the values ?

### Section 11.2

Should the IEEE references use a more recent version than 2005 ?

## NITS (non-blocking / cosmetic)

### Section 6

s/Layer 2 or Layer 3/layer-2 or layer-3/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)