from:"Lars Eggert"

[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

Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-sbom-access-03

2023-04-24 Thread Lars Eggert

Russ, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars

> On 14. Dec 2021, at 00:02, Russ Housley via Datatracker  
> wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-opsawg-sbom-access-03
> Reviewer: Russ Housley
> Review Date: 2021-12-13
> IETF LC End Date: unknown
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> 
> Note: I am not a good persone to review the YANG specification.  I
> assume one of the YANG Doctors will have a look at this document too.
> 
> 
> Major Concerns:
> 
> Section 1 says:
> 
>   To satisfy these two key use cases, objects may be found in one of
>   three ways:
> 
> This lead to some confusion for me.  Earlier in the document, it says:
> 
>   This specification does not allow for vulnerability information to be
>   retrieved directly from the endpoint.  That's because vulnerability
>   information changes occur at different rates to software updates.
> 
> After thinking about it, I realized that the objects do not include
> vulnerability information, but pointers to obtain vulnerability
> information.  Please reword to others do not need to give it the
> same amount of thought.
> 
> 
> Minor Concerns:
> 
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.
> 
> Section 1 says:
> 
>   In the second case, when a device does not have an appropriate
>   retrieval interface, but one is directly available from the
>   manufacturer, a URI to that information must be discovered.
> 
> s/must/MUST/ ?
> 
> 
> Nits:
> 
> The terms "software" and "firmware" are used with essentially the same
> meaning in this document.  If there is a difference, it needs to be
> explained.  If they are the same in the context of this document, please
> say so.
> 
> Abstract, last sentence: please add "(MUD)" and also a pointer to
> RFC 8520.
> 
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

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

2023-03-01 Thread Lars Eggert

Hi,

On Mar 1, 2023, at 20:30, Kenneth Vaughn  wrote:
>> No reference entries found for these items, which were mentioned in the text:
>> `[RFC3413]`, `[RFC2579]`, `[RFC3411]`, `[RFC2578]`, and `[RFC2580]`.
> All of these references are part of either STD58 or STD62, both of which are 
> listed under normative references.
> 
> I have not made any changes as it is unclear how this should be handled.
> •
> Do I leave as is?

yes, leave as is. (Bug in my checker tool it seems.)

>> Document updates `RFC6353`, but does not cite it as a reference, which is a 
>> bit
>> odd.
> I do not understand this comment. The document is cited in the body of the 
> text (e.g., first paragraph of Section 2) and is listed under normative 
> references. I am not sure what additional citation is being proposed.

Ditto. Sorry about that.

Lars


signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-tlstm-update-11

2023-02-28 Thread Lars Eggert

Joel, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Feb 10, 2023, at 01:56, Joel Halpern via Datatracker  
> wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-tlstm-update-11
> Reviewer: Joel Halpern
> Review Date: 2023-02-09
> IETF LC End Date: 2023-02-20
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as a Proposed Standard RFC
> 
> Major issues: N/A
> 
> Minor issues:
>In the fourth paragraph of section 1.1, the text refers to "a secure
>association between two TLS Transport Models (TLSTMs)".  As I understand
>the terminology, there is one TLSTM.  There are two instances of /
>realizations of the model.  Should the sentence refer to instances or
>realizations, rather than two models? (i-d nits gets confused by the
>references to rfc 5953 in the revision description.  After looking at it, I
>realized there was no problem here, rather it is accurate.  A comment on
>this in item 14 of the shepherd writeup would have been helpful.)
> 
> Nits/editorial comments: N/A
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-sap-12

2023-01-13 Thread Lars Eggert

Linda, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Jan 3, 2023, at 22:11, Linda Dunbar via Datatracker  
> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-sap-12
> Reviewer: Linda Dunbar
> Review Date: 2023-01-03
> IETF LC End Date: 2023-01-09
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document specifies the YANG data model for the Network Service
> Attachment Points.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> It seems to me that the Network Service Attachment Points are very similar to
> Network Termination Points. What are the major differences?
> 
> Thank you
> Linda Dunbar
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-service-assurance-yang-09

2022-12-12 Thread Lars Eggert

Dan, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Nov 14, 2022, at 21:36, Dan Romascanu via Datatracker  
> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-service-assurance-yang-09
> Reviewer: Dan Romascanu
> Review Date: 2022-11-14
> IETF LC End Date: 2022-11-22
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Ready with Nits
> 
> This is a well written and clear document that specifies YANG modules for
> representing assurance graphs which represent the assurance of a given service
> by decomposing it into atomic assurance elements called subservices. It
> conforms with the SAIN architecture described in a separate document which is
> mandatory reading in order to understand, implement or use the YANG modules.
> 
> The document is Ready from a Gen-ART perspective. A few nits should be
> considered before publication.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 1. A number of acronyms need expanding at first occurrence: SAIN, TCAM, ECMP.
> May be more.
> 
> 2. Section 2:
> 
>> The third YANG module, "ietf-service-assurance-interface"
>   (Section 5), is another example that augments the "ietf-service-
>   assurance" module, by adding support for the interface subservice.
> 
> Why is this called 'another example'. If this is an example (of what?), should
> not the module in Section 5 be named as such?
> 
> 3. In section 3.3:
> 
>>type yang:date-and-time;
>  description
>"Date and time at which the symptom stopped being detected.
> must after the start-date-time.";
> 
> s/must after the start-date-time/must be after the start-date-time/
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [OPSAWG] [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-service-assurance-architecture-11 [RESEND]

2022-12-12 Thread Lars Eggert

Paul, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Nov 18, 2022, at 16:55, Paul Kyzivat  wrote:
> 
> [Resending to include the wg and last-call.]
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-service-assurance-architecture-11
> Reviewer: Paul Kyzivat
> Review Date: 2022-11-15
> IETF LC End Date: 2022-11-20
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> Issues: 1
> Nits: 8
> 
> 1) ISSUE: Section 3.6: ambiguity
> 
> As best I understand the text "Under Maintenance" is being used in two 
> different ways that can cause ambiguity:
> 
> - "When a service or subservice is flagged as under maintenance, it must 
> report a generic "Under Maintenance" symptom, for propagation towards 
> subservices that depend on this specific subservice: any other symptom from 
> this service, or by one of its impacting dependencies must not be reported."
> 
> -  " In more complex cases, for instance with a primary and backup path ... 
> In such cases, the status of the service instance might include the "Under 
> Maintenance" as well as other symptoms (e.g. from the backup path)"
> 
> In the latter case, if nothing is wrong with the backup path then there might 
> only be the "Under Maintenance" from the primary path, and it would be 
> indistinguishable from a case where there was no backup path.
> 
> IIUC it is important that these cases be distinguishable.
> 
> 
> 2) NIT: Section 3: missing word
> 
> "Based on the service configuration provided by the service orchestrator, the 
> SAIN orchestrator decomposes the assurance graph. It then sends to the SAIN 
> agents the assurance graph along some other configuration options."
> 
> s/along some other/along with some other/
> 
> 
> 3) NIT: Section 3.3.3: Improper DNS name in example
> 
> "Assume that we want to assure a kubernetes cluster https://kubernetes.io.";
> 
> Examples like this should only use DNS domains intended for examples, such as 
> kubernetes.example.org.
> 
> 
> 4) NIT: Section 3.1.1: missing word
> 
> "The status of a should depend on the status of c, d, e, f, g, and h"
> 
> s/status of a should/status of a  should/
> 
> 
> 5) NIT: Section 3.6: confusing wording
> 
> "Symptoms related to the device-specific subservices, such as the interfaces, 
> might be ignored as well as their state changes is probably the consequence 
> of the maintenance."
> 
> Hard to parse. Does the following work?
> 
> "Symptoms related to the device-specific subservices, such as the interfaces, 
> might also be ignored because their state changes are probably the 
> consequence of the maintenance."
> 
> 
> 6) NIT: Section 3.6: punctuation
> 
> Odd punctuation in:
> 
> "... subservices that depend on this specific subservice: any other symptom 
> ..."
> 
> I think this would be better as two sentences:
> 
> "... subservices that depend on this specific subservice. Any other symptom 
> ..."
> 
> 
> 7) NIT: Section 3.7: bad syntax
> 
> Syntax problems with:
> 
> "One of them is the domain of service management on network elements, with 
> also requires its own assurance."
> 
> Does the following express the intent?
> 
> "One of them is the domain of service management on network elements, that 
> also require their own assurance."
> 
> 
> 8) NIT: Section 3.7: awkward language
> 
> The following language is quite awkward:
> 
> " Exactly like ...
> , exactly like ...
> , exactly like ...
> . Exactly like ... .
> 
> I suggest breaking this out as a list.
> 
> 
> 9) NIT: Section 3.9: unusual language
> 
> The following is IMO unusual phrasing:
> 
> "The assurance graph will change along the time"
> 
> I think the following would be a better phrasing:
> 
> "The assurance graph will change over time"
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

