Subject: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Sep 2021 10:01:16 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document presents a couple use cases for the new IE 46 codepoints,
but both are in the context of monitoring the rollout of a migration of
control-plane technology.  Are there steady-state use cases for these
values?

Section 2

   Another use case is to monitor MPLS control plane migrations from
   dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of
   Seamless MPLS SR described in Section 4.6 of
   [I-D.hegde-spring-mpls-seamless-sr].

I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of
maturity to be a good reference here (and thus, that this example is
worth including).  For example, the referenced section refers to "option
A", "option B", and "option C" but I couldn't find where in the document
these options were enumerated as such.  (Maybe it's supposed to be
what's described in sections 4.1.{1,2,3}; maybe not.) (Further aside
about that draft: it also isn't using the RFC 8174 version of the BCP 14
boilerplate, and has more authors than recommended by the RFC Series
Editor statement on authorship,
https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
.)

Section 5

If pressed to come up with new security considerations from this work, I
would submit that conveying information about what control-plane
protocol is in use gives an attacker information to use in planning an
attack on that control plane.  But the attacker would need to have
access to the IPFIX information in order to do so, and RFCs 7012 and
7011 are clear that the mechanism for conveying the IPFIX data has to
provide confidentiality protection, so it seems that endpoint compromise
would be needed for the attacker to actually gain access, and it's hard
to come up with a realistic scenario involving endpoint compromise where
these new codepoints are key to an attack.  In short, it doesn't really
seem like a consideration that's relevant enough to be worth mentioning
in this document, so I'm okay with leaving this section as-is.

The most that I would suggest changing is to add the word "significant",
for "no significant extra security considerations".

NITS

Section 1

   Four new routing protocol extensions, OSPFv2 Extensions [RFC8665],

I suggest dropping the word "new", which is a relative term and will be
less and less applicable over time.

   Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
   Information Export [RFC7012] can be leveraged to account traffic to
   MPLS SR label dimensions within a Segment Routing domain.

I don't understand the word "dimensions" in this context.  (It doesn't
appear in the referenced documents, either, which suggests that a
different word may have been intended.)

---

From: <[email-masked]>
Date: Thu, 9 Sep 2021 05:19:00 +0000

Hi Benjamin,

> I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of maturity to be a good reference here (and thus, that this example is worth including).  
I agree. The only alternative is to reference https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07 instead. The challenge is that Seamless MPLS is widely supported and used at network vendors and operators but not yet standardized at IETF. Both Seamless MPLS drafts are either in progress or expired. If you don't object, I like to keep that example and reference for not having a better alternative.

> For example, the referenced section refers to "option A", "option B", and "option C" but I couldn't find where in the document these options were enumerated as such.  
That refers to RFC4364 section 10. https://datatracker.ietf.org/doc/html/rfc4364#section-10. And yes, the author should include the reference for clarity. I will follow up on that.

>I don't understand the word "dimensions" in this context.  (It doesn't appear in the referenced documents, either, which suggests that a different word may have been intended.)

Regarding: account traffic to MPLS SR label dimensions

In data engineering, metrics are divided into two groups. Dimensions (https://www.merriam-webster.com/dictionary/dimension) and measurements (https://www.merriam-webster.com/dictionary/measurement). Dimensions are important for Dimensional data modelling (https://en.wikipedia.org/wiki/Dimensional_modeling). To give measurements context. I agree that the words dimensions and measurements aren't widely used at IETF in such a context.

> The most that I would suggest changing is to add the word "significant", for "no significant extra security considerations".
Acknowledged and merged into -09 version.

> I suggest dropping the word "new", which is a relative term and will be less and less applicable over time.
Acknowledged and merged into -09 version.

I am going to publish -09 version once all the IESG reviews are concluded. Here the inputs I received and merged so far
https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-08.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt

Best wishes
Thomas

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]> 
Sent: Wednesday, September 8, 2021 7:01 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

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.)

Please refer to https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cqmEKyd5B0ZoBK0kTMNF1%2BnOFoyJ2%2FmyPNVRoLvEXTA%3D&amp;reserved=0
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NRFVezr2O2J6IyAiXvlXm%2BdXFtZIyS1aM1tGUaDLJ2Q%3D&amp;reserved=0

