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

[Adrian Farrel <[e-mail]>]

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