Hi Thomas,
Thank you for preparing this revised version. I think almost all my comments are addressed in this version. However, I still dont see the need to have new registries that only mirror existing ones. For example, and unless I missed some subtleties, it would be sufficient to say that the flag values are taken from <https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtm l#segment-routing-header-flags> https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml #segment-routing-header-flags rather than adding the following in the I-D: +--------+-------------------+--------------------------------------+ | Value | Description | Reference | +--------+-------------------+--------------------------------------+ | 0-1 | Unassigned | | +--------+-------------------+--------------------------------------+ | 2 | O-flag | [RFC-ietf-6man-spring-srv6-oam-13] | +--------+-------------------+--------------------------------------+ | 3-7 | Unassigned | | +--------+-------------------+--------------------------------------+ Table 2: "IPFIX IPv6 SRH Flags" registry which is similar in term of encoding and values as what was set by RFC9256: IANA has registered the following in the "Segment Routing Header Flags" subregistry in the "Internet Protocol Version 6 (IPv6) Parameters" registry: +=====+=============+===========+ | Bit | Description | Reference | +=====+=============+===========+ | 2 | O-flag | RFC 9259 <https://datatracker.ietf.org/doc/html/rfc9259> | +-----+-------------+-----------+ BTW, I guess you initially meant: NEW: Table 2: "IPFIX IPv6 SRH Flags" registry Note to IANA: Add a note to the "Segment Routing Header Flags" registry so that new values are echoed in the new "IPFIX IPv6 SRH Flags instead of CURRENT: Table 2: "IPFIX IPv6 SRH Flags" registry Note to IANA: Add a note to the registry so that new values are echoed in the new "IPFIX SRv6 EndPoint Behavior The same comment applies for the values that can be directly taken from https://www.iana.org/assignments/segment-routing/segment-routing.xhtml #srv6-endpoint-behaviors. Cheers, Med De : [email protected] <[email protected]> Envoyé : jeudi 15 septembre 2022 20:08 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; [email protected]; [email protected] Cc : [email protected]; [email protected] Objet : RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Dear Med, Many thanks for the comprehensive review. Much appreciated. We merged all your input to the upcoming -01 release. https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-sr v6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt The diff to the current -00 version can be found here: https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draf t-ietf-opsawg-ipfix-srv6-srh-00.txt <https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/dra ft-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubuserconten t.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsaw g-ipfix-srv6-srh-01.txt> &url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ip fix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt For some we need further clarifications if we addressed them correctly. I would appreciate if you could clarify the following three points: Med> Section 2, remark: "Why do we need three IE, srhSegmentIPv6ListSection, srhSegmentIPv6BasicList and srhSectionIPv6, to expose SRH Segment List Thomas> Section 5.1 should provide the answer. If that should not be sufficient, please suggest how this could be better expressed. Med> Section 2: remark: "as series of n octets" is not clearly comprehensible. Thomas> Extended to "as series of n octets in IPFIX". Does that makes it clearer? Med> Section 4.11, remark: "Do you really need to define a new registry here?" Thomas> The registry could potentially be used (and updated) by non IPFIX people. Best wishes Thomas From: OPSAWG <[email protected] <mailto:[email protected]> > On Behalf Of [email protected] <mailto:[email protected]> Sent: Tuesday, September 6, 2022 10:19 AM To: Joe Clarke (jclarke) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Hi all, I support. FWIW, the authors may found some quick comments at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgra f-opsawg-ipfix-srv6-srh-05-rev%20Med.pdf <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit hub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf -opsawg-ipfix-srv6-srh-05-rev%2520Med.pdf&data=05%7C01%7CThomas.Graf%4 0swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9be ec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 %7C%7C%7C&sdata=GmDWAcd71AYy6N%2BWx5469KaEjcmDCLJ%2FDsVv3LINv88%3D&res erved=0> * doc: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit hub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf -opsawg-ipfix-srv6-srh-05-rev%2520Med.doc&data=05%7C01%7CThomas.Graf%4 0swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9be ec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 %7C%7C%7C&sdata=RCDJoUkBTJ%2Fooe%2BvJEOTagdDY64LIVvfrH4RhyBsAKI%3D&res erved=0> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgra f-opsawg-ipfix-srv6-srh-05-rev%20Med.doc Cheers, Med De : OPSAWG <[email protected] <mailto:[email protected]> > De la part de Joe Clarke (jclarke) Envoyé : jeudi 18 août 2022 22:14 À : [email protected] <mailto:[email protected]> Objet : [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Hello, WG. Wed like to begin a two week call for adoption of this work. Even as an individual draft it has already received some reviews and has iterated quite a bit. Based on IETF 114 there does seem to be interest in adopting this in opsawg, but we need a formal adoption poll. Please review and provide your adoption thoughts no later than September 1, 2022. Thanks. Joe ______________________________________________________________________ ___________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
