Hi Med, I would suggest that you have a short meeting in Vancouver to sort this out. I would invite Roman in addition to Paul so you can clear all your DISCUSS.
> On Jul 11, 2024, at 10:58 AM, mohamed.boucad...@orange.com wrote: > > Hi Mahesh, > > An implementer that looks in 5102 will be forwarded to 7012 because there is > appropriate metadata in 5102 that says that spec is superseded/obsoleted by > 7012. Like any other RFC with that metadata, there is no note that explicits > which aspects is obsoleted (or updated in case of updated-by). Readers have > to look into 7012 which clearly and explicitly list the changes and how the > registry should be handled in the future. > > I never saw an update to an obsoleted RFC. IMO, it does not make sense to go > that way. > > We can add a note with a summary to help readers navigate with all these. > > Cheers, > Med > > De : Mahesh Jethanandani <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>> > Envoyé : jeudi 11 juillet 2024 18:27 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com>> > Cc : Paul Wouters <paul.wout...@aiven.io <mailto:paul.wout...@aiven.io>>; The > IESG <i...@ietf.org <mailto:i...@ietf.org>>; > draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org > <mailto:draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org>; opsawg-chairs > <opsawg-cha...@ietf.org <mailto:opsawg-cha...@ietf.org>>; opsawg@ietf.org > <mailto:opsawg@ietf.org> > Objet : Re: [OPSAWG]Re: Paul Wouters' Discuss on > draft-ietf-opsawg-ipfix-tcpo-v6eh-17: (with DISCUSS) > > > 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 > <mailto: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 <mailto:nore...@ietf.org>> > Envoyé : jeudi 11 juillet 2024 03:48 > À : The IESG <i...@ietf.org <mailto:i...@ietf.org>> > Cc : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org > <mailto:draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org>; opsawg- > cha...@ietf.org <mailto:cha...@ietf.org>; opsawg@ietf.org > <mailto:opsawg@ietf.org>; thomas.g...@swisscom.com > <mailto:thomas.g...@swisscom.com>; > thomas.g...@swisscom.com <mailto: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 <mailto:mjethanand...@gmail.com> > > > > > > > ____________________________________________________________________________________________________________ > 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
