Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-srv6-srh-14

Thank you to the authors for addressing my previous DISCUSS items in a timely fashion.

Thank you to Tero Kivinen for the SECDIR review.

** Section 9
   There exists no significant extra security considerations regarding
   allocation of these new IPFIX IEs compared to [RFC7012]

What are the “non-significant extra security considerations” not mentioned in RFC7012?  The text implies there is something more to say.

** Section 9.
   Privacy considerations described in Section 11.8 of [RFC7012] SHOULD
   be considered for all described IEs.  They export provider data plane
   metrics which describe how packets are being forwarded within the
   SRv6 network.


-- Typo.  This text should reference Section 11.8 of RFC7011.  RFC7012 has no privacy consideration and no Section 11.

-- Even though this is a data model, the clarity of “SHOULD ... consider” language (here) to text which has non-normative “mays” and “musts” (of RFC7011) is murky.  Consider if it is more appropriate to say “must”.  For example:

NEW
The IEs described in this document export provider plane data metrics on how packets are being forwarded within an SRv6 network. Applications and operators using the IEs described in this document must evaluate the sensitivity of this information in their implementation context, and apply the data-at-rest storage guidance in Section 11.8 of RFC7011 as appropriate.

My thanks for so quickly addressing my previous discuss!

# Internet AD comments for draft-ietf-opsawg-ipfix-srv6-srh-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.2

* We might clarify here that no export method involves any "decompression"
  of a compressed SID.  (I assume unpacking a compressed SID is entirely the
  responsibility of an analysis function within or downstream of the
  collector.)

## Nits

### S5.2

* s/designed experts/designated experts/

Thanks for your work to address my previous DISCUSS and COMMENT. There is a residual comment, which is the question of how srhIPv6Section should be formed if there is no SRH in the packet. In his reply, Thomas said,

> In case when the compressed SID container is only used in the IPv6 destination address of the provider data plane and the SRH is not being present at all, it would be a zero lenght array.

Perhaps adding some text to that effect might be worthwhile.

# 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

Thanks for working on this specification. Thanks to Michael Tüxen for the TSVART review. Based on this review I am balloting no objection.