Subject: [OPSAWG] 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

From: The IESG <[email-masked]>
Date: Tue, 06 Jul 2021 06:30:10 -0700

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
[email-masked] mailing lists by 2021-07-20. Exceptionally, comments may
be sent to [email-masked] 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.

---

From: tom petch <[email-masked]>
Date: Tue, 6 Jul 2021 16:21:46 +0000

From: OPSAWG <[email-masked]> on behalf of The IESG <[email-masked]>
Sent: 06 July 2021 14:30

<tp>
Revisiting this after a while, two quirks struck me.

1) This I-D adds four entries to an IANA registry, nothing more really, and the registry is Expert Review so strictly no I-D/RFC is needed.  It is probably a good idea to have one otherwise it can be difficult, impossible even, for a user to know how an entry came to be in an IANA registry.

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.

Tom Petch

Abstract

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Tue, 6 Jul 2021 16:54:22 +0000

Hi Tom; 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de tom petch
> Envoyé : mardi 6 juillet 2021 18:22
> À : [email-masked]
> Cc : [email-masked]; draft-ietf-opsawg-ipfix-mpls-sr-label-
> [email-masked]
> Objet : Re: [OPSAWG] 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 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
> 1) This I-D adds four entries to an IANA registry, nothing more
> really, and the registry is Expert Review so strictly no I-D/RFC is
> needed.

[Med] Please note that RFC 7012 says the following: 

      "The specification of new MPLS label types MUST be published using a
       well-established and persistent publication medium."

  It is probably a good idea to have one otherwise it can be
> difficult, impossible even, for a user to know how an entry came to
> be in an IANA registry.
> 
> 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?

[Med] Please refer to the write-up where this is discussed (search for hidden column) together with the plan agreed with IANA. 

> 
> 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.
> 
> Tom Petch
> 
> 
> 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 [email-masked] mailing lists by 2021-07-20.
> Exceptionally, comments may be sent to [email-masked] instead. In
> either case, please retain the beginning of the Subject line to
> allow automated sorting.
> 
> Abstract
> 
> 

_________________________________________________________________________________________________________________________

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.