2022-10-20 Thread Lars Eggert

Elwyn, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2022-10-10, at 14:53, Elwyn Davies via Datatracker  
> wrote:
> 
> Reviewer: Elwyn Davies
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-yang-vpn-service-pm-12
> Reviewer: Elwyn Davies
> Review Date: 2022-10-10
> IETF LC End Date: 2022-10-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:  Ready with a few minor nits.  Apologies for the rather late 
> delivery.
> 
> Major issues:
> 
> Minor issues:
> 
> s4.4:  The following text appears in the section on 'Percentile Parameters':
> 
>  Setting a percentile to
>  0.00 indicates the client is not interested in receiving
>  particular percentile.
> 
> Given the discussion of configurable items in Section 6 it would be helpful to
> mention that these items and other items marked 'rw' and with names ending in
> '?' can be configured rather than just saying 'Setting'.
> 
> Nits/editorial comments:
> 
> General: The document contains a lot of VPN terminology and network types 
> using
> acronyms such as CE, PE etc.   Some of these are defined in Sections 2/2.1 but
> a pointer to a document that defines the VPN technology (such as RFC 4026)
> would be helpful.
> 
> s1:  The abbreviations PE, CE and P are used here before their definitions in
> s2.  I guess they had better be expanded on first use.
> 
> s2.1: The references for definitions of MPLS, OWAMP and TWAMP introduced in s3
> would be usefully noted here.
> 
> s3, para 3: s/involved devices/devices involved/
> 
> s3.1, para 1: s/Some applications/Some applications,/
> 
> s4.1, para before Fig 4, sentence 1: s/VPN Network PM YANG module/the VPN
> Network PM YANG module/
> 
> s5: There are 3 instances of 'into 0.0' in the percentile definitions of
> augment "/nw:networks/nw:network/nt:link" that should be 'to 0.0'.
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-l2nm-15

