Hi Paul, Thanks for the review.
Please see inline. Cheers, Med De : ipv6 <ipv6-boun...@ietf.org> De la part de Aitken, Paul Envoyé : vendredi 19 janvier 2024 11:58 À : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>; opsawg@ietf.org Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-06.txt 1. Introduction A brief overview of UDP option is provided in Section 3. Typo, "UDP options" (plural). [Med] ACK. The IE specified in Section 4.1 uses the new abstract data type defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh]. The unsigned256 type? It makes more sense to introduce a bitfield type. [Med] I think the use of unsigned256 is consistent with the current use in IP Flow Information Export (IPFIX) Entities (iana.org)<https://www.iana.org/assignments/ipfix/ipfix.xhtml> (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs having data semantic of flags. 3. UDP Options at a Glance Also, Section 4.3 specifies a new IPFIX to export observed ExIDs in the UEXP options. Something is missing here: "a new IPFIX IE to ...". [Med] Fixed. Only 16-bits ExIDs are supported. Clarify, "Only 16-bits ExIDs are supported in UDP." [Med] updated to « supported in [I-D.ietf-tsvwg-udp-options]." The motivation for exporting such data is similar to the one for exporting TCP options (tcpOptions) or IPv6 Extension Headers (ipv6ExtensionHeaders). Please state the motivation or include an xref where the motivation can be found. [Med] We may simply delete that sentence. 4.1 - 4.3 These definitions should be in the IANA section. 5. An Example Given UDP kind allocation in Section 10 of [I-D.ietf-tsvwg-udp-options] and the option mapping defined in Section 4.1, Section 4.1 of what? [Med] of this document. 4.1. udpOptions To cover the 0-255 kind range, up to 255 flags can be set in the value field. Up to 256 flags. [Med] ACK. For example, if only option kinds =< 32 are observed Conventionally "<=" is used. [Med] OK Abstract Data Type: unsigned256 It's not an integer, it's a bitfield. [Med] see above. 4.2 and 4.3 It would be better to spell out the names in full: udpExperimentalOptionSafeExID and udpExperimentalOptionUnsafeExID [Med] Expanded to udpSafeExperimentalOptionExID and udpUnsafeExperimentalOptionExID I would not have understand what these measure, nor how to encode them, without having first reviewed draft-ietf-opsawg-ipfix-tcpo-v6eh. Examples in section 5 would be useful. [Med] OK, will update the example. The octetArray type is especially confusing as these are really hextetArrays. [Med] Not sure we need a new data type here as octeArray is defined as follows: The octetArray data type has no encoding rules; it represents a raw array of zero or more octets, with the interpretation of the octets defined in the Information Element definition. 4.3. udpUnsafeExpOptionExID Description: Observed Expermients ID (ExIDs) in the UNSAFE Experimental option (UEXP, Kind=254). Typo, "Experiments". [Med] Fixed. P. On 18/12/23 19:22, Joe Clarke (jclarke) wrote: We'd like to kick off a [rather extended] WG LC on the three IPFIX-related "fixes" documents we have in the hopper. We've already requested some directorate reviews for these, and the authors feel they have stabilized well. Please review: 1. https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCMEo_jvU$> 2. https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCG_d35-j$> 3. https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCAzlAEMT$> And comment as to whether or not you feel they are in the right shape to progress to the IESG. We will run this LC until Jan 8 given that the holidays means some people will not be around. Also note that an IPR poll was conducted prior to adoption and no known IPR has been disclosed. Thanks. Joe _______________________________________________ IPFIX mailing list ip...@ietf.org<mailto:ip...@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCO14NBgv$ [ietf[.]org] ____________________________________________________________________________________________________________ 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
