Hi Paul, Thank you for the careful review, as usual. Much appreciated!
The diff to track all the changes (including other reviewers) can be seen at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh-11.txt - draft-ietf-opsawg-ipfix-tcpo-v6eh.txt<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ipfix-tcpo-v6eh&url_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt> Please see inline. Cheers, Med De : Aitken, Paul <pait...@ciena.com> Envoyé : mercredi 8 mai 2024 11:42 À : drafts-expert-review-comm...@iana.org; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : ie-doct...@ietf.org; opsawg <opsawg@ietf.org> Objet : Re: [Ie-doctors] [IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix) * 1.1 Add "the": Section 3 addresses these issues. Also, the ipv6ExtensionHeaders IPFIX IE is deprecated in favor of the new IEs defined in this document. [Med] ACK. * 1.2 Add "the" : The specification of the tcpOptions IPFIX IE (209) does not: [Med] ACK. Should "option" be "options"? : * Describe how some observed TCP options in a Flow can be exported using IPFIX. Only TCP options having a Kind <= 63 can be exported in a tcpOptions IE. [Med] Yes. Fixed. Add "the" : Section 4 addresses these issues. Also, the tcpOptions IE is deprecated in favor of the new IEs defined in this document. [Med] OK * 2 Is the indentation correct here? : Extension header chain: Refers to the chain of extension headers that are present in an IPv6 packet. This term should not be confused with the IPv6 header chain, which includes the IPv6 header, zero or more IPv6 extension headers, and zero or a single Upper-Layer Header. [Med] Yes * 3.2 "the same" : Description: The number of consecutive occurrences of the same extension header type in a Flow. [Med] ACK * 3.4 Add "ipv6ExtensionHeaderTypeCountList" : If several extension header chains are observed in a Flow, each header chain MUST be exported in a separate ipv6ExtensionHeaderTypeCountList IE. [Med] ACK. * 3.5 What if both ipv6ExtensionHeadersFull and ipv6ExtensionHeaderTypeCountList are exported? [Med] The present of the limit will still be meaningful and reflects how ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList. [Later] this is discussed in section 5.1, but that wouldn't be known from reading the IPFIX registry alone. The fact that these IEs are mutually exclusive should be added to both IE descriptions. Description: When set to "false", this Information Element indicates that the exported extension headers information (e.g., ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does not match the full enclosed extension headers [Med] Not sure we need to put all the ops details in the description. * 3.6 Change "identifying" to "to identify" : Exporting such information might help to identify root causes of performance degradation, including packet drops. How would we know which ipv6ExtensionHeadersChainLength IE corresponds with which header chain? If several extension header chains are observed in a Flow, each header chain length MUST be exported in a separate ipv6ExtensionHeadersChainLength IE. [Med] Good point. Added a new list IE to correlate these two as needed. * 5.1 "Will" sounds like a detail of a particular implementation. More generally this should be a "MUST", a "SHOULD", or a "MAY": If an implementation determines that an observed packet of a Flow includes an extension header that it does not support, then the exact observed code of that extension header will be echoed in the ipv6ExtensionHeaderTypeCountList IE (Section 3.4). [Med] Went with MUST * 5.2 What does this mean? : If a TCP Flow contains packets with a mix of 2-byte and 4-byte Experiment IDs, the same Template Record is used with both tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs. [Med] both IEs will be present. * 6.1 It would be helpful to list the corresponding header bit values, and to list them in order (0, 1, 5) rather than 1, 5, 0: Figure 1 provides an example of reported values in an ipv6ExtensionHeadersFull IE for an IPv6 Flow in which only the IPv6 Destination Options header (0) is observed. Figure 2 provides another example of reported values in an ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the IPv6 Hop- by-Hop Options (1), Routing (5), and Destination Options (0) headers are observed. [Med] ACK. * 6.2 It would be helpful to list the corresponding header bit values: Figure 3 shows an example of reported values in a tcpOptionsFull IE for a TCP Flow in which End of Option List (0), Maximum Segment Size (2), and Window Scale (3) options are observed. Please use the full 16-bit value, "0348" : 1. The tcpSharedOptionExID16 IE set to 0x0348454E to report observed 2-byte ExIDs: HOST_ID and TCP-ENO ExIDs. [Med] ACK * 8.1 It's unclear which IE "this IE" is. eg, write "IE 209" if that's what's meant. * Update the tcpOptions IE (209) entry by marking it as deprecated in favor of the tcpOptionsFull IE defined in this document. This note should also be echoed in the "Additional Information" of this IE. [Med] ACK. * 8.4 This section sets up a potential conflict: what would happen if a new code was assigned to an IPv6 EH in [IANA-EH], but the expert reviewers disagreed with adding it to IPFIX? [Med] There is no conflict: the default will be to automatically mirror assignments. DE review is to cover corner cases where a request is made to directly touch the IPFIX registry. Section 1.1 said, "how to automatically update the IANA IPFIX registry". Is expert review contrary to an automatic update? [Med] DEs are not involved in such automatic assignements. * 8.4.1. Typo in Initial Values: +-----+-------+----------+-------------------------+---------------+ | 1 | HOP | 0 | Pv6 Hop-by-Hop Options | This-Document | +-----+-------+----------+-------------------------+---------------+ [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 To unsubscribe send an email to opsawg-le...@ietf.org
