Hi Paul, Following up on the remaining review for this document.
Thank you very much. Best regards, David Dong IANA Services Sr. Specialist On Mon May 13 13:22:17 2024, mohamed.boucad...@orange.com wrote: > Hi Paul, > > Thank you for the review. The changes can be tracked at: Diff: draft- > ietf-opsawg-ipfix-fixes-08.txt - draft-ietf-opsawg-ipfix- > fixes.txt<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf- > opsawg-ipfix-fixes&url_2=https://boucadair.github.io/simple-ipfix- > fixes/draft-ietf-opsawg-ipfix-fixes.txt> > > Please see inline for more context. > > 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 #1363822] Expert review for draft-ietf- > opsawg-ipfix-fixes (ipfix) > > > This document is simply too long to review. I'm about half way > through, and will not have time to complete the review before May > 10th. > > > > * In the TOC, all the OLD / NEW section names are distracting. It > would be much more readable if the TOC was limited to just two levels: > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 > > 3. Why An RFC is Needed for These Updates? . . . . . . . . . . . 6 > > 4. Update the Description . . . . . . . . . . . . . . . . . . . 6 > > 4.1. sourceTransportPort . . . . . . . . . . . . . . . . . . . 6 > > 4.2. destinationTransportPort . . . . . . . . . . . . . . . . 7 > > 4.3. forwardingStatus . . . . . . . . . . . . . . . . . . . . 8 > > > > * In the Introduction, "some other parts" lacks context unless the > reader is familiar with RFC9565, RFC7125, and the WG process that took > place. So simply say, "some parts": > > When OPSAWG was considering [RFC9565] which updates [RFC7125], the WG > > realized that some other parts of the IANA IP Flow Information Export > > (IPFIX) registry ... > > > > [Med] ACK. > > > * Typo in 4.1.2. NEW : > > See the assigned tranport protocol (e.g., TCP, UDP, DCCP, and > > SCTP) port numbers at https://www.iana.org/assignments/service- > > names-port-numbers. > > > Also, please retain the UDP, TCP, SCTP, DCCP ordering. Same for 4.2.2, > 4.4.2, and 4.5.2. > See the assigned tranport protocol (e.g., TCP, UDP, DCCP, and SCTP) > port numbers at > https://www.iana.org/assignments/service-names-port-numbers. > > [Med] ACK > > > * 4.2.2. NEW > > "destination" x2 : > Description: The destination port identifier in the transport protocol > header. For transport protocols such as > UDP, TCP, SCTP, and DCCP, this is the source port number given in the > respective header. This field MAY also > be used for future transport protocols that have 16-bit source port > identifiers. > > [Med] Good catch. Fixed. > > > * 4.4.2. NEW > > There's no mention of DCCP in the description, nor reference to > [RFC4340], though DCCP is mentioned in the last paragraph of > Additional Information. > > [Med] Already fixed that one when addressing Donald's review. > > > * 4.5.2. NEW > > Traffic is sent from a source port, not to it: > > The source port identifier to which the Exporting Process sends Flow > information. > > [Med] ACK. > > > There's no mention of DCCP in the description, nor reference to > [RFC4340], though DCCP is mentioned in the last paragraph of > Additional Information. > > [Med] Already fixed that one when addressing Donald's review. > > > > * 6.3.2. NEW > > No, it's the "flow end reason" registry: > > See the Classification Engine IDs registry available at > [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end- > reason]. > > > [Med] ACK. > > > * 6.4.2. New > > "See the NAT originating address realm registry at ..." > Additional Information: See the assigned NAT originating address realm > at > > [Med] ACK > > > * 6.5.2. New > > "See the NAT Event Type registry at" > Additional Information: See the assigned NAT Event Types at > > [Med] The OLD is correct, but I understand that echoing the registry > name is explicit that this is about "assigned xxx values". Went with > this modif. > > > * 6.6.2. NEW > > "See the firewallEvent registry at" > Additional Information: See the assigned firewall events at > > Same comment for many other sections. ie, where the text says, "Values > are listed in the xyz registry.", the Additional Information should > say, "See the xyz registry at ..." > > > [Med] ACK. > > > * 6.11.2 NEW > > Please append [RFC5102<https://www.iana.org/go/rfc5102>] here. > For the methods parameters, Information Elements are defined in the > information model document [RFC5102]. > > [Med] OK as that was the intent at the time. However, given that 5102 > is obsoleted, should we simply point to the registry itself instead of > 5102? > > > * Typo in 6.12.2. NEW : > > Additional Information: See the assigned emelement data types at > > [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix- > > information-element-data-types]. > > > > [Med] ACK. > > * 6.13.2. NEW > > The ; should be a . as "The special value" is a new sentence: > > subregistry; the special value 0x00 (default) is used > > [Med] ACK. > > > (Stopped at 6.14) > ____________________________________________________________________________________________________________ > 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