2022-05-30 Thread Lars Eggert

Dale, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2022-5-11, at 4:44, Dale Worley via Datatracker  wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-opsawg-l2nm-15
> Reviewer:  Dale R. Worley
> Review Date:  2022-05-10
> IETF LC End Date:  2022-05-13
> IESG Telechat date:  [not known]
> 
> I have not checked the Yang module itself, as the Yang Doctors will do
> a better job than I can.  Similarly, I have assumed that the specific
> information required for configuring VPNs has been set correctly by
> the members of the working group.  I have reviewed it from the point
> of view that I am qualified to, a reader with beginning knowledge
> about VPNs and Yang learning more about the subject.
> 
> Summary:
> 
>This draft is basically ready for publication, but has nits that
>should be fixed before publication.
> 
> Nits/editorial comments:
> 
> 2.  Terminology
> 
> Clarifying the wording here so as to make clear the relationships
> between these concepts would ease the learning curve for the
> inexperienced.  For example,
> 
>   VPN node:  Is an abstraction that represents a set of policies
>  applied on a PE and belonging to a single VPN service.
> 
> This is likely known in the VPN community, but I'm having a problem
> following it:  What exactly is a PE, or rather, what is its conceptual
> scope?  A "Customer Edge-to-Provider Edge attachment circuit" is clear
> to the naive, because it's the tangible thing that connects the
> customer to the service provider.  That suggests that the CE is the
> logical entity on the customer end of the attachment, and similarly
> the PE.  But is the PE unique to the attachment circuit, and thus the
> VPN has a lot of PEs that it interconnects, or is there a single PE in
> the VPN?
> 
> Also, is there only one VPN node that is applied to any one PE, or can
> there be many?  This determines whether VPN nodes are one-to-one with
> PEs or whether they may have a wider scope.  It seems to be known that
> a VPN can have multiple VPN nodes, but that isn't stated in the
> definition either.
> 
>   VPN network access:  [...]
> 
>  A reference to the bearer is maintained to allow keeping the link
>  between the L2SM and the L2NM when both data models are used in a
>  given deployment.
> 
> This sentence is correct, but it doesn't seem to belong in this
> location, as it seems to describe an aspect of the data concerning an
> attachment circuit, whereas "VPN network access" is an abstraction of
> just one end of an attachment circuit.  Or does the conceptual model
> not have an abstraction of the other end of attachment circuits, thus
> allowing the network interface and the attachment circuit to be
> conflated, and thus the reference to the bearer can be considered to
> be a property of the VPN network access?
> 
> 4.  Reference Architecture
> 
> In Figure 1, some of the module names are missing the initial "ietf-".
> 
> The bottom section of Figure 1 is:
> 
>+--+  Bearer+--+  +--+ +--+
>| CE A + -- + PE A +  + PE B + --- + CE B |
>+--+ Connection +--+  +--+ +--+
> 
>   Site A   Site B
> 
> Shouldn't there be some indication of connection between PE A and PE
> B?
> 
> Also, it's not clear why this set of boxes is integrated with the rest
> of Figure 1, as the lines in the figure don't seem to show any
> particular connection between these four boxes and the boxes above
> them.  This segment seems to be a generic VPN between two sites, but
> "Site A" and "Site B" don't seem to be referenced elsewhere.
> 
> If the intention is that "Network" embraces all 4 of these boxes, then
> the ends of the dashed line above "Network" need to be aligned with
> the left and right edges of the sites, and possibly some "|" added to
> show the various interconnections, perhaps in this style:
> 
>   +++   |   |
>   | Config  |   |   |
>   | Manager |   |   |
>   +++   |   |
>||   |
>| NETCONF/CLI..
>||   |
>+-+
>|Network  |
> 
>+--+  Bearer+--+  +--+ +--+
>| CE A + -- + PE A +==+ PE B + --- + CE B |
>+

