Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh
mohamed.boucadair@orange.com Tue, 20 September 2022 09:19 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236FC15258C for <opsawg@ietfa.amsl.com>; Tue, 20 Sep 2022 02:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNDOO6T66H-4 for <opsawg@ietfa.amsl.com>; Tue, 20 Sep 2022 02:19:35 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DE7C14F725 for <opsawg@ietf.org>; Tue, 20 Sep 2022 02:19:34 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar22.francetelecom.fr (ESMTP service) with ESMTPS id 4MWwwh4jJyz2xR1; Tue, 20 Sep 2022 11:19:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1663665572; bh=7LrIM2ci91ZubQ100yNustfuZn2gO8u9WhVeLYrnYiY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=aavEdxHKZy1ohqmYAPuVhHWAYI+WbJ4bLrWPCxzQwWrq5DIjdGEreemBxvF1QHCjy A4xQ5rlQSXect8qcRWy/9AMpVNLYMjW+rWvRC4hekTP7i2fmr/c5KY30IIQ8XwFt3F Ij1BnXV6awJ6r5G/7gJDMc8hYrUuCn5gkU4vlmiJD/ng7yWcgxcAnUWM/pQJqhXXZF lS81j253ZL9PwU+N9MzTjT1c3lS2noInCF0aEB+EAdLlKOHdhelZLaPYABVBr3+s4Q lpGLgXperG5c07n3PjbY77qDos6siolh9yZ7RE0KkSYflaRxz8wJ2qLAwBWWlZLnxQ F2Ym8ojeRo9vw==
From: mohamed.boucadair@orange.com
To: Benoit Claise <benoit.claise@huawei.com>, "Thomas.Graf@swisscom.com" <Thomas.Graf@swisscom.com>, "jclarke=40cisco.com@dmarc.ietf.org" <jclarke=40cisco.com@dmarc.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
CC: "pierre.francois@insa-lyon.fr" <pierre.francois@insa-lyon.fr>
Thread-Topic: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh
Thread-Index: AQHYzGbSkNenOfX58E6FatPIULX/CK3nyOLw
Content-Class:
Date: Tue, 20 Sep 2022 09:19:31 +0000
Message-ID: <30922_1663665572_632985A4_30922_314_1_e530d834a7a741aa8ec4a1efcd11f494@orange.com>
References: <BN9PR11MB5371EF97C81F4D53CFD5FC77B86D9@BN9PR11MB5371.namprd11.prod.outlook.com> <30955_1662452342_63170276_30955_240_1_24f1bf268bbf4ea08f058aa6ee5d31a6@orange.com> <ZRAP278MB0176383B6F6427DA40FC924889499@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM> <51222224a12d463fba8c84fe9cdc2044@orange.com> <8aa51620-98df-003b-3e7a-bec5bb8c9602@huawei.com> <18795_1663590103_63285ED7_18795_259_1_0bebdd34f5e94100ae01191f38a6bad1@orange.com> <5741704f-c264-322c-d971-1b72996ae16e@huawei.com>
In-Reply-To: <5741704f-c264-322c-d971-1b72996ae16e@huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-09-20T05:21:38Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=28e214f4-9316-47a5-b47d-af99eff6173b; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_e530d834a7a741aa8ec4a1efcd11f494orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/H8FMhrnJnJC1vqFdVb2OuhAxJqc>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2022 09:19:39 -0000
Hi Benoît, No problem to setup a quick call to discuss this if needed. For sure, the existing IPv6 SRH Flags registry is useful to associate some flags with a meaning. However, the observed values may include flags for which no meaning is defined (yet). That is why the statement ““Values for this Information Element are listed in the "IPFIX IPv6 SRH Flags" registry”” is to be revisited. Also, mirroring the content of the registry is useless for the intended behavior. Cheers, Med De : Benoit Claise <benoit.claise@huawei.com> Envoyé : lundi 19 septembre 2022 22:29 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Thomas.Graf@swisscom.com; jclarke=40cisco.com@dmarc.ietf.org; opsawg@ietf.org Cc : pierre.francois@insa-lyon.fr Objet : Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Hi Med, On 9/19/2022 2:21 PM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote: Hi Benoît, Thank you for the follow-up. Actually, the more I look into this, the more I’m convinced that we don’t need a new registry for the flags and that the statement “Values for this Information Element are listed in the "IPFIX IPv6 SRH Flags" registry” is restrictive (inaccurate(?)). The flags should be exported as ** observed ** not as set in the registry. Observed for sure, but for one specific flag value, we must find the semantic. This is where the registry comes in place, for matching an observed value with a semantic Think about discarded packets because some flags are set (including those already for which a meaning is already defined such as the O flag) while the processing of these flags is not supported by a router. In such cases, one use of the srhFlagsIPv6 IE would be to display the erroneous set of flags together with some error counters. The values of the IE is not “taken from the IANA registry”. Am I wrong, or in case, you are overloading the srhFlagsIPv6 with your own convention? How do you want the collector to interpret this flow. That said, I fully agree that the spec has to indicate “Data Type Semantics: flags” for that IE. The same would apply for the srhSegmentEndpointBehavior IE. Please let me know if I’m missing something. Thanks. Maybe we speak cross purposes. Shall we set up a quick call? Regards, Benoit Cheers, Med De : Benoit Claise <benoit.claise@huawei.com><mailto:benoit.claise@huawei.com> Envoyé : samedi 17 septembre 2022 17:39 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com><mailto:mohamed.boucadair@orange.com>; Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>; jclarke=40cisco.com@dmarc.ietf.org<mailto:jclarke=40cisco.com@dmarc.ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : pierre.francois@insa-lyon.fr<mailto:pierre.francois@insa-lyon.fr>; me <benoit.claise@huawei.com><mailto:benoit.claise@huawei.com> Objet : Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Hi Med, Thanks for your comments. I visited IANA in Philly to validate this propose, but we could re-evaluate & discuss about it. We need a registry because just telling that we take the value from https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags is not sufficient as we also need to specify the following IPFIX fields: - Abstract Data Type. (unsigned8 in this srhFlagsIPv6 case) - Data Type Semantics (flags in srhFlagsIPv6 case) Now, if your point is that we don't really to mention the initial values ... Initial values in the registry are defined by the table below. +--------+-------------------+--------------------------------------+ | 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 ... I agree it's not strictly necessary but it helps (me/the IPFIX experts) to understand, from this document, which type of values are currently available. See inline. On 9/16/2022 9:34 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote: Hi Thomas, Thank you for preparing this revised version. I think almost all my comments are addressed in this version. However, I still don’t 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.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” You are right (since https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags is "IETF review" while https://www.iana.org/assignments/ipfix/ipfix.xhtml is "Expert Review") 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. Yes OLD: Table 4: "IPFIX SRV6 Endpoint Behavior" registry Note to IANA: Add a note to the registry so that new values are echoed in the new "IPFIX SRv6 EndPoint Behavior NEW: Table 4: "IPFIX SRV6 Endpoint Behavior" registry Note to IANA: Add a note to the "IPFIX SRV6 Endpoint Behavior" registry so that new values are echoed in the new "IPFIX SRv6 EndPoint Behavior Regards, Benoit Cheers, Med De : Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com> <Thomas.Graf@swisscom.com><mailto:Thomas.Graf@swisscom.com> Envoyé : jeudi 15 septembre 2022 20:08 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com><mailto:mohamed.boucadair@orange.com>; jclarke=40cisco.com@dmarc.ietf.org<mailto:jclarke=40cisco.com@dmarc.ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : benoit.claise@huawei.com<mailto:benoit.claise@huawei.com>; pierre.francois@insa-lyon.fr<mailto:pierre.francois@insa-lyon.fr> 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-srv6-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/draft-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-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 <opsawg-bounces@ietf.org<mailto:opsawg-bounces@ietf.org>> On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> Sent: Tuesday, September 6, 2022 10:19 AM To: Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org<mailto:jclarke=40cisco.com@dmarc.ietf.org>>; opsawg@ietf.org<mailto:opsawg@ietf.org> 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: 1. pdf: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-05-rev%2520Med.pdf&data=05%7C01%7CThomas.Graf%40swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GmDWAcd71AYy6N%2BWx5469KaEjcmDCLJ%2FDsVv3LINv88%3D&reserved=0> 2. doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.doc<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-05-rev%2520Med.doc&data=05%7C01%7CThomas.Graf%40swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCDJoUkBTJ%2Fooe%2BvJEOTagdDY64LIVvfrH4RhyBsAKI%3D&reserved=0> Cheers, Med De : OPSAWG <opsawg-bounces@ietf.org<mailto:opsawg-bounces@ietf.org>> De la part de Joe Clarke (jclarke) Envoyé : jeudi 18 août 2022 22:14 À : opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh Hello, WG. We’d 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. _________________________________________________________________________________________________________________________ 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] CALL FOR ADOPTION: draft-tgraf-opsawg-ip… Joe Clarke (jclarke)
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Zafar Ali (zali)
- Re: [OPSAWG] FW: CALL FOR ADOPTION: draft-tgraf-o… Chongfeng Xie
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Paolo Lucente
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Haoyu Song
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Alex Huang Feng
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Paolo Volpato
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Qin Wu
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Benoit Claise
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Ahmed Abdelsalam (ahabdels)
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Diego R. Lopez
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Giuseppe Fioccola
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Benoit Claise
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Joe Clarke (jclarke)
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Thomas.Graf
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Benoit Claise
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Thomas.Graf
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Benoit Claise
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Thomas.Graf
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… mohamed.boucadair
- Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsaw… Benoit Claise