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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Adrian and Dan,

Thanks for the quick reply :-)

Noted the changes done by Dan on the I-D.

About Adrian’s comments see in-line for EVY>

Regards

-éric

From: Adrian Farrel <[e-mail]>
Date: Tuesday, 20 August 2024 at 12:33
To: Eric Vyncke (evyncke) <[e-mail]>, 'The IESG' <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: 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.

EVY> making some I-D normative will of course force some delay but will ensure that the references are published documents. OTOH, why putting them normative if they are not really normative ?
EVY> I.e., probably too late now, but it may have been better to delay this I-D until most I-Ds are at least in WGLC. A note to the RFC Editor could possibly be used, i.e., suggesting to wait until those I-D are approved or make a cluster of the documents (even if not normative). Just a suggestion.

> ## 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?

EVY> no need indeed, but this would help the reader

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

EVY> am I not ? ;-)

EVY> more seriously, give AASVG a try, especially if using Markdown for the I-D, it is really impressive

> 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