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

[[e-mail]]

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:[e-mail]]
Envoyé : jeudi 24 juin 2021 08:35
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]; [e-mail]
Cc : [e-mail]
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, June 24, 2021 1:24 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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:[e-mail]>; [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://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.

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: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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://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.

_________________________________________________________________________________________________________________________



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.