This document presents a couple use cases for the new IE 46 codepoints, but both are in the context of monitoring the rollout of a migration of control-plane technology.  Are there steady-state use cases for these values?

Section 2

I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of maturity to be a good reference here (and thus, that this example is worth including).  For example, the referenced section refers to "option A", "option B", and "option C" but I couldn't find where in the document these options were enumerated as such.  (Maybe it's supposed to be what's described in sections 4.1.{1,2,3}; maybe not.) (Further aside about that draft: it also isn't using the RFC 8174 version of the BCP 14 boilerplate, and has more authors than recommended by the RFC Series Editor statement on authorship,
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fpipermail%2Frfc-interest%2F2015-May%2F008869.html&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Hh5IT341AwjwYta3ohga2%2FOtsrBbFZeY%2FUklGjOy9tU%3D&amp;reserved=0
.)

Section 5

If pressed to come up with new security considerations from this work, I would submit that conveying information about what control-plane protocol is in use gives an attacker information to use in planning an attack on that control plane.  But the attacker would need to have access to the IPFIX information in order to do so, and RFCs 7012 and
7011 are clear that the mechanism for conveying the IPFIX data has to provide confidentiality protection, so it seems that endpoint compromise would be needed for the attacker to actually gain access, and it's hard to come up with a realistic scenario involving endpoint compromise where these new codepoints are key to an attack.  In short, it doesn't really seem like a consideration that's relevant enough to be worth mentioning in this document, so I'm okay with leaving this section as-is.

The most that I would suggest changing is to add the word "significant", for "no significant extra security considerations".

NITS

Section 1

I suggest dropping the word "new", which is a relative term and will be less and less applicable over time.

I don't understand the word "dimensions" in this context.  (It doesn't appear in the referenced documents, either, which suggests that a different word may have been intended.)

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Sep 2021 19:01:49 -0700

Hi Thomas,

> I agree. The only alternative is to reference https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07 instead. The challenge is that Seamless MPLS is widely supported and used at net…

To be clear, I don't have issues with referring to an individual draft in
the abstract.  It's more that for this particular draft, I came away very
unsure what I was supposed to take away from reading it that made it worth
referencing.  It would probably be possible to add more words to
draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for
in draft-hedge-spring-mpls-seamless-sr, or to make edits to
draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify
what's interesting about it that we want the reader to think about.  Since
I am still unclear on what the important concepts are, I unfortunately
don't have any concrete suggestions for what that text could be.

> That refers to RFC4364 section 10. https://datatracker.ietf.org/doc/html/rfc4364#section-10. And yes, the author should include the reference for clarity. I will follow up on that.

Thanks for following up; having that reference from
draft-hegde-spring-mpls-seamless-sr would have been very helpful.

> In data engineering, metrics are divided into two groups. Dimensions (https://www.merriam-webster.com/dictionary/dimension) and measurements (https://www.merriam-webster.com/dictionary/measurement)…

Thanks for the reference!  Knowing that "dimensional modeling" is the
intended context would have been enough for me to figure it out, I think.
That could be as simple as "account traffic to MPLS SR label dimensions
within a dimensional model of a Segment Routing domain" (if that makes
sense).

> https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-08.txt&url2=https://raw.githubus…

Thanks for the link.

I think it would be good to add a few words to hint at dimensional
modeling, and maybe also to add a few words to clarify why
draft-hegde-spring-mpls-seamless-sr is being referenced.

-Ben

---

From: <[email-masked]>
Date: Sat, 11 Sep 2021 07:46:17 +0000

Hi Benjamin,

Thanks for the clarifications and suggestions. Very much appreciated.

> I think it would be good to add a few words to hint at dimensional modeling, and maybe also to add a few words to clarify why draft-hegde-spring-mpls-seamless-sr is being referenced.

