Hi Med, WG, Here is my AD review of draft-ietf-opsawg-rfc7125-update-03.
Moderate level comments:
(1) p 3, sec 3. The tcpControlBits Information Element
If exported as a single octet with reduced-size encoding, this
Information Element covers the low-order octet of this field
(i.e., bit offset positions 8 to 15) [TCP-FLAGS]. A collector
receiving this Information Element with reduced-size encoding must
not assume anything about the content of the four bits with bit
offset positions 4 to 7.
I find that I'm somewhat confused as to which octet is low-order or high-order
and whether the actual TCP flags are indexed from 0 to 7 or 8 to 15, and hence
what actual bit order the fields are within the exported IPFIX field. I think
that it would be very helpful, possibly by an example, to ensure that no-one
can interpret this the wrong way. E.g.,
https://www.ibm.com/docs/en/npi/1.3.0?topic=versions-ipfix-information-elements,
indexes FIN as having bit value 0x0001, but the TCP Header Flags registry
indicates that the Bit Offset is 15, so I would naturally assume that it has
the value 1 << 15 ... Would having some text to clarify this help? And
perhaps a concrete example of what would be exported, to illustrate the point?
Minor level comments:
(2) p 0, sec
RFC 7125 revised the tcpControlBits IP Flow Information Export
(IPFIX) Information Element that was originally defined in RFC 5102
to reflect changes to the TCP header control bits since RFC 793.
However, that update is still problematic for interoperability
because some flag values were deprecated since then.
Suggest: "... because some flag values have subsequently been deprecated."
Nit level comments:
(3) p 0, sec
This document removes stale information from the IPFIX registry and
avoiding future conflicts with the authoritative TCP Header Flags
registry.
I suggest s/avoiding/avoids/
Regards,
Rob
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
