Hi Med, I still think that there needs to be a more explicit statement. E.g., the description of the tcpControlBits talks about setting it to one if the bit is set, and then references the "TCP Header Flags". So I think that you should add something like the following: "Note, the TCP-FLAGs registry indexes the bit offset from the most-significant-bit of octet 12 to the least-significant bit of octet 13 in the TCP header, but the tcpControlBits are encoded as a regular unsigned 16 bit integer" ... then you could include your example. ... I think that it would also be helpful for you example to indicate what value would actually be seen on the wire in the IPFIX export for the example that you give.
Thanks, Rob -----Original Message----- From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Sent: Wednesday, October 11, 2023 5:07 PM To: Rob Wilton (rwilton) <rwil...@cisco.com>; opsawg@ietf.org; draft-ietf-opsawg-rfc7125-update....@ietf.org Subject: RE: AD review of draft-ietf-opsawg-rfc7125-update-03 Hi Rob, Thanks for the review. I agree having an example is useful to avoid that bit offset is interpreted as bit value. We do having the following in the introduction to basically say that we are echoing what is in RFC9293 about the meaning of offet: Also, Section 6 of [RFC9293] introduces "Bit Offset" to ease referencing each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of [RFC9293]). A PR to take into account your review can be seen at: https://github.com/boucadair/-ipfix-rfc7125-update/pull/4/files. Please let me know if any further change is needed. Cheers, Med > -----Message d'origine----- > De : Rob Wilton (rwilton) <rwil...@cisco.com> > Envoyé : mercredi 11 octobre 2023 16:39 > À : opsawg@ietf.org; draft-ietf-opsawg-rfc7125-update....@ietf.org > Objet : AD review of draft-ietf-opsawg-rfc7125-update-03 > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ibm.com%2Fdocs%2Fen%2Fnpi%2F1.3.0%3Ftopic%3Dversions-ipfix- > information- > elements&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb6a953e85efa4 > 074878808dbca67cfdc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63832 > 6319436299870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ya911%2BVKxHs > NYQRvDhVrlN3IpoLbcmI56et409w%2F0sA%3D&reserved=0, 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
