Hi Med,
I think this is pretty much good to go except for some funny line wrapping and
indentation. It is probably worth fixing that in a -05 and then I'll kick off
IETF LC.
I.e.
Note also that [TCP-FLAGS] indexes the bit offset from the
most-significant
bit of octet 12 to the least-significant bit of octet 13 in the
TCP header,
Boucadair Expires 14 April 2024 [Page 4]
Internet-Draft tcpControlBits IPFIX October 2023
but the tcpControlBits is encoded as a regular unsigned 16 bit
integer. For example, a tcpControlBits Information Element set to
0x90 is used to report TCP control bits for a segment that has
CWR (Congestion Window Reduced) and ACK flag bits set (that is,
bit offset positions 8 and 11).
MSB LSB
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thanks,
Rob
-----Original Message-----
From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
Sent: Thursday, October 12, 2023 1:40 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 follow up.
Looks good to me. This is now fixed in draft-ietf-opsawg-rfc7125-update-04
which is available online.
Thanks.
Cheers,
Med
> -----Message d'origine-----
> De : Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>
> Envoyé : jeudi 12 octobre 2023 12:53
> À : BOUCADAIR Mohamed INNOV/NET
> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>;
> opsawg@ietf.org<mailto:opsawg@ietf.org>;
> draft-ietf-opsawg-rfc7125-update....@ietf.org<mailto:draft-ietf-opsawg-rfc7125-update....@ietf.org>
> Objet : RE: AD review of draft-ietf-opsawg-rfc7125-update-03
>
> 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<mailto:mohamed.boucad...@orange.com>
> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
> Sent: Wednesday, October 11, 2023 5:07 PM
> To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>;
> opsawg@ietf.org<mailto:opsawg@ietf.org>; draft-
> ietf-opsawg-rfc7125-update....@ietf.org<mailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fboucadair%2F-ipfix-rfc7125-
> update%2Fpull%2F4%2Ffiles&data=05%7C01%7Cmohamed.boucadair%40orange.co
> m%7C57ac4a1dc23840a993b508dbcb11670b%7C90c7a20af34b40bfbc48b9253b6f5d2
> 0%7C0%7C0%7C638327047822387444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> ata=9Q8QZr9caqNRiFtQgHLNHazvlgx0hJ9fyCZnGUndMCg%3D&reserved=0. Please
> let me know if any further change is needed.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>
> > Envoyé : mercredi 11
> > octobre 2023 16:39 À : opsawg@ietf.org<mailto:opsawg@ietf.org>;
> > draft-ietf-opsawg-rfc7125-update....@ietf.org<mailto: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%<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%25>
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C57ac4a1dc23840a993b
> 508dbcb11670b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63832704782
> 2387444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b4mx8fuSpmkU6uzcjsp
> o%2B04ZQfUYVxT1fojX888eUhE%3D&reserved=0.
> > 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.
____________________________________________________________________________________________________________
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
