Skip to main content

Service Assurance for Intent-Based Networking Architecture
draft-ietf-opsawg-service-assurance-architecture-13

Yes

(Robert Wilton)

No Objection

Erik Kline
Paul Wouters

Note: This ballot was opened for revision 12 and is now closed.

Erik Kline
No Objection
Murray Kucherawy
(was Discuss) No Objection
Comment (2022-12-15 for -12) Sent for earlier
Thanks to Bron Gondwana for the ARTART review, and to the authors for responding.

The following DISCUSS was resolved during the IESG telechat:

A number of the shepherd writeup questions were hastily answered and the information we need is largely missing.  For instance:

--
> What type of RFC publication is being requested on the IETF stream (Best
> Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper type
> of RFC? Do all Datatracker state attributes correctly reflect this intent?

yes.
--

There are three questions here, and only the last of them can be answered "yes".  The second one is the most interesting one.

--
> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been identified
> and addressed? For which does this still need to happen in subsequent
> reviews?

no.
--

I don't understand.

--
> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? To
> the best of your knowledge, have all required disclosures been filed? If
> not, explain why. If yes, summarize any relevant discussion, including links
> to publicly-available messages when applicable.

yes.
--

So something's been filed, or reasonable reminders were sent?  If the former, where's the discussion or what was its result?  According to the Last Call text, there was one filing.  Was it discussed?  Is it a source of concern?
Paul Wouters
No Objection
Roman Danyliw
(was Discuss) No Objection
Comment (2023-01-03) Sent for earlier
Thank you for addressing my DISCUSS and COMMENT feedback.
Warren Kumari
No Objection
Comment (2022-12-12 for -12) Sent
I'm kinda annoyed -- this is a 27 page document, but I was unable to find any issues (other than those already noted by Eric and Lars) to comment on. There were some readability nits, but even these didn't rise to a level worth commenting...

It's disheartening to read this long a document find anything to complain about...
Zaheduzzaman Sarker
No Objection
Comment (2022-12-14 for -12) Not sent
Thanks for the specification, I haven't find TSV related issues in my review.
Éric Vyncke
No Objection
Comment (2022-12-12 for -12) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-architecture-12
CC @evyncke

Thank you for the work put into this document. Very interesting and very easy to read document: congratulations !

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

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. 

Please note that Benno Overeinder is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Benno will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/

I hope that this review helps to improve the document,

Regards,

-éric

PS: thanks for listing me as contributor.

## COMMENTS

### Section 1

Please explain what the "SAIN orchestrator" is before using this concept. It would also be nice to describe what the "assurance graph" is. As I had some background information on SAIN, I was able to follow the introduction but I am unsure whether other readers will be able to understand it without reading the next section. Suggest to either reduce the section 1 (as section 3 goes in more details) or move the terminology section before the description.

Unsure whether graphs have roots ;-) in "The root of the assurance graph".

### Section 3

Should there be text on how the SAIN orchestrator generates the assurance graph before decomposing it ? I.e., a forward reference to section 3.1

Figure 1, as the text is also about VIM and NFC, should "Network System" be replaced by "System" or any generic term?

### Section 3.1

What is meant by "peer1 tunnel interface" ? Is it the egress interface used by the encapsulated packets ? Or is it the set of ingress interfaces where the to-be-encapsulated packets are received from ? (of course the same reasoning when decapsulating packets).

### Section 3.1.1

Unsure whether DAG is really a requirement (rationale will be welcome in the text), but suggest to rename the 'top' box into 'middle' (or 'synthetic') as it is not really on the top of figure 3. This would also avoid the use of "empty" box in figure 7.

### Section 3.2

Are SLO used anywhere else in the document? Else, don't introduce the acronym.

### Section 3.3

Is `a subservice also defines its assurance`correct? I would have expected `a subservice is associated to its assurance`.

### Section 3.4

What is the purpose of "global computation graph" ?

### Section 3.9

```
   The assurance graph will change over time, because services and
   subservices come and go (changing the dependencies between
   subservices), or simply because a subservice is now under
   maintenance.
```
But section 3.6 seems to indicate that maintenance is just an event/metric and does not cause a change in the assurance graph itself.


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
Robert Wilton Former IESG member
Yes
Yes (for -12) Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2022-12-12 for -12) Sent
# GEN AD review of draft-ietf-opsawg-service-assurance-architecture-12

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/-6ZNHph8My80VstOhYoI8-XOZ4o).

## Nits

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.

### Outdated references

Document references `draft-ietf-opsawg-service-assurance-yang-09`, but `-10` is
the latest available revision.

Document references `draft-irtf-nmrg-ibn-concepts-definitions`, but that has
been published as `RFC9315`.

### Grammar/style

#### Section 2, paragraph 2
```
ervices, the edges indicate a dependency relations. SAIN collector: A functio
                            ^^^^^^^^^^^^^^^^^^^^^^
```
The plural noun "relations" cannot be used with the article "a".

#### Section 3.1, paragraph 8
```
 with the only parameter (the device id) set to "PE1" will appear only once
                                     ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.1.1, paragraph 25
```
given IP address), however it's a not a good parameter to identify an interf
                                ^^^^^^^^^^^^
```
It seems like one article is redundant in this context.

#### Section 3.4, paragraph 1
```
 ignored because their state changes is probably the consequence of the main
                                     ^^
```
The verb form "is" does not seem to match the subject "changes".

#### Section 3.6, paragraph 2
```
ice for a L3VPN. * A tunnel can considered as a subservice for an applicatio
                                ^^^^^^^^^^
```
The modal verb "can" requires the verb's base form.

#### Section 3.6, paragraph 5
```
document refer to physical components but this is not a constraint. Indeed, t
                                     ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3.7, paragraph 4
```
s to obtain the configuration from the the service orchestrator. The latter
                                   ^^^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool