Hi Wes, Please see inline.
Cheers, Med De : Wesley Eddy <w...@mti-systems.com> Envoyé : mardi 16 janvier 2024 16:09 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; 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
