Subject: 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

From: tom petch <[email-masked]>
Date: Wed, 7 Jul 2021 09:45:39 +0100

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
> [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.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: <[email-masked]>
Date: Wed, 7 Jul 2021 12:29:51 +0000

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:[email-masked]] De la part de tom
> petch
> Envoyé : mercredi 7 juillet 2021 10:46
> À : [email-masked]
> Cc : [email-masked]
> 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.
> 
> 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
> 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.
> 
> 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.
> 
> does not specify the columns or format of the registry and so this
> is not technically an update to that RFC.
> 
> Tom Petch
> 
> > 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
> > 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
> >
> >
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-
> label
> > -type/
> >
> >
> >
> --
> last-call mailing list
> [email-masked]
> 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.

---

From: <[email-masked]>
Date: Thu, 8 Jul 2021 05:13:17 +0000

Hi Med, Rob and Tom,

The IE46 IANA registry has been updated a few days ago as described in the shepherd review of this document.

https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type

I therefore updated the table in the IANA consideration section accordingly and submitted -07 version.

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-07

Best wishes
Thomas

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, July 7, 2021 2:30 PM
To: tom petch <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: 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

Hi Tom, 

Thank you.

Cheers,
Med 

> petch Envoyé : mercredi 7 juillet 2021 10:46 À : [email-masked] Cc 
> : [email-masked]
> thereof, specifies three columns, Value Description Reference This I-D 
> adds a fourth column, Requester What happens to that column for 
> existing entries?
> 
> the January 2008 Information Model for IPFIX; that RFC is obsoleted by
> 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.
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-&amp;data
> > =04%7C01%7CThomas.Graf%40swisscom.com%7Cc3ac75ed6dc54a0dee0008d94142
> > f3e8%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637612578075280117
> > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1MnX2q4R9Hw3gBIy%2FBrMN3hsR
> > e5DGjlncSNEQoYJTwg%3D&amp;reserved=0
> label
> > -type/
> >
> >
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Fietf-announce&amp;data=04%7C01%7CT
> > homas.Graf%40swisscom.com%7Cc3ac75ed6dc54a0dee0008d94142f3e8%7C364e5
> > b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637612578075280117%7CUnknown%7
> > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > XVCI6Mn0%3D%7C1000&amp;sdata=%2FPZ7wTAIwOqlBw71SmtwHz99unz%2BHnhpCho
> > xWR0cbrQ%3D&amp;reserved=0
> > .
> >
> 
> --
> last-call mailing list
> [email-masked]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flast-call&amp;data=04%7C01%7CThomas.Gr
> af%40swisscom.com%7Cc3ac75ed6dc54a0dee0008d94142f3e8%7C364e5b87c1c7420
> d9beec35d19b557a1%7C0%7C0%7C637612578075280117%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 1000&amp;sdata=5HNo4opyqhnHCzZoG%2BmRPcaUnf6mIjnzYR3QBwuwzPw%3D&amp;re
> served=0

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.

---

From: tom petch <[email-masked]>
Date: Thu, 8 Jul 2021 10:58:49 +0100

> Can you please clarify why that section is "a nonsense"?

Because three and four are different, four into three will not go.

The IANA registry has three columns; this I-D specifies an update to the 
registry with four columns (with no instructions to IANA as to how to 
resolve this).  This makes no sense to me, ie it is nonsense!

The Shepherd writeup explains that there is a secret, invisible fourth 
column which explains the discrepancy but the Last Call is for the I-D, 
not the Shepherd writeup and without the Shepherd writeup, the I-D makes 
no sense:-)

IANA Considerations are an opportunity to involve IANA in updating a 
registry and fixing errors not just in adding new entries to a flawed 
registry.

Tom Petch

---

From: Amanda Baber <[email-masked]>
Date: Thu, 15 Jul 2021 01:09:11 +0000

Hi Tom,

This was introduced by IANA, not the authors: we mistook his subregistry entries for Information Elements entries and told him to use those IE-specific fields. 

A few days ago, with expert approval, we changed the names of the "References" and "Requester" fields in the Information Elements registry to "Additional Information" and "Reference." 

We're not aware of any plans to rename or add IPFIX subregistry fields.

Best regards,

Amanda Baber
Lead IANA Services Specialist

On 7/8/21, 2:59 AM, "last-call on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    Tom Petch

    >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb48NC87X$ 
    >> label
    >>> -type/
    >>>
    >>>
    >>>
    >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5DMKBVe$ 
    >>> .
    >>>
    >>
    >> --
    >> last-call mailing list
    >> [email-masked]
    >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5qmXt7-$ 
    >

    -- 
    last-call mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5qmXt7-$

---

From: tom petch <[email-masked]>
Date: Thu, 15 Jul 2021 13:18:28 +0100

> We're not aware of any plans to rename or add IPFIX subregistry fields.

Color me confused.

In the I-D which is in Last Call, now updated to -07, IANA 
Considerations seeks to update the subregistry for 46 with four columns 
for four new entries.  The subregistry only has three columns.  Hence my 
comment that this is (still) a nonsense.

The shepherd writeup says that
'Both IANA and IE doctors confirmed that IE46 registry will be fixed ..

and a IANA note therein 01/07 says the columns have been renamed.

But
- it is the IPFix registry that has been updated AFAICT not the IE46 
subregistry
- Mohamed posted a note to the Last Call list 7jul saying that the 
subregistry will be updated but I see no sign of that
- this I-D is asking for action to the IE46 subregistry which is 
impossible with the current columns in the IE46 subregistry.

Something needs to change IMHO.

Tom Petch

---

From: Amanda Baber <[email-masked]>
Date: Thu, 15 Jul 2021 15:05:08 +0000

Hi Tom,

I agree that the extra fourth column needs to be removed from the document. I just wanted to make it clear that it's not there because it was attempting to add the column. It was there because they were mistakenly informed that there was a column.

(Apologies for top posting.)

Amanda

On 7/15/21, 5:19 AM, "tom petch" <[email-masked]> wrote:

    Color me confused.

    But

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 15 Jul 2021 16:41:05 +0100

Amanda

That is nice and clear.  It seems that a new document is needed and, 
perhaps, another update to the Shepherd writeup in Working Group Summary 
which seems to be more about the IPFix registry in general and not about 
the subregistry for element 46 where it implies (to me) that a fourth 
column is still expected for the subregistry; you say, that is not now 
expected which is fine with me so I shall shut up.

Tom Petch