Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

From: <[email-masked]>
Date: Wed, 23 Jun 2021 15:47:02 +0000

Hi Thomas, all,

I made a shepherd review of the document. The review can be found at:

*         pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf

*         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx

Almost all the comments are minor. These are basically to enhance the readability of the document (shorten long sentences, etc.) and make idnits happy.

There is one "procedural" comment that it is better to discuss now as I suspect it will pop up in the process: Why the document is in the "Standard Track"?

I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don't have any normative statements in the document.

Are there any reasons why the document should be in "Standards Track"?

Once these comments are fixed, I will start preparing the write-up.

Thank you.

Cheers,
Med

_________________________________________________________________________________________________________________________

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: Tianran Zhou <[email-masked]>
Date: Thu, 24 Jun 2021 03:08:38 +0000

Hi Med,

>>Why the document is in the "Standard Track"?

The registry does not require the standard track document. But this is not the reason why this document should so not be standard track.
If not standard track, should it be informational? Look at the "informational" draft definition in RFC2026. I do not think this draft falls into the informational track.
"An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation."

In addition, this working group published rfc8549 as standard track, which is similar to draft-ietf-opsawg-ipfix-mpls-sr-label-type, for IPFIX IE.
https://datatracker.ietf.org/doc/rfc8549/

IMO, it seems standard track is a suitable type for this draft .

Cheers,
Tianran

From: OPSAWG [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 23, 2021 11:47 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

Thank you.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 04:22:50 +0000

Hi Med,

Many thanks for the shepherd review. I updated the document accordingly into -03 version.

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

I included all your suggestions and followed your example in using abbreviations and changed the term "MPLS Segment Routing"
To "MPLS SR" throughout the document. The same for the term "subregistry" instead of "sub-registry" or "SubRegistry".

I took the liberty to further simplify the use case paragraph in section 2. I hope it is better readable now. Looking forward to your review.

Below in detail where I deviated to your suggestions. Mostly minor.

Regarding wherever this document should be on Standard Track or not. That's a reasonable question. I doubled checked on https://www.ietf.org/standards/process/informational-vs-experimental/, checked also other IPFIX RFC's such as https://datatracker.ietf.org/doc/html/rfc8549 which also only specified new IPFIX code points for existing protocols, and came to the same conclusion then Tianran that Informational does not fit.

Best wishes
Thomas

Section 1
---
Proposed:

Also [I-D.ali-spring-sr-traffic-accounting] describes
how IP Flow Information Export <xref target="RFC7012"/> can be leveraged
to account traffic to MPLS Segment Routing label dimensions within a
Segment Routing domain.

Changed to:

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

Section 2
---
Proposed:

By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3, and BGP Prefix-SID,
it is possible to identify into which traffic is being
forwarded based upon which MPLS control plane protocol is in use.

Changed to:

By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
it is possible to identify which traffic is being
forwarded based upon which MPLS SR control plane protocol is in use.

Section 2
---
Proposed:

Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70), and forwardingStatus(89) IEs to infer:

o  how many packets are forwarded or dropped,
o  if dropped, for which reasons, and
o  the MPLS provider edge loopback address and label protocol.

Changed to:

Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70) and forwardingStatus(89) IEs to infer
how many packets are forwarded or dropped to which MPLS provider
edge loopback address and label protocol, and if dropped for which
reasons.

Section 3
---
Proposed: Table 1: Updates to "IPFIX MPLS label type (Value 46)" SubRegistry
Changed to: Table 1: Updates to "IPFIX MPLS label type (Value 46)" subregistry

Section 4
---
Proposed: These values are thus used for distinct purposes
Changed to: These values are thus used for those distinct purposes

From: [email-masked] <[email-masked]>
Sent: Wednesday, June 23, 2021 5:47 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.pdf&data=04%7C01%7CThomas.Graf%40swisscom.com%7C6b1146929f844e45b53108d9365e31b0%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637600600448168824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LL21sIBfQASVe1nV6ZL3MrmVRp9RbZowyHBBSmBFgBk%3D&reserved=0>
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.docx&data=04%7C01%7CThomas.Graf%40swisscom.com%7C6b1146929f844e45b53108d9365e31b0%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637600600448178789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AjP1FU6uDFRM1LabzOIizUTuauJMaaO8aHWUKuh25EM%3D&reserved=0>

Thank you.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 05:23:54 +0000

Hi Tianran, all,

Please see inline.

Cheers,
Med

De : Tianran Zhou [mailto:[email-masked]]
Envoyé : jeudi 24 juin 2021 05:09
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

The registry does not require the standard track document. But this is not the reason why this document should so not be standard track.
[Med] Yeah, if we don't have the second bullet above.

[Med] Please note that the consensus thing was updated as per: https://datatracker.ietf.org/doc/rfc8789/.

