* 1.1

Add "the":

   Section 3 addresses these issues.  Also, the ipv6ExtensionHeaders IPFIX
   IE is deprecated in favor of the new IEs defined in this document.


* 1.2

Add "the" :

   The specification of the tcpOptions IPFIX IE (209) does not:

Should "option" be "options"? :

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

Add "the" :

   Section 4 addresses these issues.  Also, the tcpOptions IE is deprecated
   in favor of the new IEs defined in this document.


* 2

Is the indentation correct here? :

   Extension header chain:  Refers to the chain of extension headers
      that are present in an IPv6 packet.

      This term should not be confused with the IPv6 header chain, which
      includes the IPv6 header, zero or more IPv6 extension headers, and
      zero or a single Upper-Layer Header.


* 3.2

"the same" :

   Description:  The number of consecutive occurrences of the same
      extension header type in a Flow.


* 3.4

Add "ipv6ExtensionHeaderTypeCountList" :

      If several extension header chains are observed in a Flow, each
      header chain MUST be exported in a separate 
ipv6ExtensionHeaderTypeCountList IE.


* 3.5

What if both ipv6ExtensionHeadersFull and ipv6ExtensionHeaderTypeCountList are 
exported?
[Later] this is discussed in section 5.1, but that wouldn't be known from 
reading the IPFIX registry alone. The fact that these IEs are mutually 
exclusive should be added to both IE descriptions.


   Description:  When set to "false", this Information Element indicates
      that the exported extension headers information (e.g.,
      ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does
      not match the full enclosed extension headers


* 3.6

Change "identifying" to "to identify" :

      Exporting such information might help
      to identify root causes of performance degradation, including
      packet drops.

How would we know which ipv6ExtensionHeadersChainLength IE corresponds with 
which header chain?

      If several extension header chains are observed in a Flow, each
      header chain length MUST be exported in a separate
      ipv6ExtensionHeadersChainLength IE.


* 5.1

"Will" sounds like a detail of a particular implementation. More generally this 
should be a "MUST", a "SHOULD", or a "MAY":

   If an implementation determines that an observed packet of a Flow
   includes an extension header that it does not support, then the exact
   observed code of that extension header will be echoed in the
   ipv6ExtensionHeaderTypeCountList IE (Section 3.4).


* 5.2

What does this mean? :

   If a TCP Flow contains packets with a mix of 2-byte and 4-byte
   Experiment IDs, the same Template Record is used with both
   tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs.



* 6.1

It would be helpful to list the corresponding header bit values, and to list 
them in order (0, 1, 5) rather than 1, 5, 0:


   Figure 1 provides an example of reported values in an
   ipv6ExtensionHeadersFull IE for an IPv6 Flow in which only the IPv6
   Destination Options header (0) is observed.


   Figure 2 provides another example of reported values in an
   ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the IPv6 Hop-
   by-Hop Options (1), Routing (5), and Destination Options (0) headers are
   observed.


* 6.2

It would be helpful to list the corresponding header bit values:

   Figure 3 shows an example of reported values in a tcpOptionsFull IE
   for a TCP Flow in which End of Option List (0), Maximum Segment Size (2), and
   Window Scale (3) options are observed.

Please use the full 16-bit value, "0348" :

   1.  The tcpSharedOptionExID16 IE set to 0x0348454E to report observed
       2-byte ExIDs: HOST_ID and TCP-ENO ExIDs.


* 8.1

It's unclear which IE "this IE" is. eg, write "IE 209" if that's what's meant.


   *  Update the tcpOptions IE (209) entry by marking it as deprecated
      in favor of the tcpOptionsFull IE defined in this document.  This
      note should also be echoed in the "Additional Information" of this
      IE.


* 8.4

This section sets up a potential conflict: what would happen if a new code was 
assigned to an IPv6 EH in [IANA-EH], but the expert reviewers disagreed with 
adding it to IPFIX?

Section 1.1 said, "how to automatically update the IANA IPFIX registry". Is 
expert review contrary to an automatic update?



* 8.4.1.

Typo in Initial Values:

   +-----+-------+----------+-------------------------+---------------+
   | 1   | HOP   | 0        | Pv6 Hop-by-Hop Options  | This-Document |
   +-----+-------+----------+-------------------------+---------------+


_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Reply via email to