Hi Paul, Please let me know if this change addresses your DISCUSS on the document. Thanks.
> On Jul 22, 2024, at 3:32 AM, [email protected] wrote: > > Hi Mahesh, all, > > Thanks for sharing this update. > > == > The solution we came up with is for IANA to list the three drafts, RFC 5102, > RFC 7012, and draft-ietf-opsawg-ipfix-tcpo-v6eh (when it is approved) in the > IANA registry for the IEs that are being either deprecated or added. In > addition, IANA should declare on the top of the registry (if it does not > already), that it is the authoritative source for the registry. > == > > Made the following changes: > > Updates IPv6/TCP I-D with more notes to cite > 5102/7012/RFC-to-be-draft-ietf-opsawg-ipfix-tcpo-v6eh: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-18 > > <https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-18>. > Updated the simple fixes I-D to add a new note under the IEs subregistry: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-fixes-12 > <https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-fixes-12>. > This is to address the second part of the feedback above. A note already > exists at the top level that 5102 is obsoleted by 7012, though. > > Cheers, > Med > > De : Mahesh Jethanandani <[email protected]> > Envoyé : lundi 22 juillet 2024 07:54 > À : Benoit Claise <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Paul Wouters > <[email protected]>; The IESG <[email protected]>; > [email protected]; opsawg-chairs > <[email protected]>; [email protected] > Objet : Re: [OPSAWG]Re: Paul Wouters' Discuss on > draft-ietf-opsawg-ipfix-tcpo-v6eh-17: (with DISCUSS) > > > Hi Benoit, > > This came up in the IESG meeting earlier today along with folks from IANA. > > The solution we came up with is for IANA to list the three drafts, RFC 5102, > RFC 7012, and draft-ietf-opsawg-ipfix-tcpo-v6eh (when it is approved) in the > IANA registry for the IEs that are being either deprecated or added. In > addition, IANA should declare on the top of the registry (if it does not > already), that it is the authoritative source for the registry. > > Having agreed upon, one has to say that RFC 7012 should have never delegated > the authority of the registry to the registry. It is odd that the registry is > the authoritative source for itself. But what is done cannot be undone, and > we are going to have to live with it. > > Cheers. > > > On Jul 12, 2024, at 2:46 PM, Benoit Claise <[email protected] > <mailto:[email protected]>> wrote: > > Dear all, > > It goes without saying that I agree with Med here. > > Regards, Benoit > > On 7/11/2024 7:58 PM, [email protected] > <mailto:[email protected]> 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 <[email protected]> > <mailto:[email protected]> > Envoyé : jeudi 11 juillet 2024 18:27 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > <mailto:[email protected]> > Cc : Paul Wouters <[email protected]> <mailto:[email protected]>; The > IESG <[email protected]> <mailto:[email protected]>; > [email protected] > <mailto:[email protected]>; opsawg-chairs > <[email protected]> <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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, [email protected] > <mailto:[email protected]> 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 <[email protected] <mailto:[email protected]>> > Envoyé : jeudi 11 juillet 2024 03:48 > À : The IESG <[email protected] <mailto:[email protected]>> > Cc : [email protected] > <mailto:[email protected]>; opsawg- > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > > > > > > > ____________________________________________________________________________________________________________ > 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 > [email protected] <mailto:[email protected]> > > > > > > > ____________________________________________________________________________________________________________ > 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 [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
