Hi Paul, Thank you for the careful review and good suggestions. Went with almost all of them.
Please see inline for more context. Cheers, Med De : ipv6 <[email protected]> De la part de Aitken, Paul Envoyé : lundi 22 janvier 2024 22:50 À : Joe Clarke (jclarke) <[email protected]>; [email protected] Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes Abstract The updates are also meant to bringing some consistency among the entries of the registry. Typo, "meant to bring in". [Med] OK. 1. Introduction As the OPSAWG is currently considering This will soon become outdated. Consider, "When OPSAWG was considering ..." [Med] OK not adequately specified any longer "nolonger adequately specified" [Med] OK This document intends to update the IANA registry and bringing some consistency among the entries of the registry. Typo, "bring". [Med] OK As discussed with IANA Say when and/or where. [Med] updated the text to indicate that this was during the publication process of RFC9487. * Miscellaneous updates that fix broken pointers, orphan section references, etc. (Section 7). Typo, "orphaned". 4.1.2. Updates to the ipv6ExtensionHeaders Description Consider making "OLD" into 4.1.2.1 and "NEW" into 4.1.2.2. Likewise for all the other OLD / NEW sections - its easier to read now, and will be easier to xref in future. [Med] Good suggestion. Fixed. Additional Information: See RFC Errata 1738. Please restore the xref. [Med] OK. The following drawing indicates the position of each bit in the encoding of the Information Element. No, not any more - so this should be removed. [Med] It is useful as it indicates the bit position that is then referred to in the new IANA registry. Updated the figure to make that clearer. This IE is used only when the observed extension headers are in the 0-31 range. Consider deprecating this IE in favour of ipv6ExtensionHeadersFull. [Med] Seems reasonable, but would like to hear more from the WG. 4.2.1. Issues Only options having a kind =< 63 can be included in a tcpOptions IE. Conventionally, "<= 63". [Med] OK 4.2.2. Update the Description of the tcpOptions IE This information element is used only when the observed kinds are within the 0-63 range. If not, the tcpOptionsFull IE Consider deprecating this IE in favour of tcpOptionsFull. [Med] Seems reasonable, but would like to hear more from the WG. 4.3. forwardingStatus In particular, the registered Abstract Data Type is unsigned8, while it must be unsigned32. Why must it be? [Med] As per the definition in RFC7270. Future versions may be defined to associate meanings with the remaining bits. This is an old Cisco NetFlow compatible IE. It seems unlikely that there would be any future versions. If there were, a new IE should be defined. Therefore it seems better to leave it as an unsigned8 and correct RFC 7270. [Med] I prefer to maintain the current text in the draft. unsigned8 will be used anyway because of the reduced-encoding. See the Forwarding Status sub-registries at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status An xref would be shorter and neater, eg "See the Forwarding Status sub-registries at [FORWARDING-STATUS]". [Med] Agree but we are using the same format as it appears in the IANA registry. - Additional Information: See "NetFlow Version 9 Flow-Record Format" (CCO-NF9FMT). "CCO-NF9FMT" makes no sense here. It's an xref in the IANA registry, so make it an xref in this document. [Med] Done. 6. Consistent Citation of IANA Registries This document requests IANA to update [IANA-IPFIX] for each of the IE entries listed in the following subsections. This does not explain the changes or why they are required. It's necessary for the reader to individually compare each "old" and "new" section. [Med] We don't repeat that here because we do already have the following in the introduction: * Updates that are meant to ensure a consistent structure when calling an existing IANA registry (Section 6). Rather than writing an explanation for each change as was done in each 4.x.1 sub-section, a single note here could indicate that in each case the updates move the URLs into the Additional Information section. 6.1. mplsTopLabelType This text has been omitted from "NEW" : See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values]. [Med] This one was removed on purpose as the assigned values are provided in the IANA IPFIX registry and there is no explicit mapping between the two registries. 6.2. classificationEngineId - Additional Information: See https://www.iana.org/assignments/i pfix/ipfix.xhtml#classification-engine-ids. Is it possible to prevent the URL from breaking across the "ipfix" word? [Med] Will see how to fix that. 6.3. flowEndReason * OLD: - Additional Information: There is no existing "Additional Information" for this IE. I appreciate that the intention may have been to indicate that the section is blank. However it misleadingly appears as though some text is missing, so it would be better not to include it at all. Likewise for many of the subsequent sections. [Med] You got the intent, but I think you have a fair comment. Removed all empty "Additional Information". 6.10. natType Please take the opportunity to add the missing description, eg "This element identifies the type of NAT applied to packets of the flow." [Med] Thanks. Went for: « This Information Element identifies the NAT type applied to packets of the Flow.". Note: This change also corrects errors in the pointers provided NAT46/NAT64. Need to ensure IANA doesn't add that to the registry. [Med] Changed to "Note to IANA". Will take care of that when reviewing IANA actions. 6.12. informationElementDataType - Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract Please correct the "element.These" typo. [Med] Fixed 6.19. valueDistributionMethod - Additional Information: See the assigned distributed methods This should be "- Additional Information: See the assigned value distribution methods" [Med] Fixed 7. Misc Again, it's difficult to see what changed in each section and tedious to compare the OLD/NEW to find out. [Med] That's covered by this generic text in the intro: * Miscellaneous updates that fix broken pointers, orphaned section references, etc. (Section 7). 8. Security Considerations Explicitly say that there are no changes. [Med] OK. 9.1. IPFIX Subregistry for IPv6 Extension Headers It's strange to list all the required changes neatly in sections 4 through 7, then plop this into the IANA section. [Med] That's OK as this is about new IANA actions. a free bit is selected by IANA More specifically, "the next available free bit is selected by IANA" (NB also in the "Note:"). [Med] OK 2 NoNxt 59 No Next Header for IPv6 The indentation of "59" is wrong. [Med] Fixed P. ____________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
