Hi Elwyn, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Elwyn Davies via Datatracker <noreply@xxxxxxxx> > Envoyé : samedi 28 octobre 2023 00:07 > À : gen-art@xxxxxxxx > Cc : draft-ietf-opsawg-rfc7125-update.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Genart last call review of draft-ietf-opsawg-rfc7125-update-05 > > Reviewer: Elwyn Davies > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > > Document: draft-ietf-opsawg-rfc7125-update-?? > Reviewer: Elwyn Davies > Review Date: 2023-10-27 > IETF LC End Date: 2023-10-26 > IESG Telechat date: 2023-11-30 > > Summary: > > The data specification is good to go [Med] Cool, thanks. , but there are some difficulties > (in my > view) with status and the nature of some text that is intended to be a > data description but actually provides normative rules for a protocol > using the data. Looking at the IPFIX IANA record, it may be worth > checking that there are not additional entries that could be > vulnerable in a similar way to the Control Flags. [Med] That's exactly what the WG did; please see slide 3 of https://datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-updates-and-next-steps-for-rfc7125-update-and-companion-i-ds-00. I also noted that > there are some references to RFCs in the record that could do with > added RFC numbers. > > Major issues: > > Status of documents: I note that this is intended to be a standards > track document that obsoletes an informational document (RFC 7125) > which in turn updated a standards track document (RFC 5102) which has > in turn been sort of 'obsoleted' by RFC 7012. Since RFC 5102 remains > as a historic reference and is mentioned in RFC 7012, I think this > draft should specify that it updates RFC > 7012 since someone using the IPFIX data structures etc should be aware > of this. [Med] This draft doesn't update RFC7012. Please note that Section 5 of 7012 says explicitly the following: [IANA-IPFIX] is now the normative reference for IPFIX Information Elements. When [RFC5102] was published, it defined, in its Section 5, the initial contents of that registry. > Also I would say that this draft goes further than making RFC 7125 > obsolete - RFC 7125 should become Historic. I take it this could be > specifed in this document. > > S3: In essence this document contains a data description intended to > update a part of the data description in the IANA record of "IP Flow > Information Export > (IPFIX) Entities". However, the four paragraphs of Description in S3 > starting > at para 4 ("As the most significant...") contain prescriptive > normative language that purports to affect the behaviour of the > protocol that is intending to use this data description (e.g., para 5 > says > > All TCP control bits (including those unassigned) MUST be exported > as observed in the TCP headers of the packets of this Flow. ) > > Is this a legitimate usage? [Med] No sure what the concern is with that normative text. I note that this language is (I think) > the > 'stronger requirement language' mentioned in s5, para 1. [Med] Yes This issue > is closely tied to the document status issue above. > > Minor issues: None > > Nits/Editorial comments: > > s1, para 3 > OLD: > However, that update is still problematic for interoperability > because a value was deprecated since then (Section 7 of [RFC8311]) > and, therefore, [RFC7125] risks to deviate from the authoritative > TCP > registry [TCP-FLAGS]. > NEW: > However, that update may still be problematic for interoperability > because a flag value was added prior to the release of [RFC9293] > for > experimental purposes but has since been deprecated (see Section 7 > of > [RFC8311]). [RFC7125] pre-dates this deprecation and explicitly > mentions the > deprecated flag hence deviating from the authoritative TCP registry > [TCP-FLAGS]. Any future changes to the control flags would risk > additional > deviations unless [RFC7125] were updated in the same way. > END > > s4: IANA should also add a reference to this document. > > [Med] Section 4 points to Section 3, which in turn includes the following: = References: [RFC9293][This-Document] = ____________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
