Hi Med, This DISCUSS and the COMMENT from John came up again in the telechat earlier today.
This is clearly tripped up more than one person in their review process, so it is quite imaginable what it would do to an implementor. I do not have a good solution, and I am hoping this discussion comes up with a solution that is better than status quo. > On Jul 10, 2024, at 11:14 PM, mohamed.boucad...@orange.com wrote: > > Hi Paul, > > I have already clarified this point in a reply to John's comment. > > Let me clarify again: > > * Both ipv6ExtensionHeaders and tcpOptions were initially defined in RFC 5102 > * RFC 7012 obsoleted RFC 5102 and declared that: > > ## The IANA registry is for now the authoritative reference for these IEs: > > "[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." > > ## RFC 5102 provides the initial content of the registry > > "This information model is maintained as the IANA "IPFIX > Information Elements" registry, the initial contents of which were > defined by RFC 5102." > > or > > "The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the > current complete reference for IPFIX Information Elements. The > initial values for this registry were provided by [RFC5102]." The move to an IANA registry as the authoritative reference for the IEs is clearly the source of the problem. Is there something in the Updates to RFC 5102 that indicates that the registry has moved to IANA? Or do folks have to read RFC 7012 to realize that? Would the registry pointing to RFC 5102, which would in turn point to RFC 7012 help? > > * We can't update 7012 because: > > "Information Element definitions have been removed, as the reference > for these is now [IANA-IPFIX]; a historical note on categorizations > of Information Elements as defined in [RFC5102] has been retained > in Section 5." > > This is the reason we: > > * cite [IANA-IPFIX] when we first mentioned ipv6ExtensionHeaders and > tcpOptions in the doc. > * list [IANA-IPFIX] as normative But that may not be enough to satisfy the question that Paul is asking. Which RFC is being updated/obsoleted with the move to deprecate the ipv6ExtensionHeaders and tcpOptions IE. Does it make sense to update RFC 5102 so folks know to reference this document, even if it is obsoleted by RFC 7102? Cheers > > Cheers, > Med > >> -----Message d'origine----- >> De : Paul Wouters via Datatracker <nore...@ietf.org> >> Envoyé : jeudi 11 juillet 2024 03:48 >> À : The IESG <i...@ietf.org> >> Cc : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org; opsawg- >> cha...@ietf.org; opsawg@ietf.org; thomas.g...@swisscom.com; >> thomas.g...@swisscom.com >> Objet : Paul Wouters' Discuss on draft-ietf-opsawg-ipfix-tcpo- >> v6eh-17: (with DISCUSS) >> >> >> Paul Wouters has entered the following ballot position for >> draft-ietf-opsawg-ipfix-tcpo-v6eh-17: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free >> to cut this introductory paragraph, however.) >> >> >> >> ----------------------------------------------------------------- >> DISCUSS: >> ----------------------------------------------------------------- >> >> This specification deprecates the ipv6ExtensionHeaders >> IPFIX IE >> in favor of the new IEs defined in this document. >> >> I don't see which RFC those were in, because this document does >> not >> Update: or Obsolete: the RFC that defined the >> ipv6ExtensionHeaders IPFIX IE >> >> >> This specification deprecates the tcpOptions IE >> >> Same here. >> >> >> >> > > ____________________________________________________________________________________________________________ > 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. > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
