Hi Éric, As the Doc Shepherd, I'm sharing some context related to this comment:
> ### Section 6.3 > > Beside encapsulation, I do not see how multiple (S)RHs could be in > one IPv6 > packet. Anyway, the router will, per RFC 8200, only act on the > outermost one. > I.e., strongly suggest that this I-D specifies that only the > outermost SRH & > associated behavior are specified. FYI, this point was discussed in the WG especially that there is no SPING document that motivates/explains the use of multiple SRHs. Please check: https://mailarchive.ietf.org/arch/msg/opsawg/SVm4TZk1v6-a0WJwALk3FrUunFU/ for why the authors think this section is useful to be maintained in the document. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker <nore...@ietf.org> > Envoyé : lundi 22 mai 2023 16:17 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg- > cha...@ietf.org; opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com>; BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com> > Objet : Éric Vyncke's Yes on draft-ietf-opsawg-ipfix-srv6-srh-10: > (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-opsawg-ipfix-srv6-srh-10: Yes > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > Please refer to > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling- > ballot- > positions%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C288ff > 9f6aed04ca9bbdf08db5acf2f32%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C638203618122821508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata=%2BiI1qjYawayWZInHErAiC3k9fr4luEapIsKb%2BqPHYg0%3D&reserved > =0 > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found > here: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-srv6- > srh%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C288ff9f6aed > 04ca9bbdf08db5acf2f32%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638203618122821508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =tII2%2FBSvVD6sz2LnIPkwUPwDwM3IGEWUOCHTzzhdfmM%3D&reserved=0 > > > > ------------------------------------------------------------------ > ---- > COMMENT: > ------------------------------------------------------------------ > ---- > > # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-srv6- > srh-10 > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies > would be > appreciated even if only for my own education). > > Special thanks to Mohamed Boucadair for the shepherd's detailed > write-up > including the WG consensus and the justification of the intended > status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS > > ### More than data plane > > I like the idea of exporting srhIPv6ActiveSegmentType for > operation, it goes > well beyond the plain export of the SRH header. I just fear that > the extra > information is redundant and will be repeated quite often. > > ### Section 5.1.9 > > What would happen if this information is learned by two sources ? > > ### Section 6.3 > > Beside encapsulation, I do not see how multiple (S)RHs could be in > one IPv6 > packet. Anyway, the router will, per RFC 8200, only act on the > outermost one. > I.e., strongly suggest that this I-D specifies that only the > outermost SRH & > associated behavior are specified. > > _________________________________________________________________________________________________________________________ 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
