Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-19 Thread Aitken, Paul 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh

Essentially the middle of this document is missing: a summary of issues is 
given and new IEs are proposed as a solution. But the issues are not developed 
or explained.


1.1.  Issues with ipv6ExtensionHeaders Information Element

   *  Specify a means to export the order and the number of occurences
  of a given extension header.

Typo, "occurrences"


The specification of ipv6ExtensionHeaders IPFIX IE does not:

Consider including the IE number for clarity, eg "The specification of 
ipv6ExtensionHeaders IPFIX IE (#64) does not:"

Same for 1.2 (tcpOptions, #209).


   *  Describe how any observed TCP option in a Flow can be exported
  using IPFIX.  Only TCP options having a kind =< 63 can be exported
  in a tcpOptions IPFIX IE.

Conventionally "<=" is used.

3.  Information Elements for IPv6 Extension Headers

   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.
For clarity say, "Section 1.1 above", else it seems to refer to 1.1 of 
ietf-opsawg-ipfix-fixes.


   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.  Because some of these limitations
   cannot be addressed by simple updates to ipv6ExtensionHeaders, this
   section specifies a set of new IEs to address all the
   ipv6ExtensionHeaders IE limitations.

Please expand on this and explain "some of": which issues are addressed and 
which are not? Why does the document identify issues without proposing 
solutions to them all? How and when will those other issues be fixed?


3.1 - 3.4

These definitions should be in the IANA section.

Section 3 should explain the problems and how they are solved, rather than 
jumping straight to the IEs as a fait-accompli.

3.1.  ipv6ExtensionHeadersFull Information Element
Please include some discussion and justification for creating this new element 
rather than updating the existing ipv6ExtensionHeaders IE (#64). If the 
existing IE cannot be updated then explain backwards compatibility between the 
proposed and existing IEs and deprecate the existing IE.

The information is encoded in a set of bit fields.
It sounds like a singular bit field rather than a set of bit fields.

  In doing so,
  few octets will be needed to encode common IPv6 extension headers
  when observed in a Flow.
This justification should be part of the discussion I mentioned above, and not 
part of the definition.


The "No Next Header" (59) value is used

Add an xref for the 59.


  This Information Element SHOULD NOT be exported if
  ipv6ExtensionHeaderCount Information Element is also present.

Explain why not. This explanation should be in the text rather than in the 
definition.
This should possibly be in section 5.1 where the 3rd paragraph discusses 
similar limitations.


   Abstract Data Type:  unsigned256

No, it's a bitfield. unsigned256 represents an integer, which this is not.

3.2.  ipv6ExtensionHeaderCount Information Element

   Description:  As per Section 4.1 of [RFC8200], IPv6 nodes must accept
  and attempt to process extension headers in occurring any number
Typo, "in".


 MSB LSB
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  EH Type#1|   Count   |...|  EH Type#n  |   Count   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Abstract Data Type:  unsigned64

This is neither a simple IE, nor an unsigned64. It's a structured data type, ie 
a variable-length array of { type, count } tuples.


3.3.  ipv6ExtensionHeadersLimit Information Element

What is to be understood when this IE is not included in the IPFIX data? Is it 
the same as "true"; the same as "false"; or something else?


3.4.  ipv6ExtensionHeadersChainLength Information Element

  See [RFC9098] for an overview of operational implications of IPv6
  packets with extension headerss.

Typo, "headers"


4.  Information Elements for TCP Options

Again this jumps directly from the introduction to the solution without any 
discussion or explanation.


   The definition of the tcpOptions IE is updated in
   [I-D.ietf-opsawg-ipfix-fixes] to address some of the issues listed in
   Section 1.2.  Because some of these limitations cannot be addressed
   by simple updates to tcpOptions, this section specifies a set of new
   IEs to address all the tcpOptions IE limitations.

Please expand on this and explain "some of": which issues are addressed and 
which are not? Why does the document identify issues without proposing 
solutions to them all? How and when will those other issues be fixed?


4.1.  tcpOptionsFull Information Element

Plea

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-19 Thread Aitken, Paul 
https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-06.txt


1.  Introduction

A brief overview of UDP option is provided in Section 3.

Typo, "UDP options" (plural).


   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.


3.  UDP Options at a Glance

Also, Section 4.3 specifies a new IPFIX to
export observed ExIDs in the UEXP options.

Something is missing here: "a new IPFIX IE to ...".


Only 16-bits ExIDs are supported.

Clarify, "Only 16-bits ExIDs are supported in UDP."


The motivation for
   exporting such data is similar to the one for exporting TCP options
   (tcpOptions) or IPv6 Extension Headers (ipv6ExtensionHeaders).

Please state the motivation or include an xref where the motivation can be 
found.


4.1 - 4.3

These definitions should be in the IANA section.


5.  An Example

   Given UDP kind allocation in Section 10 of
   [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
   Section 4.1,

Section 4.1 of what?


4.1.  udpOptions

  To cover the 0-255 kind range, up to 255 flags can be set in the
  value field.

Up to 256 flags.


For example, if only option kinds =< 32 are observed

Conventionally "<=" is used.


Abstract Data Type:  unsigned256

It's not an integer, it's a bitfield.


4.2 and 4.3

It would be better to spell out the names in full: 
udpExperimentalOptionSafeExID and udpExperimentalOptionUnsafeExID


I would not have understand what these measure, nor how to encode them, without 
having first reviewed draft-ietf-opsawg-ipfix-tcpo-v6eh. Examples in section 5 
would be useful.

The octetArray type is especially confusing as these are really hextetArrays.



4.3.  udpUnsafeExpOptionExID

   Description:  Observed Expermients ID (ExIDs) in the UNSAFE
  Experimental option (UEXP, Kind=254).

Typo, "Experiments".


P.


On 18/12/23 19:22, Joe Clarke (jclarke) wrote:
We’d like to kick off a [rather extended] WG LC on the three IPFIX-related 
“fixes” documents we have in the hopper.  We’ve already requested some 
directorate reviews for these, and the authors feel they have stabilized well.

Please review:


  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ 
[datatracker.ietf.org]
  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ 
[datatracker.ietf.org]
  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ 
[datatracker.ietf.org]

And comment as to whether or not you feel they are in the right shape to 
progress to the IESG.  We will run this LC until Jan 8 given that the holidays 
means some people will not be around.  Also note that an IPR poll was conducted 
prior to adoption and no known IPR has been disclosed.

Thanks.

Joe



___
IPFIX mailing list
ip...@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCO14NBgv$
 [ietf[.]org]


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

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-22 Thread mohamed . boucadair 
Hi Paul,

Thanks for the review.

Please see inline.

Cheers,
Med

De : ipv6  De la part de Aitken, Paul
Envoyé : vendredi 19 janvier 2024 11:58
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-06.txt


1.  Introduction

A brief overview of UDP option is provided in Section 3.

Typo, "UDP options" (plural).

[Med] ACK.

   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities 
(iana.org) (where 
unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs having data 
semantic of flags.


3.  UDP Options at a Glance

Also, Section 4.3 specifies a new IPFIX to
export observed ExIDs in the UEXP options.

Something is missing here: "a new IPFIX IE to ...".
[Med] Fixed.

Only 16-bits ExIDs are supported.

Clarify, "Only 16-bits ExIDs are supported in UDP."
[Med] updated to « supported in [I-D.ietf-tsvwg-udp-options]."

The motivation for
   exporting such data is similar to the one for exporting TCP options
   (tcpOptions) or IPv6 Extension Headers (ipv6ExtensionHeaders).

Please state the motivation or include an xref where the motivation can be 
found.
[Med] We may simply delete that sentence.

4.1 - 4.3

These definitions should be in the IANA section.


5.  An Example

   Given UDP kind allocation in Section 10 of
   [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
   Section 4.1,

Section 4.1 of what?
[Med] of this document.


4.1.  udpOptions

  To cover the 0-255 kind range, up to 255 flags can be set in the
  value field.

Up to 256 flags.
[Med]  ACK.

For example, if only option kinds =< 32 are observed

Conventionally "<=" is used.
[Med]  OK

Abstract Data Type:  unsigned256

It's not an integer, it's a bitfield.
[Med] see above.

4.2 and 4.3

It would be better to spell out the names in full: 
udpExperimentalOptionSafeExID and udpExperimentalOptionUnsafeExID
[Med] Expanded to udpSafeExperimentalOptionExID and 
udpUnsafeExperimentalOptionExID


I would not have understand what these measure, nor how to encode them, without 
having first reviewed draft-ietf-opsawg-ipfix-tcpo-v6eh. Examples in section 5 
would be useful.
[Med] OK, will update the example.

The octetArray type is especially confusing as these are really hextetArrays.

[Med] Not sure we need a new data type here as octeArray is defined as follows:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

4.3.  udpUnsafeExpOptionExID

   Description:  Observed Expermients ID (ExIDs) in the UNSAFE
  Experimental option (UEXP, Kind=254).

Typo, "Experiments".
[Med]  Fixed.

P.

On 18/12/23 19:22, Joe Clarke (jclarke) wrote:
We'd like to kick off a [rather extended] WG LC on the three IPFIX-related 
"fixes" documents we have in the hopper.  We've already requested some 
directorate reviews for these, and the authors feel they have stabilized well.

Please review:


  1.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ 
[datatracker.ietf.org]
  2.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ 
[datatracker.ietf.org]
  3.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ 
[datatracker.ietf.org]

And comment as to whether or not you feel they are in the right shape to 
progress to the IESG.  We will run this LC until Jan 8 given that the holidays 
means some people will not be around.  Also note that an IPR poll was conducted 
prior to adoption and no known IPR has been disclosed.

Thanks.

Joe



___

IPFIX mailing list

ip...@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCO14NBgv$
 [ietf[.]org]

___

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-22 Thread Aitken, Paul 
Med,

   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is 
meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" 
value.


5.  An Example

   Given UDP kind allocation in Section 10 of
   [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
   Section 4.1,

Section 4.1 of what?
[Med] of this document.

Please write that for clarity.


The octetArray type is especially confusing as these are really hextetArrays.

[Med] Not sure we need a new data type here as octeArray is defined as follows:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

The draft proposes the encoding not of octets, but of 16-bit values. Therefore 
it's not an "array of zero or more octets" but rather, an "array of zero or 
more hextets".

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

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-22 Thread Aitken, Paul 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


Abstract

The updates are also meant to bringing some
consistency among the entries of the registry.

Typo, "meant to bring in".


1.  Introduction

As the OPSAWG is currently considering

This will soon become outdated. Consider, "When OPSAWG was considering ..."


not adequately specified any longer

"nolonger adequately specified"


This document intends to update the IANA registry
   and bringing some consistency among the entries of the registry.

Typo, "bring".


As discussed with IANA

Say when and/or where.


   *  Miscellaneous updates that fix broken pointers, orphan section
  references, etc.  (Section 7).

Typo, "orphaned".


4.1.2.  Updates to the ipv6ExtensionHeaders Description

Consider making "OLD" into 4.1.2.1 and "NEW" into 4.1.2.2.

Likewise for all the other OLD / NEW sections - its easier to read now, and 
will be easier to xref in future.


Additional Information:

See RFC Errata 1738.

Please restore the xref.


  The following drawing indicates
  the position of each bit in the encoding of the Information
  Element.

No, not any more - so this should be removed.


  This IE is used only when the observed extension headers are in
  the 0-31 range.

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.


4.2.1.  Issues

   Only options having a kind =< 63 can be included in a tcpOptions IE.

Conventionally, "<= 63".


4.2.2.  Update the Description of the tcpOptions IE

This information element is used only when the observed
 kinds are within the 0-63 range.  If not, the tcpOptionsFull IE

Consider deprecating this IE in favour of tcpOptionsFull.


4.3.  forwardingStatus

In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?


   Future versions may be defined to associate
   meanings with the remaining bits.

This is an old Cisco NetFlow compatible IE. It seems unlikely that there would 
be any future versions. If there were, a new IE should be defined.
Therefore it seems better to leave it as an unsigned8 and correct RFC 7270.


See the Forwarding Status sub-registries at
https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status

An xref would be shorter and neater, eg "See the Forwarding Status 
sub-registries at [FORWARDING-STATUS]".


- Additional Information: See "NetFlow Version 9 Flow-Record Format"
(CCO-NF9FMT).

"CCO-NF9FMT" makes no sense here. It's an xref in the IANA registry, so make it 
an xref in this document.


6.  Consistent Citation of IANA Registries

   This document requests IANA to update [IANA-IPFIX] for each of the IE
   entries listed in the following subsections.

This does not explain the changes or why they are required. It's necessary for 
the reader to individually compare each "old" and "new" section.

Rather than writing an explanation for each change as was done in each 4.x.1 
sub-section, a single note here could indicate that in each case the updates 
move the URLs into the Additional Information section.


6.1.  mplsTopLabelType

This text has been omitted from "NEW" :

See the list of MPLS label types assigned by IANA at
[https://www.iana.org/assignments/mpls-label-values].


6.2.  classificationEngineId

  -  Additional Information:  See https://www.iana.org/assignments/i
pfix/ipfix.xhtml#classification-engine-ids.

Is it possible to prevent the URL from breaking across the "ipfix" word?


6.3.  flowEndReason

   *  OLD:

  -  Additional Information:

There is no existing "Additional Information" for this IE. I appreciate that 
the intention may have been to indicate that the section is blank. However it 
misleadingly appears as though some text is missing, so it would be better not 
to include it at all.

Likewise for many of the subsequent sections.


6.10.  natType

Please take the opportunity to add the missing description, eg "This element 
identifies the type of NAT applied to packets of the flow."


  Note: This change also corrects errors in the pointers provided
  NAT46/NAT64.

Need to ensure IANA doesn't add that to the registry.


6.12.  informationElementDataType

  -  Description:  A description of the abstract data type of an
IPFIX information element.These are taken from the abstract

Please correct the "element.These" typo.


6.19.  valueDistributionMethod

  -  Additional Information:  See the assigned distributed methods

This should be "-  Additional Information:  See the assigned value distribution 
methods"


7.  Misc

Again, it's difficult to see what changed in each section and tedious to 
compare the OLD/NEW to find out.


8.  Security Considerations

Explicitly say that there are no changes.


9.1.  IPFIX Subregistry fo

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-23 Thread mohamed . boucadair 
Hi Paul,

Thank you for the careful review and good suggestions. Went with almost all of 
them.

Please see inline for more context.

Cheers,
Med

De : ipv6  De la part de Aitken, Paul
Envoyé : lundi 22 janvier 2024 22:50
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


Abstract

The updates are also meant to bringing some
consistency among the entries of the registry.

Typo, "meant to bring in".
[Med] OK.

1.  Introduction

As the OPSAWG is currently considering

This will soon become outdated. Consider, "When OPSAWG was considering ..."

[Med] OK

not adequately specified any longer

"nolonger adequately specified"

[Med] OK

This document intends to update the IANA registry
   and bringing some consistency among the entries of the registry.

Typo, "bring".

[Med] OK

As discussed with IANA

Say when and/or where.

[Med] updated the text to indicate that this was during the publication process 
of RFC9487.


   *  Miscellaneous updates that fix broken pointers, orphan section
  references, etc.  (Section 7).

Typo, "orphaned".


4.1.2.  Updates to the ipv6ExtensionHeaders Description

Consider making "OLD" into 4.1.2.1 and "NEW" into 4.1.2.2.

Likewise for all the other OLD / NEW sections - its easier to read now, and 
will be easier to xref in future.

[Med] Good suggestion. Fixed.


Additional Information:

See RFC Errata 1738.

Please restore the xref.
[Med] OK.

  The following drawing indicates
  the position of each bit in the encoding of the Information
  Element.

No, not any more - so this should be removed.

[Med] It is useful as it indicates the bit position that is then referred to in 
the new IANA registry. Updated the figure to make that clearer.

  This IE is used only when the observed extension headers are in
  the 0-31 range.

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.

4.2.1.  Issues

   Only options having a kind =< 63 can be included in a tcpOptions IE.

Conventionally, "<= 63".
[Med] OK


4.2.2.  Update the Description of the tcpOptions IE

This information element is used only when the observed
 kinds are within the 0-63 range.  If not, the tcpOptionsFull IE

Consider deprecating this IE in favour of tcpOptionsFull.
[Med] Seems reasonable, but would like to hear more from the WG.

4.3.  forwardingStatus

In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?
[Med] As per the definition in RFC7270.

   Future versions may be defined to associate
   meanings with the remaining bits.

This is an old Cisco NetFlow compatible IE. It seems unlikely that there would 
be any future versions. If there were, a new IE should be defined.
Therefore it seems better to leave it as an unsigned8 and correct RFC 7270.

[Med] I prefer to maintain the current text in the draft. unsigned8 will be 
used anyway because of the reduced-encoding.

See the Forwarding Status sub-registries at
https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status

An xref would be shorter and neater, eg "See the Forwarding Status 
sub-registries at [FORWARDING-STATUS]".
[Med] Agree but we are using the same format as it appears in the IANA registry.


- Additional Information: See "NetFlow Version 9 Flow-Record Format"
(CCO-NF9FMT).

"CCO-NF9FMT" makes no sense here. It's an xref in the IANA registry, so make it 
an xref in this document.

[Med] Done.


6.  Consistent Citation of IANA Registries

   This document requests IANA to update [IANA-IPFIX] for each of the IE
   entries listed in the following subsections.

This does not explain the changes or why they are required. It's necessary for 
the reader to individually compare each "old" and "new" section.

[Med] We don't repeat that here because we do already have the following in the 
introduction:


   *  Updates that are meant to ensure a consistent structure when

  calling an existing IANA registry (Section 6).

Rather than writing an explanation for each change as was done in each 4.x.1 
sub-section, a single note here could indicate that in each case the updates 
move the URLs into the Additional Information section.


6.1.  mplsTopLabelType

This text has been omitted from "NEW" :

See the list of MPLS label types assigned by IANA at
[https://www.iana.org/assignments/mpls-label-values].

[Med] This one was removed on purpose as the assigned values are provided in 
the IANA IPFIX registry and there is no explicit mapping between the two 
registries.


6.2.  classificationEngineId

  -  Additional Information:  See https://www.iana.org/assignments

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

2024-01-23 Thread mohamed . boucadair 
Hi Paul,

Thank you very much for the detailed review.

There are some points that are common to the udp spec. Will discuss those in 
separate threads.

Please see inline.

Cheers,
Med

De : tsvwg  De la part de Aitken, Paul
Envoyé : vendredi 19 janvier 2024 10:52
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [tsvwg] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh

Essentially the middle of this document is missing: a summary of issues is 
given and new IEs are proposed as a solution. But the issues are not developed 
or explained.


1.1.  Issues with ipv6ExtensionHeaders Information Element

   *  Specify a means to export the order and the number of occurences
  of a given extension header.

Typo, "occurrences"
[Med] Fixed.

The specification of ipv6ExtensionHeaders IPFIX IE does not:

Consider including the IE number for clarity, eg "The specification of 
ipv6ExtensionHeaders IPFIX IE (#64) does not:"

Same for 1.2 (tcpOptions, #209).
[Med] Sure. Went for (64) and (209).


   *  Describe how any observed TCP option in a Flow can be exported
  using IPFIX.  Only TCP options having a kind =< 63 can be exported
  in a tcpOptions IPFIX IE.

Conventionally "<=" is used.
[Med] OK
3.  Information Elements for IPv6 Extension Headers

   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.
For clarity say, "Section 1.1 above", else it seems to refer to 1.1 of 
ietf-opsawg-ipfix-fixes.
[Med] Added "of this document".

   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.  Because some of these limitations
   cannot be addressed by simple updates to ipv6ExtensionHeaders, this
   section specifies a set of new IEs to address all the
   ipv6ExtensionHeaders IE limitations.

Please expand on this and explain "some of": which issues are addressed and 
which are not?
[Med] This is already covered by this pointer: "Refer also to {{Section 4.1.1 
of ?I-D.ietf-opsawg-ipfix-fixes}} for more details.". We do already have two 
paragraphs there with these details. No need to be redundant here.
Why does the document identify issues without proposing solutions to them all? 
How and when will those other issues be fixed?
[Med] The new IEs in this I-D fix all the issues.

3.1 - 3.4

These definitions should be in the IANA section.

Section 3 should explain the problems and how they are solved, rather than 
jumping straight to the IEs as a fait-accompli.
[Med] The issues and rationale are already provided in previous sections, hence 
the current structure.
3.1.  ipv6ExtensionHeadersFull Information Element
Please include some discussion and justification for creating this new element 
rather than updating the existing ipv6ExtensionHeaders IE (#64). If the 
existing IE cannot be updated then explain backwards compatibility between the 
proposed and existing IEs and deprecate the existing IE.
[Med] This is explained in the other spec and have a clear statement that the 
new IE MUST be used when the range is exceeded, etc.

The information is encoded in a set of bit fields.
It sounds like a singular bit field rather than a set of bit fields.
[Med] Hmm, this is a well used terminology in IPFIX IE description. Please 
check the IANA registry.
  In doing so,
  few octets will be needed to encode common IPv6 extension headers
  when observed in a Flow.
This justification should be part of the discussion I mentioned above, and not 
part of the definition.


The "No Next Header" (59) value is used

Add an xref for the 59.
[Med] Added a pointer to {{Section 4.7 of !RFC8200}}.

  This Information Element SHOULD NOT be exported if
  ipv6ExtensionHeaderCount Information Element is also present.

Explain why not. This explanation should be in the text rather than in the 
definition.
This should possibly be in section 5.1 where the 3rd paragraph discusses 
similar limitations.
[Med] Moved to 5.1. The reason is that the content of the IEs is redundant. 
Will see how to convey that in the text.

   Abstract Data Type:  unsigned256

No, it's a bitfield. unsigned256 represents an integer, which this is not.
[Med] Will reply to this one in a separate message as this is also discussed in 
the udp spec.
3.2.  ipv6ExtensionHeaderCount Information Element

   Description:  As per Section 4.1 of [RFC8200], IPv6 nodes must accept
  and attempt to process extension headers in occurring any number
Typo, "in".
[Med] Fixed.

 MSB LSB

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 |  EH Type#1|   Count   |...|  EH Type#n