[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-13: (with COMMENT)

2023-05-25 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-ipfix-srv6-srh-11

CC @larseggert

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

### Grammar/style

 Section 3, paragraph 10
```
s information [IANA-IPFIX] allow to provide answers to the following questio
 ^^
```
Did you mean "providing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

 Section 5.1.10, paragraph 5
```
as a list, without the need of post processing. However, this method require
   ^^^
```
This word is normally spelled with a hyphen.

 Section 6.1, paragraph 6
```
emented the following IEs as part of a a production implementation in the VRP
 ^^^
```
Possible typo: you repeated a word.

 Section 6.2, paragraph 1
```
ListSection decomposition as part of a a production implementation in the ope
 ^^^
```
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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-sbom-access-15: (with COMMENT)

2023-04-24 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-sbom-access-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-sbom-access-15

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/c_Npcow_0xA8aojaPi07NMcoeaw).

## Comments

### Section 1, paragraph 3
```
 Put simply, we seek to answer two classes of questions *at scale*:
```
What does "at scale" mean here? Ask the questions to a large number of systems?
Ask the questions and expect very large results? Something else?

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

### Uncited references

Uncited references: `[RFC8446]`, `[RFC6242]`, and `[RFC8341]`.

### Outdated references

Reference `[RFC7231]` to `RFC7231`, which was obsoleted by `RFC9110` (this may
be on purpose).

### Grammar/style

 Section 1, paragraph 16
```
: * on devices themselves * on a web site (e.g., via URI) * through some for
 
```
Nowadays, it's more common to write this as one word.

 Section 4, paragraph 13
```
this device. Publication dates can found inside the SBOMs."; } choice vuln-r
   ^
```
Make sure that the ambiguous verb form "found" is correct. (It can either be
the base form "found", or the past tense of a different verb.).

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

2023-02-28 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-tlstm-update-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-tlstm-update-12

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VI00LPj0gVfsGW_qOfw9JlGAJdE).

## Comments

### Paragraph 2
```
Updates to the TLS Transport Model for SNMP
 draft-ietf-opsawg-tlstm-update-12
```
Was there a mibdoctors review of this I-D? Should there be?

### Section 1, paragraph 1
```
 This document updates and clarifies how the rules of [RFC6353] apply
 when using Transport Layer Security (TLS) or Datagram Transport Layer
 Security (DTLS) versions later than 1.2.  This document jointly
 refers to these two protocols as "(D)TLS".  The update also
 incorporates the [RFC8996] update, which prohibits the use of TLS
 versions prior to TLS 1.2.
```
Should this document then not also obsolete RFC8996?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC3413]`, `[RFC2579]`, `[RFC3411]`, `[RFC2578]`, and `[RFC2580]`.

### Uncited references

Document updates `RFC6353`, but does not cite it as a reference, which is a bit
odd.

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

Reference `[RFC5953]` to `RFC5953`, which was obsoleted by `RFC6353` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

### Grammar/style

 Section 4, paragraph 28
```
s not specify converting to lowercase so this involves an extra step). This
 ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

 Section 4, paragraph 90
```
nd this hash value MUST match exactly or the connection MUST NOT be establis
 ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-sap-13: (with COMMENT)

2023-01-13 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-sap-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-sap-13

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ItsyANCW6Oj_lsbpj7gAxWiyOfU).

## Comments

### Inclusive language

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

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## 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-teas-ietf-network-slices-17`, but `-18` is the
latest available revision.

### Grammar/style

 "Table of Contents", paragraph 1
```
iew can be used, e.g., to feed an intelligence that is responsible for servic
   ^^^
```
Uncountable nouns are usually not used with an indefinite article. Use simply
"intelligence".

 Section 2, paragraph 1
```
RFC4026]). Customer Edge (CE): An equipment that is dedicated to a particular
   
```
Uncountable nouns are usually not used with an indefinite article. Use simply
"equipment".

 Section 2, paragraph 3
```
itch, etc. Provider Edge (PE): An equipment owned and managed by the service
   
```
Uncountable nouns are usually not used with an indefinite article. Use simply
"equipment".

 Section 5, paragraph 22
```
and its parent interface are present but the parent interface is disabled, t

```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

 Section 10.2, paragraph 29
```
oses, this section focuses on the so called "Option A" but similar examples c
  ^
```
The expression "so-called" is usually spelled with a hyphen.

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-service-assurance-yang-10: (with COMMENT)

2022-12-12 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-service-assurance-yang-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-service-assurance-yang-10

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/PUK6ex0SQtj7-di4O2RM31mul2A).

## Comments

### Boilerplate

This document uses the RFC2119 keywords "SHALL NOT", "SHOULD NOT", "SHALL",
"MAY", "REQUIRED", "RECOMMENDED", "OPTIONAL", "SHOULD", "MUST NOT", "NOT
RECOMMENDED", and "MUST", but does not contain the recommended RFC8174
boilerplate. (It refers to BCP 13 and not BCP 14...)

### DOWNREFs

DOWNREF `[I-D.ietf-opsawg-service-assurance-architecture]` from this Proposed
Standard to Informational `draft-ietf-opsawg-service-assurance-architecture`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

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

Reference `[RFC7895]` to `RFC7895`, which was obsoleted by `RFC8525` (this may
be on purpose).

### Grammar/style

 Section 3.2, paragraph 29
```
. The subservices hierarchically organised by dependencies constitute an ass
 ^
```
Do not mix variants of the same word ("organise" and "organize") within a
single text.

 Section 3.3, paragraph 16