I put additional thoughts into that paragraph and changed the reference to RFC 8670 (BGP Prefix Segment in Large-Scale Data Centers) instead. RFC 7983 (Use of BGP for Routing in Large-Scale Data Centers)  describes the use of BGP labeled-unicast in large data center environments. Where RFC 8670 focuses on using Segmenting Routing with BGP by using the same architecture. RFC 8670 describes the motivation of such a migration and is a stable document. I hope this makes more sense now.

   Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
   Information Export [RFC7012] can be leveraged in dimensional data
   modelling to account traffic to MPLS SR label dimensions within a
   Segment Routing domain.

   Another use case is to monitor MPLS control plane migrations from
   dynamic BGP labels [RFC8277] to BGP Prefix-SIDs [RFC8669].  The
   motivation and benefits for such a migration is described in
   [RFC8670].

https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt

Let me know your thoughts.

Best wishes
Thomas

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Saturday, September 11, 2021 4:02 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Hi Thomas,

On Thu, Sep 09, 2021 at 05:19:00AM +0000, [email-masked] wrote:
> I agree. The only alternative is to reference https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268212042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZE7ap4WzesHE5wOJstYpopUlqTm8AJDiFZ91CyTlVBg%3D&amp;reserved=0 instead. The challenge is that Seamless MPLS is widely supported and used at network vendors and operators but not yet standardized at IETF. Both Seamless MPLS drafts are either in progress or expired. If you don't object, I like to keep that example and reference for not having a better alternative.

To be clear, I don't have issues with referring to an individual draft in the abstract.  It's more that for this particular draft, I came away very unsure what I was supposed to take away from reading it that made it worth referencing.  It would probably be possible to add more words to draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for in draft-hedge-spring-mpls-seamless-sr, or to make edits to draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify what's interesting about it that we want the reader to think about.  Since I am still unclear on what the important concepts are, I unfortunately don't have any concrete suggestions for what that text could be.

> That refers to RFC4364 section 10. https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4364%23section-10&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7fB48K9MprNUDazBaASPc1PmYiCYeCwhS4VAFAuxwPU%3D&amp;reserved=0. And yes, the author should include the reference for clarity. I will follow up on that.

Thanks for following up; having that reference from draft-hegde-spring-mpls-seamless-sr would have been very helpful.

> >I don't understand the word "dimensions" in this context.  (It 
> >doesn't appear in the referenced documents, either, which suggests 
> >that a different word may have been intended.)
> 
> In data engineering, metrics are divided into two groups. Dimensions (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fdimension&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DebdS9dUUB5ClCNwMNal5h0dFol9r9gPnRIfqt04jM%3D&amp;reserved=0) and measurements (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fmeasurement&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yt7PrhbXPo93V6UOFX%2FCZC8QD7%2BSWy5gsR83afNvglU%3D&amp;reserved=0). Dimensions are important for Dimensional data modelling (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDimensional_modeling&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=No%2FQrRQ0Id4Pbkn7TaMOTNKWlVDaf7nJixuV3oRXTzA%3D&amp;reserved=0). To give measurements context. I agree that the words dimensions and measurements aren't widely used at IETF in such a context.

Thanks for the reference!  Knowing that "dimensional modeling" is the intended context would have been enough for me to figure it out, I think.
That could be as simple as "account traffic to MPLS SR label dimensions within a dimensional model of a Segment Routing domain" (if that makes sense).

> I am going to publish -09 version once all the IESG reviews are 
> concluded. Here the inputs I received and merged so far
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2F%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.com
> %2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fmaster%2Fdraft-ie
> tf-opsawg-ipfix-mpls-sr-label-type-08.txt%26url2%3Dhttps%3A%2F%2Fraw.g
> ithubusercontent.com%2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type
> %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt&amp;data
> =04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c827
> 20%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jSqQWycX%2BpY2Xwo%2FBgK4blpMOpIq18g
> byT6B322uF2E%3D&amp;reserved=0

Thanks for the link.

I think it would be good to add a few words to hint at dimensional modeling, and maybe also to add a few words to clarify why draft-hegde-spring-mpls-seamless-sr is being referenced.

-Ben

