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

[[e-mail]]

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 <[e-mail]> 
Sent: Thursday, June 24, 2021 5:34 PM
To: [e-mail]; Tianran Zhou <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

From: [e-mail] <[e-mail]>
Sent: 24 June 2021 13:57

Hi Tom,

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

<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



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:[e-mail]] Envoyé : jeudi 24 juin 
> 2021 12:20 À : Tianran Zhou <[e-mail]>; BOUCADAIR 
> Mohamed INNOV/NET <[e-mail]>; 
> draft-ietf-opsawg-ipfix- [e-mail]; 
> [e-mail] Cc : [e-mail] Objet : Re: Shepherd 
> Review of draft-ietf-opsawg-ipfix-mpls-sr- label-type
>
> From: OPSAWG <[e-mail]> on behalf of Tianran Zhou 
> <[e-mail]>
> Sent: 24 June 2021 07:34
> To: [e-mail]; draft-ietf-opsawg-ipfix-mpls-sr- 
> [e-mail]; [e-mail]
>
> 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 
> 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: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, June 24, 2021 1:24 PM
> To: Tianran Zhou <[e-mail]>; draft-ietf-opsawg-ipfix- 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]] Envoyé : jeudi 24 
> juin 2021 05:09 À : BOUCADAIR Mohamed INNOV/NET 
> <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:draft-
> [e-mail]>; opsawg- 
> [e-mail]<mailto:[e-mail]>
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr- 
> label-type
>
> Hi Med,
>
> >>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.
>
> 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://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.
>
> 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://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.
>
> IMO, it seems standard track is a suitable type for this draft .
>
> Cheers,
> Tianran
>
> From: OPSAWG [mailto:[e-mail]] On Behalf Of 
> [e-mail]<mailto:[e-mail]>
> Sent: Wednesday, June 23, 2021 11:47 PM
> To: draft-ietf-opsawg-ipfix-mpls-sr-label-
> [e-mail]<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-
> [e-mail]>; [e-mail]<mailto:opsawg-
> [e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls- 
> sr-label-type
>
> Hi Thomas, all,
>
> I made a shepherd review of the document. The review can be found
> at:
>
>
> ·         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
> Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf
>
> ·         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
> 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.
>
> ____________________________________________________________________
> _____________________________________________________
>
>
>
> 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.

_________________________________________________________________________________________________________________________

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.