In addition, this working group published rfc8549 as standard track, which is similar to draft-ietf-opsawg-ipfix-mpls-sr-label-type, for IPFIX IE.
https://datatracker.ietf.org/doc/rfc8549/
[Med] This is document is not similar as it includes many normative statements.

Cheers,
Tianran

From: OPSAWG [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, June 23, 2021 11:47 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

·         pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf

·         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx

Thank you.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 05:35:11 +0000

Hi Thomas,

Thank you for promptly addressing the comments.

Looks good to me, but idnits is still not happy with these long lines of Table 1:

==
  ** There are 12 instances of too long lines in the document, the longest
     one being 2 characters in excess of 72.
==

One very very minor nit:

OLD:
   These values are thus used for those
   distinct purposes
NEW:
   These values are thus used for those
   distinct purposes.

For the intended status, I'm still not convinced we have valid arguments for it. Let's see how to fix that.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : jeudi 24 juin 2021 06:23
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

Best wishes
Thomas

Section 1
---
Proposed:

Changed to:

Section 2
---
Proposed:

Changed to:

Section 2
---
Proposed:

Changed to:

Section 3
---

Section 4
---

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi Thomas, all,

Thank you.

Cheers,
Med

Thank you.

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 24 Jun 2021 06:34:53 +0000

Hi Med,

Your capture is correct.
Let's go through the more complete definition of "informational", but ignore the "consensus" part.
"An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. The Informational
designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to verification
that there has been adequate coordination with the standards process
(see section 4.2.3)."

It seems this draft is not intended only to provide information as described in the further explanation.
What's your thoughts?

Best,
Tianran

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 24, 2021 1:24 PM
To: Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Tianran, all,

Please see inline.

Cheers,
Med

De : Tianran Zhou [mailto:[email-masked]]
Envoyé : jeudi 24 juin 2021 05:09
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

Cheers,
Tianran

Hi Thomas, all,

Thank you.

Cheers,
Med

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 07:03:47 +0000

Re-,

The main document provides useful details about the use cases of the new types. These use cases are informative.

The part that I see may have interoperability implications is the clarification that the new codes should not be mixed with the existing BGP one. If we want to maintain the intended status, I suggest to consider re-working that part so that interoperability aspects are highlighted + use normative language. Without such as change, we don't have valid argument to motivate the intended status.

Cheers,
Med

De : Tianran Zhou [mailto:[email-masked]]
Envoyé : jeudi 24 juin 2021 08:35
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

Your capture is correct.

Best,
Tianran

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 24, 2021 1:24 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Tianran, all,

Please see inline.

Cheers,
Med

Hi Med,

Cheers,
Tianran

Hi Thomas, all,

Thank you.

Cheers,
Med

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 07:13:28 +0000

Hi Med,

Thanks for the promptly feedback. I updated to -04 version according to your input.

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

All lines now within 72 characters. Added the "." as described and reverted back to the previous paragraph and included your input.

Best wishes
Thomas

From: [email-masked] <[email-masked]>
Sent: Thursday, June 24, 2021 7:39 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[email-masked]>
Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Re-,

I forgot to mention this one about this long sentence:

"

   how many packets are forwarded or dropped to which MPLS provider edge

                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   loopback address and label protocol, and if dropped for which
   reasons.
"

I don't parse the part I highlighted. I prefer what you had in the previous version, though.

Thanks.

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : jeudi 24 juin 2021 07:35
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas,

==

One very very minor nit:

OLD:

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Hi Med,

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-03<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-mpls-sr-label-type-03&data=04%7C01%7CThomas.Graf%40swisscom.com%7C80175bc4454d4dac9a7008d936d26ac5%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601099621725494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TGKYwKLyZy0G4T3oftyk4IbhkSUoNb%2FIoQvy2vuCqzQ%3D&reserved=0>

Regarding wherever this document should be on Standard Track or not. That's a reasonable question. I doubled checked on https://www.ietf.org/standards/process/informational-vs-experimental/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fstandards%2Fprocess%2Finformational-vs-experimental%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C80175bc4454d4dac9a7008d936d26ac5%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601099621725494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FaB%2Bx9nCYCJbU7GKfiOoZPDm%2BHmEJkRa0OgVL1rilyY%3D&reserved=0>, checked also other IPFIX RFC's such as https://datatracker.ietf.org/doc/html/rfc8549<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8549&data=04%7C01%7CThomas.Graf%40swisscom.com%7C80175bc4454d4dac9a7008d936d26ac5%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601099621735441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fFV41WUBxnmO%2F8topKv76FA%2BVIPMWuM7JSceTASwXUw%3D&reserved=0> which also only specified new IPFIX code points for existing protocols, and came to the same conclusion then Tianran that Informational does not fit.

Best wishes
Thomas

Section 1
---
Proposed:

Changed to:

Section 2
---
Proposed:

Changed to:

Section 2
---
Proposed:

Changed to:

Section 3
---

Section 4
---

Hi Thomas, all,

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.pdf&data=04%7C01%7CThomas.Graf%40swisscom.com%7C80175bc4454d4dac9a7008d936d26ac5%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601099621735441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oTYSeyXjUCiM6AJz1Eg%2BUV6KkyO3RlXhlk7ICazUGtI%3D&reserved=0>
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.docx&data=04%7C01%7CThomas.Graf%40swisscom.com%7C80175bc4454d4dac9a7008d936d26ac5%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601099621745398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UJNOe9cwmaQuQbN86xpIg6rACTBHMrJ%2Fe8cusJ5Ob5c%3D&reserved=0>

Thank you.

Cheers,
Med

Thank you.

Thank you.

Thank you.

---

From: tom petch <[email-masked]>
Date: Thu, 24 Jun 2021 10:20:27 +0000

From: OPSAWG <[email-masked]> on behalf of Tianran Zhou <[email-masked]>
Sent: 24 June 2021 07:34
To: [email-masked]; [email-masked]; [email-masked]

Hi Med,

Your capture is correct.
Let’s go through the more complete definition of “informational”, but ignore the “consensus” part.

<tp>
A slightly different, pragmatic consideration is that Normative References to Informational documents create more work, some hassle.  I see this regularly with YANG modules which SHOULD have reference clauses referring to the source of a definition and often this is an informational model which has been given Informational status; wrong IMHO.

So if these values are ever going to be referenced, by such as  a YANG module, then Standards Track is more straightforward.

Tom Petch

“An "Informational" specification is published for the general
(see section 4.2.3).”

What’s your thoughts?

Best,
Tianran

Hi Tianran, all,

Please see inline.

Cheers,
Med

Hi Med,

>>Why the document is in the “Standard Track”?
>>* We don’t have any normative statements in the document.

The registry does not require the standard track document. But this is not the reason why this document should so not be standard track.
[Med] Yeah, if we don’t have the second bullet above.

If not standard track, should it be informational? Look at the “informational” draft definition in RFC2026. I do not think this draft falls into the informational track.
“An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation.”
[Med] Please note that the consensus thing was updated as per: https://datatracker.ietf.org/doc/rfc8789/.

Cheers,
Tianran

Hi Thomas, all,

There is one “procedural” comment that it is better to discuss now as I suspect it will pop up in the process: Why the document is in the “Standard Track”?

I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don’t have any normative statements in the document.

Are there any reasons why the document should be in “Standards Track”?

Thank you.

Cheers,
Med

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 12:57:24 +0000

Hi Tom, 

That's an interesting approach, indeed. However, one may object this is speculating about future use. No?

Please note that IPFIX types (in general, not only this I-D) can be used in YANG modules without having to cite an RFC. The authoritative reference would be the IANA registry itself. I'm thinking about an IANA-maintained IPFIX module that would echo the content of the current registry. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch [mailto:[email-masked]]
> Envoyé : jeudi 24 juin 2021 12:20
> À : Tianran Zhou <[email-masked]>; BOUCADAIR Mohamed
> INNOV/NET <[email-masked]>; draft-ietf-opsawg-ipfix-
> [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-
> label-type
> 
> To: [email-masked]; draft-ietf-opsawg-ipfix-mpls-sr-
> [email-masked]; [email-masked]
> 
> Hi Med,
> 
> Your capture is correct.
> A slightly different, pragmatic consideration is that Normative
> References to Informational documents create more work, some hassle.
> I see this regularly with YANG modules which SHOULD have reference
> clauses referring to the source of a definition and often this is an
> informational model which has been given Informational status; wrong
> IMHO.
> 
> So if these values are ever going to be referenced, by such as  a
> YANG module, then Standards Track is more straightforward.
> 
> Tom Petch
> 
> sources, subject only to editorial considerations and to
> verification that there has been adequate coordination with the
> standards process (see section 4.2.3)."
> 
> To: Tianran Zhou <[email-masked]>; draft-ietf-opsawg-ipfix-
> [email-masked]; [email-masked]
> Cc: [email-masked]
> De : Tianran Zhou [mailto:[email-masked]] Envoyé : jeudi 24
> juin 2021 05:09 À : BOUCADAIR Mohamed INNOV/NET
> <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:draft-
> [email-masked]>; opsawg-
> [email-masked]<mailto:[email-masked]>
> The registry does not require the standard track document. But this
> is not the reason why this document should so not be standard track.
> If not standard track, should it be informational? Look at the
> "informational" draft definition in RFC2026. I do not think this
> draft falls into the informational track.
> [Med] Please note that the consensus thing was updated as per:
> https://datatracker.ietf.org/doc/rfc8789/.
> 
> In addition, this working group published rfc8549 as standard track,
> which is similar to draft-ietf-opsawg-ipfix-mpls-sr-label-type, for
> IPFIX IE.
> From: OPSAWG [mailto:[email-masked]] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: draft-ietf-opsawg-ipfix-mpls-sr-label-
> [email-masked]<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-
> [email-masked]>; [email-masked]<mailto:opsawg-
> [email-masked]>
> ·         pdf: https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf
> 
> ·         doc: https://github.com/boucadair/IETF-Drafts-
> Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx
> 
> Almost all the comments are minor. These are basically to enhance
> the readability of the document (shorten long sentences, etc.) and
> make idnits happy.
> 
> There is one "procedural" comment that it is better to discuss now
> as I suspect it will pop up in the process: Why the document is in
> the "Standard Track"?
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> 
> 
> 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,
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> 
> 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.
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> 
> 
> 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,
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> 
> 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, 24 Jun 2021 15:33:59 +0000

Sent: 24 June 2021 13:57

Hi Tom,

<tp>
It is speculating about whether or not this data will ever be needed to be referred to in a Normative manner.  I keep seeing examples where it is, but the authors have not allowed for that, as with YANG modules.  Talking of YANG modules, almost every one I see is short of reference clauses, judged by the standards of 'YANG Guidelines', and sometimes the reason is because that would be a DownRef and that is hassle.  I think that YANG reference clauses have tilted the playing field and that the IESG will catch up with that in time, even if the letter of the law lags behind.  A reference to an IANA registry is usually second-best because all that does is point to the real source of information. the RFC that defined the concept or the value.

Tom Petch

Cheers,
Med

---

From: <[email-masked]>
Date: Sat, 26 Jun 2021 07:40:42 +0000

Dear Tianran, Med and Tom

Thanks a lot for the discussion wherever the document intend should be standard or informational. 

Also after reviewing RFC 1796 and RFC 2026, I agree that current content and language of the draft aren't normative enough to qualify to be on the standard track. To me as the author I feel more comfortable to change the intend to informational instead of changing the language to be more normative and describe in more detail where the new code points MUST (or SHOULD) be used and where the existing BGP code points MUST NOT be used. 

Therefore I changed the intend and updated the draft to -05 version.

I hope this makes sense. Looking forward for the feedback from the list.

Best wishes
Thomas

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Thursday, June 24, 2021 5:34 PM
To: [email-masked]; Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Tom,

<tp>

Tom Petch

Cheers,
Med

> De : tom petch [mailto:[email-masked]] Envoyé : jeudi 24 juin 
> 2021 12:20 À : Tianran Zhou <[email-masked]>; BOUCADAIR 
> Mohamed INNOV/NET <[email-masked]>; 
> draft-ietf-opsawg-ipfix- [email-masked]; 
> [email-masked] Cc : [email-masked] Objet : Re: Shepherd 
> Review of draft-ietf-opsawg-ipfix-mpls-sr- label-type
>
> So if these values are ever going to be referenced, by such as  a YANG 
> module, then Standards Track is more straightforward.
>
> Tom Petch
>
> The registry does not require the standard track document. But this is 
> not the reason why this document should so not be standard track.
> "informational" draft definition in RFC2026. I do not think this draft 
> falls into the informational track.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8789%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca103c776853c41a0484508d937259464%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601456810093723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xDOSyOjLxI6clbyf3%2Fhaa9yVIq9rrBgIo6Z2mjVmGTI%3D&amp;reserved=0.
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Frfc8549%2F&amp;data=04%7C01%7CThomas.Graf%40s
> wisscom.com%7Ca103c776853c41a0484508d937259464%7C364e5b87c1c7420d9beec
> 35d19b557a1%7C0%7C0%7C637601456810093723%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=yHU1QE61GeNNJF2c8kjgKf0bV%2B9ryb%2BRxeeWST%2FwnAs%3D&amp;rese
> rved=0 [Med] This is document is not similar as it includes many 
> normative statements.
>
> ·         pdf: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca103c776853c41a0484508d937259464%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601456810093723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SjPvFNqF7nM%2B3A5tTES1JhLsb5xSvGQkUdbFT6n1F8o%3D&amp;reserved=0
> ·         doc: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca103c776853c41a0484508d937259464%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637601456810093723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SjPvFNqF7nM%2B3A5tTES1JhLsb5xSvGQkUdbFT6n1F8o%3D&amp;reserved=0
> Almost all the comments are minor. These are basically to enhance the 
> readability of the document (shorten long sentences, etc.) and make 
> idnits happy.
>
> There is one "procedural" comment that it is better to discuss now as 
> I suspect it will pop up in the process: Why the document is in the 
> "Standard Track"?
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>

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.