> Cc: [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Benjamin Kaduk's No Objection on 
> draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=04%7C01%7
> CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5
> b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&amp;sdata=tNQj%2BEZIlFdo5rWk03qTnoianqjvmvzWvy80NxC2s5o
> %3D&amp;reserved=0 for more information about DISCUSS and COMMENT 
> positions.
> 
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2F
> &amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f0
> 8d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C6376692252682
> 21998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=17OrrPh2jRjHfJT9cTGUeBeKVu
> qlk%2FbUqdEGG5tgjEY%3D&amp;reserved=0
> 
> 
> 
> worth including).  For example, the referenced section refers to 
> "option A", "option B", and "option C" but I couldn't find where in 
> the document these options were enumerated as such.  (Maybe it's 
> supposed to be what's described in sections 4.1.{1,2,3}; maybe not.) 
> (Further aside about that draft: it also isn't using the RFC 8174 
> version of the BCP 14 boilerplate, and has more authors than 
> recommended by the RFC Series Editor statement on authorship,
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fpipermail%2Frfc-interest%2F2015-May%2F008869.html&amp
> ;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d97
> 4c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C63766922526822199
> 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BY6z%2FpAIhrLfzUHY9RH65KvLCq7H
> FlqpFXNUzPgdENY%3D&amp;reserved=0
> .)
> 
> Section 5
> 
> If pressed to come up with new security considerations from this work, 
> I would submit that conveying information about what control-plane

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Sep 2021 16:57:10 -0700

Hi Thomas,

Many thanks; that looks like it should work quite nicely.

-Ben

---

From: <[email-masked]>
Date: Sat, 18 Sep 2021 05:30:41 +0000

Dear Rob, Med and IESG

Based on Ben's feedback, I submitted the final -11 version.

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

I think the document is ready now for the RFC editor queue.

Best wishes
Thomas

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Tuesday, September 14, 2021 1:57 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Hi Thomas,

-Ben

On Sat, Sep 11, 2021 at 07:46:17AM +0000, [email-masked] wrote:
> tf-opsawg-ipfix-mpls-sr-label-type-10.txt%26url2%3Dhttps%3A%2F%2Fraw.g
> %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt&amp;data
> =04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123c
> d4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CU
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6J6eFY%2FHjJWFUIKugTO%2F0q%2FhSUm9a
> 54DE8qV2LSCa3E%3D&amp;reserved=0
> 
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's No Objection on 
> > I agree. The only alternative is to reference https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=W9Y9RGobCEdshkILs7JeW2HpAE3T%2BdJ322XTfbD9STo%3D&amp;reserved=0 instead. The challenge is that Seamless MPLS is widely supported and used at network vendors and operators but not yet standardized at IETF. Both Seamless MPLS drafts are either in progress or expired. If you don't object, I like to keep that example and reference for not having a better alternative.
> 
> > That refers to RFC4364 section 10. https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4364%23section-10&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480213187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=egYBTw%2BjoE%2FPMObnmULYGU87D5%2B3SI8uPSI9wK62%2Frg%3D&amp;reserved=0. And yes, the author should include the reference for clarity. I will follow up on that.
> 
> > In data engineering, metrics are divided into two groups. Dimensions (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fdimension&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9zlM0D%2Fgn1IWEJhRydRtL%2F9yBihplYJh2wXqqjZEdDg%3D&amp;reserved=0) and measurements (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fmeasurement&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dQjLrclhC04vYVxY84On41kzB1wT1xWSWry0c6sMk7c%3D&amp;reserved=0). Dimensions are important for Dimensional data modelling (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDimensional_modeling&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3WUOXXKkCD6s7ToxCrEkEuZPlPAPHC4xHZY1VknBYe0%3D&amp;reserved=0). To give measurements context. I agree that the words dimensions and measurements aren't widely used at IETF in such a context.
> 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > 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.)
> > 
> > 
> > Please refer to
> > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state 
> > of maturity to be a good reference here (and thus, that this example 
> > is worth including).  For example, the referenced section refers to 
> > If pressed to come up with new security considerations from this 
> > work, I would submit that conveying information about what 
> > control-plane protocol is in use gives an attacker information to 
> > use in planning an attack on that control plane.  But the attacker 
> > would need to have access to the IPFIX information in order to do 
> > so, and RFCs 7012 and