[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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-ntf-09

2021-11-29 Thread Lars Eggert

Gyan, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2021-10-24, at 3:45, Gyan Mishra via Datatracker  wrote:
> 
> Reviewer: Gyan Mishra
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-ntf-??
> Reviewer: Gyan Mishra
> Review Date: 2021-10-23
> IETF LC End Date: 2021-10-27
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> This draft analyzes the overall framework of network telemetry technologies
> that exist today and future evolution of telemetry technology and data
> gathering from a control plane, data plane and management plane perspective.
> Document is well written.
> 
> Major issues:
> None
> 
> Minor issues:
> None
> Nits/editorial comments:
> 
> Section 4.1.3 Forwarding plane telemetry does not include STAMP RFC 8762.
> Mention traditional non OAM based ping ICMP Echo snd Echo-Reply.
> 
> Also for OAM based maybe list the variety of OAM based ping such as for all
> data planes such as MPLS, RSVP-TE,  L2 VPN pdeudowire OAM ping VCCV (Virtual
> Circuit Connection Verification) RFC 5085 RFC 7189, RFC 5586 GACH PW OAM.
> 
> Any of the RFCs listed here maybe include as informative references.
> 
> Also NVO3 VXLAN and BIER OAM.  SFC service plane RFC 8924 SFC OAM.
> 
> Also DETNET forwarding and service sub planes DETNET OAM.
> 
> SDN and SD-WAN, PCEP, BGP all centralized controller based architecture can
> also be used for network telemetry.
> 
> RESTCONF REST API is missing should be mentioned
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-tacacs-yang-09

2021-04-14 Thread Lars Eggert

Mohit, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2021-3-20, at 12:24, Mohit Sethi via Datatracker  wrote:
> 
> Reviewer: Mohit Sethi
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-tacacs-yang-09
> Reviewer: Mohit Sethi
> Review Date: 2021-03-20
> IETF LC End Date: 2021-03-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document defines a TACACS+ YANG module for configuring TACACS+
> clients so that they can use TACACS+ servers as an alternative to RADIUS
> servers or local user configuration.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> Perhaps expand TACACS+ on first usage. The same for FIB. Perhaps add the
> acronym AAA to the first usage of Authentication, Authorization and Accounting
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

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

Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-sbom-access-03

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

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-tlstm-update-11

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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-sap-12

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

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

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-service-assurance-yang-09

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

Re: [OPSAWG] [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-service-assurance-architecture-11 [RESEND]

Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-l2nm-15

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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-ntf-09

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

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

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

Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-tacacs-yang-09

21 matches

Site Navigation

Mail list logo

Footer information