From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Tianran Zhou <zhoutian...@huawei.com> Sent: 24 June 2021 07:34 To: mohamed.boucad...@orange.com; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
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: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] Sent: Thursday, June 24, 2021 1:24 PM To: Tianran Zhou <zhoutian...@huawei.com>; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org Cc: opsawg@ietf.org 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:zhoutian...@huawei.com] Envoyé : jeudi 24 juin 2021 05:09 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> Cc : opsawg@ietf.org<mailto:opsawg@ietf.org> 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:opsawg-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Sent: Wednesday, June 23, 2021 11:47 PM To: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
