[Teas] Re: Éric Vyncke's No Objection on draft-ietf-teas-applicability-actn-slicing-07: (with COMMENT)

[[e-mail]]

Hi Eric, 

Thanks for the review; we have addressed the comments below in the latest version of the I-D:

HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-teas-applicability-actn-slicing
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-teas-applicability-actn-slicing-09

Specifically, adjusted text for: 

2.3.  Service Isolation - Further tweaking to the description of "performance isolation". 

And...

2.4.  Orchestration - Explanatory text for "statistical packet bandwidth". 

BR, Dan (on behalf of the authors). 

-----Original Message-----
From: Adrian Farrel <[e-mail]> 
Sent: 20 August 2024 11:33
To: 'Éric Vyncke' <[e-mail]>; 'The IESG' <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [Teas] Re: Éric Vyncke's No Objection on draft-ietf-teas-applicability-actn-slicing-07: (with COMMENT)

Hey Eric,
Thanks for the review.

> Thank you for the work put into this document. May I add that I was 
> impressed by the quality of the writing (it is clear, detailed, and easy to read)?

You can say that as often as you like.

> Please find below one blocking some non-blocking COMMENT points (but 
> replies would be appreciated even if only for my own education).
>
> I hope that this review helps to improve the document,

Inevitably.

> ## Many informative references to drafts
>
> There are (too?) many informative references to IETF drafts; while 
> these I-Ds are adopted by WG, I wonder whether this I-D should be 
> delayed until these informative drafts are published... This 
> suggestion is to ensure that the value of this document is not 
> compromised if the contents of these referenced drafts is heavily changed or even worse they are never published.

The I-Ds fall into two categories:
- WG YANG models that are in their final stages (post-WG last call)
- Early stage I-Ds that are cited as peripheral examples 

We already got taken to task for not making some of the references Normative, and we're sorting that out. Some of the I-Ds may become Normative, but I think that will just hold this I-D in the RFC Editor Queue for a very short while.

> ## Section 1
>
> While I know about the sensitivities around "network slice" term, this 
> section perhaps overdoes it to clarify "IETF network slices".

Well, it's hard to revise something you have written :-) Any suggested edits?

> ## Section 2.3
>
> Should packet drop be listed in the performance isolation bullet (even 
> if somehow included in congestion) ?

Yes.
OLD
   *  Performance isolation requires that service delivery for one
      network slice does not adversely impact congestion, or performance
      levels perceived by the users of other slices.
NEW
   *  Performance isolation requires that service delivery for one
      network slice does not adversely impact congestion, packet drop,
      or performance levels perceived by the users of other slices.
END

> ## Section 2.4
>
> Suggest to drop "control" from the section title.

Fair enough.

> ## Section 3
>
> A graphical description of the interactions among the components and 
> interfaces will be welcome, i.e., something similar to figure 1 of 
> section 3.3 (and aasvg would be a nice touch) ?

I don't think we need to reproduce material from RFC 8453, do we?

As to making SVGs: you make yourself sound like a young person ;-)

> Should XMI be introduced as well ?

XM is new to this document and is introduced in 3.3. We're adding to the explanation of what the XMI is in 3.3.

> What is `Statistical packet bandwidth`? Is it about average and 
> standard deviation or something similar ? I am not an expert in ACTN, 
> i.e., perhaps other readers/implementers would prefer to have a clear definition.

Yeah, we'll try to find some words.

Cheers,
Adrian