```
ption "Date and time at which the symptoms history starts for this subservic
  
```
An apostrophe may be missing.

 Section 3.3, paragraph 18
```
iption "Container for the list of agents’s symptoms"; list agent { key "id";
  
```
Did you mean "agent's" or "agents'"?

 Section 3.3, paragraph 18
```
e some guidelines in order to build theses extensions. The mechanism to add a
^^
```
Did you mean "these"?

 Section 3.3, paragraph 18
```
 The parameters should be defined in an container named "parameters" augmenti
 ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

 Section 6.1, paragraph 3
```
 be given access to monitor their services status (e.g. via model-driven tel
  
```
An apostrophe may be missing.

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-service-assurance-architecture-12: (with COMMENT)

2022-12-12 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-service-assurance-architecture-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/



--
COMMENT:
--

# 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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

2022-10-20 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-yang-vpn-service-pm-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-yang-vpn-service-pm-13

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/GZGiqBYW9PpHdVBNPE6f_f6JucU).

## Comments

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

### Typos

 Section 4.3, paragraph 24
```
-PM statistics per class ("one-way-pm-statistics-per-class"):  Lists p
-   --
```

 Section 4.3, paragraph 24
```
-   erformance measurement statistics for the topology link or the
+   performance measurement statistics for the topology link or the
+   +
```

 Section 4.3, paragraph 28
```
-Last updatd time ("last-updated"):  Indicates the timestamp when the
-  ^
+Last update time ("last-updated"):  Indicates the timestamp when the
+  ^
```

### Grammar/style

 Section 5, paragraph 4
```
 places, e.g. 10.00, 99.90 ,99.99 etc.. For example, for a given one-way del
 ^^
```
Two consecutive dots.

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-l2nm-17: (with COMMENT)

2022-05-30 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-l2nm-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-l2nm-17

CC @larseggert

Thanks to Dale Worley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/iTZYyhVQ7nygCX_KIedl1RhPBE4).

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

Reference `[RFC5143]` to `RFC5143`, which was obsoleted by `RFC4842` (this may
be on purpose).

### Grammar/style

 Section 4, paragraph 9
```
ider does not assume, nor does it precludes exposing the VPN service via the
  ^
```
Did you mean "preclude"? As "do" is already inflected, the verb cannot also be
inflected.

 Section 8.4, paragraph 54
```
 MAC address' situation has occurred and the duplicate MAC address has been

```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

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



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

2021-11-29 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-ntf-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/



--
COMMENT:
--

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

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

Thanks to Gyan S. Mishra for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ItkS25VOVfDg8eLogFDMCtpeoFM).

---
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.2. , paragraph 4, nit:
> ic manipulation. In some cases, micro-bursts need to be detected in a very sh
> 
This word is normally spelled as one.

Section 3.2. , paragraph 6, nit:
> ant to be warned of issues in advance so proactive actions can be taken to av
>  ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 4.1. , paragraph 3, nit:
> lso be implemented over TCP and SCTP but that is not recommended for forward
> 
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 10. , paragraph 19, nit:
> P/2 [RFC7540] based open-source micro-service communication framework. It pro
> ^
This word is normally spelled as one.

"A.3.1. ", paragraph 2, nit:
> pected movement makes it fascinating and many people connect to sites that a
> 
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

"A.3.1. ", paragraph 3, nit:
> ent can be affected by such situation so their management solutions should be
>  ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Document references draft-ietf-ippm-multipoint-alt-mark, but that has been
published as RFC8889.

Document references draft-song-ippm-postcard-based-telemetry-10, but -11 is the
latest available revision.

Document references draft-ietf-grow-bmp-adj-rib-out, but that has been
published as RFC8671.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)

2021-09-20 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-vpn-common-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/



--
COMMENT:
--

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

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

---
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 62, nit:
> or the QinAny encapsulation. The outer outer VLAN tag is set to a specific va
>  ^^^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-l3sm-l3nm-10, but -11 is the latest
available revision.

Document references draft-ietf-opsawg-l2nm-04, but -06 is the latest available
revision.

Document references draft-ietf-teas-ietf-network-slice-framework-00, but -04 is
the latest available revision.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-l3sm-l3nm-11: (with COMMENT)

2021-09-20 Thread Lars Eggert via Datatracker
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/



--
COMMENT:
--

It would be useful to summarize this document's relationship to RFC8299 in the 
abstract.

---
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 7.6.3. , paragraph 43, nit:
> icates which BFD flavor is used to setup the session (e.g., classic BFD [RFC
>^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 7.7. , paragraph 1, nit:
> y applicable if both RP redundancy and and delivery through optimal path are
>^^^
Possible typo: you repeated a word.

Section 8. , paragraph 8, nit:
>  VPLS and, VXLAN. Other values may defined, if needed."; leaf type { type ide
>^^^
The modal verb "may" requires the verb's base form.

Section 8. , paragraph 32, nit:
> cription "Reference to the TCP-AO key chain."; reference "RFC 8177: YANG Key
>   ^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> description "Reference to the MD5 key chain."; reference "RFC 8177: YANG Key
>   ^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> f; description "Customer-supplied key chain."; } } } } } container service {
>   ^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> cast static source/group associated to to IGMP session"; leaf group-addr { ty
> ^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-vpn-common-09, but -10 is the latest
available revision.

Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
 * http://tools.ietf.org/wg/opsawg/



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg