Hi Tom, Can you please clarify why that section is "a nonsense"? As indicated in the write-up, that section includes sufficient information to proceed with the IANA assignments. The I-D cites itself as the codpoints requester, while it cites the RFCs that define the related mechanisms as the authoritative references. Citing RFC7012 here is not useful. The I-D includes required information taking into account the discussion with the IE experts and IANA. Hence the additional column. Please note that it is not the job of this I-D to fix issues related to the target registry. It is thus out of scope to discuss changing pointers to 5102 to 7012. FYI, 7012 discusses why reference to 5102 is maintained in the registry. Thank you. Cheers, Med > -----Message d'origine----- > De : last-call [mailto:last-call-bounces@xxxxxxxx] De la part de tom > petch > Envoyé : mercredi 7 juillet 2021 10:46 > À : last-call@xxxxxxxx > Cc : draft-ietf-opsawg-ipfix-mpls-sr-label-type@xxxxxxxx > Objet : Re: [Last-Call] Last Call: <draft-ietf-opsawg-ipfix-mpls-sr- > label-type-06.txt> (Export of MPLS Segment Routing Label Type > Information in IP Flow Information Export (IPFIX)) to Informational > RFC > > The IANA Considerations in this I-D are a nonsense; the I-D should > not be published. > > I commented on this on the OPSAWG list and the document shepherd > essentially agreed with me that the IANA Considerations are rubbish > and pointed me to the Shepherd write-up which describes how this has > been discussed with IANA and with IPFIX experts (the registry is > Expert > Review) and an agreement has been reached as to what IANA should do > instead of what is described in this I-D; this would address some > but not all of my comments and would IMHO introduce a further error. > > So publishing this I-D would leave a trail of misinformation to > confuse those that come after. > > My specific comments were > > "2) The existing registry, and indeed the instructions setting up > thereof, specifies three columns, Value Description Reference This > I-D adds a fourth column, Requester What happens to that column for > existing entries? > > 3) The Reference column for the existing entries points to RFC5102, > the January 2008 Information Model for IPFIX; that RFC is obsoleted > by > RFC7012 which is the reference which IANA gives for the registry as > a whole (which seems a good choice). For the new four entries here, > the Reference is specified to be the RFC that defines the protocol > which sets the MPLS label, nothing to do with the IPFIX RFC and > nothing to do with this I-D in Last Call. Not exactly wrong, but > seems inconsistent. > Perhaps replace 5102 with 7012, make the Reference column for the > new four values this I-D and make this I-D provide the link back to > the protocol RFC (which sections 1 and 2 probably do already) and > eliminate the fourth column. > > I disagree with the Shepherd writeup where it renames the Reference > column to be something else. Reference is something widely used and > well understood. AFAICT the RFC that created the registry (RFC5102) > does not specify the columns or format of the registry and so this > is not technically an update to that RFC. > > Tom Petch > > On 06/07/2021 14:30, The IESG wrote: > > > > The IESG has received a request from the Operations and Management > > Area Working Group WG (opsawg) to consider the following document: > - > > 'Export of MPLS Segment Routing Label Type Information in IP Flow > > Information Export (IPFIX)' > > <draft-ietf-opsawg-ipfix-mpls-sr-label-type-06.txt> as > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send substantive comments to > the > > last-call@xxxxxxxx mailing lists by 2021-07-20. Exceptionally, > > comments may be sent to iesg@xxxxxxxx instead. In either case, > please > > retain the beginning of the Subject line to allow automated > sorting. > > > > Abstract > > > > > > This document introduces new IP Flow Information Export > (IPFIX) code > > points to identify which traffic is being forwarded based on > which > > MPLS control plane protocol used within a Segment Routing > domain. In > > particular, this document defines four code points for the > IPFIX > > mplsTopLabelType Information Element for IS-IS, OSPFv2, > OSPFv3, and > > BGP MPLS Segment Routing extensions. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr- > label > > -type/ > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf-announce > > . > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call _________________________________________________________________________________________________________________________ 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
