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: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Sent: Thursday, June 24, 2021 7:39 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type Re-, I forgot to mention this one about this long sentence: " 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. " I don't parse the part I highlighted. I prefer what you had in the previous version, though. Thanks. Cheers, Med De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Envoyé : jeudi 24 juin 2021 07:35 À : thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.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: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type 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 : thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> [mailto:thomas.g...@swisscom.com] Envoyé : jeudi 24 juin 2021 06:23 À : 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, 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<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> 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/<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: 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: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: Wednesday, June 23, 2021 5: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: 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<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> 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
