Med, I reviewed the current draft-ietf-opsawg-ipfix-tcpo-v6eh.
1.1 "Specify how to automatically update the IANA IPFIX registry"
- is "automatically" correct? I didn't see any mention of this later in the
draft.
1.2 "Support means to report the observed Experimental Identifiers (ExIDs) that
are carried in shared TCP options (kind=253 or 254)"
- it took me far too long to parse this correctly. Would "Allow reporting of
the observed Experimental Identifiers ..." be clearer?
2. Conventions and Definitions
- s/Template/Template Record/
- Collector, Data Record, Flow Record, Exporting Process, Collecting Process
are not used in the document, so they should be removed.
3. "to address some of the issues listed in Section 1.1."
- just some of the issues but not all of them?
3.1 "while bit 254 corresponds to the most-significant bit of the IE."
- 256 bits (2^8) are numbered 0 to 255 or 1 to 256, but never up to 254.
3.1 The "No Next Header" (59) value is used if there is no upper-layer header
in an IPv6 packet. Even if the value is not considered as an extension header
as such, the corresponding bit is set in the ipv6ExtensionHeadersFull IE
whenever that value is encountered in the Flow.
- This goes against the previous paragraph, "In doing so, few octets will be
needed to encode common IPv6 extension headers when observed in a Flow."
because flows with no EH will require at least 8 octets to set bit 59.
3.1 "Several extension header chains may be observed in a Flow. These extension
headers may be aggregated in one single ipv6ExtensionHeadersFull Information
Element or be exported in separate ipv6ExtensionHeadersFull IEs, one for each
extension header chain."
- say whether or not the order of those IEs is important. eg, an intermediate
IPFIX device might not preserve the order.
3.2. ipv6ExtensionHeaderCount Information Element
- consider naming this in plural, "ipv6ExtensionHeadersCount", for consistency
with the other IEs defined here.
3.2 "and number of consecutive occurrences"
- remove "consecutive"?
3.2. "If several extension header chains are observed in a Flow, each header
chain MUST be exported in a separate ipv6ExtensionHeaderCount IE."
- say whether or not the order of those IEs is important.
3.2 "the occurrences that are observed before the Fragment header and the
occurrences right after the Fragment header."
- singular, "the occurrence".
3.2 (Figure)
- please name/number the figure and move the bit numbers rightwards one place,
consistent with the figures in section 6.
- the count is limited to 8 bits, bu there was no previous mention of this. Say
what to do when the count is exceeded.
3.2 Data Type Semantics:
- this is not an identifier. It seems be a new type consisting of (type, count)
tuples.
3.3 e.g., ipv6ExtensionHeaderFull
- typo: it's ipv6ExtensionHeadersFull
3.3. ipv6ExtensionHeadersLimit Information Element
- Why use negative logic (ie, where "false" indicates a complete set of IPv6
headers). It would make more sense for this to be "true" when matching and
"false" when not matching.
3.3 See [RFC8883] for an example of IPv6 packets processing
- singular "packet processing"
3.4. However, it was regularly reported
- by who? Where? Cite references or it didn't happen!
3.4 "The ipv6ExtensionHeadersChainLength IE is used to report, in octets, the
length of an extension header chain observed in a Flow. The length is the sum
of the length of all extension headers of the chain."
- say whether multiple IEs are to be exported, one per chain. If so, then say
whether order is important.
4.1 Option number X is mapped to bit position "254 - X".
- please, NO! Nobody's going to do that. Please use the same encoding as in 3.1.
- BTW TCP option numbers begin at 0 so it should be "255 - X".
4.2. tcpSharedOptionExID Information Element
- From the description here, I did not understand how to encode the IE.
4.2 Expermients IDs ... (or 4-bute)
- typos
6.1 IPv6 Extension Headers
- this section is actually about "ipv6ExtensionHeadersFull"
6.1 This section provides few examples to illustrate the use of some IEs
defined in the document.
- move this text to section 6.
6.1 Figure 1
- there should be 256 bits, numbered 0 to 255.
- the numbering above the middle and right-most blocks is mis-aligned. Compare
with Figure 2.
6.1 Figure 2
- again there should be 256 bits, numbered 0 to 255.
- draw figures 1 and 2 as figure 3, with only one section of ellipsis.
- referring to section 9.1 of I-D.ietf-opsawg-ipfix-fixes] for the IPv6
Hop-by-Hop Options, Routing, and Destination Options headers bits:
1, HOP 0 Hop-by-hop option header
0, DST 60 Destination option header
5, RH 43 Routing header
- so please list the headers in order!
- this shows that the bits 0, 1, and 5 should be set - so the figure should
show "1 0 0 0 1 1" rather than "0|1|0|0|1|1|".
6.2. TCP Options
- Reword "Given TCP kind allocation practices"
- "Concretely, the tcpOptionsFull IE will be set to 15." --> no, "1|1|0|1|" = 8
+ 4 + 1 = 13.
8 TBD3 ipv6ExtensionHeaderLimit
- typo, it's "ipv6ExtensionHeadersLimit"
P.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
