Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Re-,
What about adding the following under "Operational Considerations":
NEW:
Implementations of tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs are
assumed to be provided with a list of valid Experiment IDs {{IANA-TCP-EXIDs}}.
How that list is maintained is implementation-specific. Absent that list, an
implementation can't autonomously determine whether an ExID is present and, if
so, whether it is 2- or 4-byte length.
Cheers,
Med
> -Message d'origine-
> De : Wesley Eddy
> Envoyé : mercredi 17 janvier 2024 14:25
> À : BOUCADAIR Mohamed INNOV/NET ;
> tsv-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org;
> opsawg@ietf.org
> Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-05
>
> On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote:
> > [Med] This can be part of regular code updates. Please note
> that this
> > is not unusual in ipfix (see for example ipv4Options, natevent,
> etc.
> > in
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml=05%7C02%7C
> mohamed.boucadair%40orange.com%7C69fc748e4be24a2aa56808dc175fb703
> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638410947053802590%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=eZcICzC8rw%2BLDau
> B82e4BxG2PkB5X3LRQO%2BDCUmGQyU%3D=0 which depend on an
> IANA registry).
>
> Ok; do you think the document should explain this in a sentence
> or two for implementers?
>
> If they are not all familiar with details of how ExIDs are used,
> then it seems like a stretch to assume they'll all understand
> that products need to be designed to periodically update ExID
> definitions.
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
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote: [Med] This can be part of regular code updates. Please note that this is not unusual in ipfix (see for example ipv4Options, natevent, etc. in https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on an IANA registry). Ok; do you think the document should explain this in a sentence or two for implementers? If they are not all familiar with details of how ExIDs are used, then it seems like a stretch to assume they'll all understand that products need to be designed to periodically update ExID definitions. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Hi Wes, Please see inline. Cheers, Med De : Wesley Eddy Envoyé : mardi 16 janvier 2024 21:21 À : BOUCADAIR Mohamed INNOV/NET ; tsv-...@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; opsawg@ietf.org Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05 On 1/16/2024 11:10 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Are you expecting the implementation to have an exhaustive list of all of the ExIDs in use to understand the difference between 2 and 4 byte usage? [Med] Yes because otherwise an implem can’t unambiguously identify and extract ExIDs. We do provide a pointer to the registered ExIDs: == Additional Information: See assigned ExIDs at [IANA-TCP-EXIDs]. == Please let me know if you still think a clarification is needed to the draft. Thanks. New ExIDs are able to be added to the IANA registry at any time, just via requesting them. Is an IPFIX implementation expected to periodically fetch the registry and reload its known values? [Med] This can be part of regular code updates. Please note that this is not unusual in ipfix (see for example ipv4Options, natevent, etc. in https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on an IANA registry). 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
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
On 1/16/2024 11:10 AM, mohamed.boucad...@orange.com wrote: Are you expecting the implementation to have an exhaustive list of all of the ExIDs in use to understand the difference between 2 and 4 byte usage? */[Med] Yes because otherwise an implem can’t unambiguously identify and extract ExIDs. We do provide a pointer to the registered ExIDs:/* *//* */==/* Additional Information: See assigned ExIDs at [IANA-TCP-EXIDs]. */== /* *//* */Please let me know if you still think a clarification is needed to the draft. Thanks./* New ExIDs are able to be added to the IANA registry at any time, just via requesting them. Is an IPFIX implementation expected to periodically fetch the registry and reload its known values? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Hi Wes, Please see inline. Cheers, Med De : Wesley Eddy Envoyé : mardi 16 janvier 2024 16:09 À : BOUCADAIR Mohamed INNOV/NET ; tsv-...@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; opsawg@ietf.org Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05 The changes look good to me; I just want to make sure you understand one of my questions that doesn't look like it was clear enough: On 1/15/2024 4:13 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: - The way an implementation understands the TCP ExIDs may benefit from slightly more explanation: -- In 4.2 and 4.3, is the idea that the implementation is just sampling the 16 or 32 bits following the experimental option kind being indicated, and assuming those 2 or 4 bytes to be ExIDs? From Section 6.2, I got the sense that the implementation is aware of particular ExID values specifically, to know if they should be reported as 2 or 4 byte values. [Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are reported in tcpSharedOptionExID32. Are you expecting the implementation to have an exhaustive list of all of the ExIDs in use to understand the difference between 2 and 4 byte usage? [Med] Yes because otherwise an implem can’t unambiguously identify and extract ExIDs. We do provide a pointer to the registered ExIDs: == Additional Information: See assigned ExIDs at [IANA-TCP-EXIDs]. == Please let me know if you still think a clarification is needed to the draft. Thanks. I don't quite understand how this is supposed to work at the sampling point, since it's the TCP implementation that interprets the option and determines whether it is to be interpreted as containing (1) no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not available within the protocol to a third party. The third party would need a list of ExIDs in-use in order to understand them. 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
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
The changes look good to me; I just want to make sure you understand one of my questions that doesn't look like it was clear enough: On 1/15/2024 4:13 AM, mohamed.boucad...@orange.com wrote: - The way an implementation understands the TCP ExIDs may benefit from slightly more explanation: -- In 4.2 and 4.3, is the idea that the implementation is just sampling the 16 or 32 bits following the experimental option kind being indicated, and assuming those 2 or 4 bytes to be ExIDs? From Section 6.2, I got the sense that the implementation is aware of particular ExID values specifically, to know if they should be reported as 2 or 4 byte values. [Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are reported in tcpSharedOptionExID32. Are you expecting the implementation to have an exhaustive list of all of the ExIDs in use to understand the difference between 2 and 4 byte usage? I don't quite understand how this is supposed to work at the sampling point, since it's the TCP implementation that interprets the option and determines whether it is to be interpreted as containing (1) no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not available within the protocol to a third party. The third party would need a list of ExIDs in-use in order to understand them.___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Hi Wes, Thank you for the review. The changes to take into account your review can be seen at: https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/commit/8bd7d7f92180a8eeaeb9ce13c0028a5c698b1738 Please see inline for more context. Cheers, Med > -Message d'origine- > De : Wesley Eddy via Datatracker > Envoyé : mardi 2 janvier 2024 19:20 > À : tsv-...@ietf.org > Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; > opsawg@ietf.org > Objet : Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh- > 05 > > Reviewer: Wesley Eddy > Review result: Ready with Issues > > Comments: > > - The document is well-written and easy to read. > > - Section 6 is really nice and helpful! > > Issues: > > - The way an implementation understands the TCP ExIDs may benefit > from slightly more explanation: > -- In 4.2 and 4.3, is the idea that the implementation is just > sampling the > 16 or 32 bits following the experimental option kind being > indicated, and > assuming those 2 or 4 bytes to be ExIDs? From Section 6.2, I > got the sense > that the implementation is aware of particular ExID values > specifically, to > know if they should be reported as 2 or 4 byte values. [Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are reported in tcpSharedOptionExID32. -- Will > any values > present be reported, or only those which show up in the IANA > registry? I > assume any values will be reported, even if they are not > registered ExIDs, > since the registry changes over time, and implementations > probably don't grab > periodic updates of it. [Med] Any observed ID must be reported independent of whether the value is registered or not. Made "s/Observed/Any observed" in the relevant sections. > > Questions: > > - This may be alright, but it seemed to me like for > interoperability there should be some way to indicate what an > implementation of this IE is doing with regard to this text in > Section 3.1 (where maybe "may" should be "MAY"?): > > 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. > [Med] I went with this change: s/may be aggregated/MAY be aggregated > - In Section 3.3, it seems backwards to me that this Limit IE > being True means that no limitation was applied, whereas False > means that it was limited. If the WG and implementers are okay > with this, I'm not questioning it, but it seems odd, so I just > wanted to make sure this was the intention. > [Med] ACK. > Nits: > > - The first paragraph in section 1 should probably mention the > specific RFC(s) for the specified IEs with the noted problems, > since it sounds from the beginning paragraphs of section 3 and 4 > like some of those are already being addressed by the separate > ipfix-fixes document. [Med] Added a reference to the IANA registry as that is the normative ref for these IEs as per the following from RFC7012: [IANA-IPFIX] is now the normative reference for IPFIX Information Elements. When [RFC5102] was published, it defined, in its Section 5, the initial contents of that registry. > > - Section 1.1, "do no correspond" -> "do not correspond" [Med] Fixed > 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
[OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Reviewer: Wesley Eddy Review result: Ready with Issues Comments: - The document is well-written and easy to read. - Section 6 is really nice and helpful! Issues: - The way an implementation understands the TCP ExIDs may benefit from slightly more explanation: -- In 4.2 and 4.3, is the idea that the implementation is just sampling the 16 or 32 bits following the experimental option kind being indicated, and assuming those 2 or 4 bytes to be ExIDs? From Section 6.2, I got the sense that the implementation is aware of particular ExID values specifically, to know if they should be reported as 2 or 4 byte values. -- Will any values present be reported, or only those which show up in the IANA registry? I assume any values will be reported, even if they are not registered ExIDs, since the registry changes over time, and implementations probably don't grab periodic updates of it. Questions: - This may be alright, but it seemed to me like for interoperability there should be some way to indicate what an implementation of this IE is doing with regard to this text in Section 3.1 (where maybe "may" should be "MAY"?): 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. - In Section 3.3, it seems backwards to me that this Limit IE being True means that no limitation was applied, whereas False means that it was limited. If the WG and implementers are okay with this, I'm not questioning it, but it seems odd, so I just wanted to make sure this was the intention. Nits: - The first paragraph in section 1 should probably mention the specific RFC(s) for the specified IEs with the noted problems, since it sounds from the beginning paragraphs of section 3 and 4 like some of those are already being addressed by the separate ipfix-fixes document. - Section 1.1, "do no correspond" -> "do not correspond" ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
