Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Joel Halpern <jmh@joelhalpern.com> Thu, 19 May 2022 13:00 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DEEC14F75F; Thu, 19 May 2022 06:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 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, NICE_REPLY_A=-1.857, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 AJ4aJkOxRIO0; Thu, 19 May 2022 06:00:08 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 81F8EC14F726; Thu, 19 May 2022 06:00:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4L3qhS1QJtz1ntrZ; Thu, 19 May 2022 06:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1652965208; bh=ALl2X7hF9bwzRuVJd9ffNh1X9LkaUpfWBgdFLbDsx1Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=P5WdbYAqw0dR4k3jq+Vm5aEwoZ4QVI8m23+PkazjzYYnMkQZvzlRC1kUQCUNYs4vs W+vehXfDBrT8Kt2qqp30pB06Lfiaa1OdLZICUN5UzQiHlO01Icdn5BEKfUhgHEVem/ msZLq7LlPej2P5KkNyqufzTixgcdHSTR2PRA24/4=
X-Quarantine-ID: <nS8ZznP2L9xo>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.20.80] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4L3qhQ1wX1z1pVtM; Thu, 19 May 2022 06:00:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------PYYG6LYnMBzwG6zCdWer6Grh"
Message-ID: <03388407-6329-c223-4d25-4b630c2b6ba2@joelhalpern.com>
Date: Thu, 19 May 2022 09:00:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Med Boucadair <mohamed.boucadair@orange.com>, James Guichard <james.n.guichard@futurewei.com>, sfc@ietf.org, ippm@ietf.org
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <525_1649935673_62580539_525_487_2_d0a4949b3d9c4424a0261012c7ce6188@orange.com> <CA+RyBmX3MdqVX5=hEsO+9SMbpXw+enwnm_qb4+-6smqbsTPPwg@mail.gmail.com> <CAMFZu3NZBgKXHrktn04LbwW33S+j+kGG5hx2A+1+jJ8aasCRag@mail.gmail.com> <14665_1651047374_6268FBCD_14665_484_6_addb2a5f712d4307a463d0582cc0a8a0@orange.com> <CAMFZu3O-vEAnrBE6rhuFh_POPD5E2i_bHvdBx=GUjRKxk3AOYw@mail.gmail.com> <3dba81e6-3a42-3643-dc98-a750891d47f5@joelhalpern.com> <CA+RyBmU+o5spc8M_54Voe+4E_A2M+Q2oE6LyJgSN4+=MCtVrcg@mail.gmail.com> <CAMFZu3MxRx5T3XgTJfBoCpgz1pH_4tNKSdk=NJ0DXELgnCRFxw@mail.gmail.com> <1e2f0696-658d-29d4-71f2-b96a3e088f4c@joelhalpern.com> <CAMFZu3McUxjVTrAoT6hOWOQtiWkKg1=vMpznHzTMs-Yha=oHRA@mail.gmail.com> <c7de197d-6e0f-bc13-7798-2ed968efabd3@joelhalpern.com> <CAMFZu3Of0SgCdWnnrQ0Jbt6-4+pFMSMPFDeNGkX2vbktGjPR=Q@mail.gmail.com> <CAMFZu3P-1aHJg3J3k4+UnZ5G3ZsPjKx16Ogs2zK=6qcbJ1kWCg@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAMFZu3P-1aHJg3J3k4+UnZ5G3ZsPjKx16Ogs2zK=6qcbJ1kWCg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/gqdiWn6XCa5wh5RHuC9-aAlHYnw>
Subject: Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2022 13:00:12 -0000
Thank you Shwetha. That looks good. Jim and I will be working on moving things forward. Yours, Joel On 5/19/2022 12:47 AM, Shwetha Bhandari wrote: > Hi Joel, > > We have published a -10 version of the draft based on this discussion. > Please check > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-10.txt and > let us know if it is ready to progress for IESG review. > > Thanks, > Shwetha > > On Wed, May 4, 2022 at 10:02 AM Shwetha Bhandari > <shwetha.bhandari@thoughtspot.com> wrote: > > Ack, will add text to this effect. > > Thanks > Shwetha > > On Wed, May 4, 2022, 9:23 AM Joel Halpern <jmh@joelhalpern.com> wrote: > > If we do not tell the implementors that there can be multiple > iOAM headers, and how they are required to process them, then > some implementors will follow logic we do not want. > > > For example, you have various selective iOAM headers. So an > SFF looks at the next header to check for iOAM. Seems it is > iOAM. And then seems the content is iOAM it can ignore. A > naive implementation might well stop right there and proceed > with normal SFF processing. Since you don't want that, just > write into the spec what the WG expects. > > > Yours, > > Joel > > On 5/3/2022 11:22 PM, Shwetha Bhandari wrote: >> Why do we need to call that out explicitly in this draft? >> Isn't that part of header processing anyway? >> >> Thanks >> Shwetha >> >> On Wed, May 4, 2022, 6:24 AM Joel Halpern >> <jmh@joelhalpern.com> wrote: >> >> Can we have just a sentence or two saying that if there >> are multiple iOAM options, the SFF must check all of them >> for relevance and act on all relevant ones? >> >> >> Yours, >> >> Joel >> >> On 5/3/2022 8:26 PM, Shwetha Bhandari wrote: >>> Hi Greg, Joel, >>> >>> The purpose of these options are different. Reiterating >>> the use cases described in the >>> draft-ietf-ippm-ioam-deployment draft : hop by hop >>> tracing related options are -pre-allocated, >>> incremental,direct export. The edge-to-edge option is >>> not collecting trace but metrics at the edge and helps >>> in correlation e.g sequence number is inserted and used >>> to identify packet loss rate. The proof-of-transit >>> option is used to prove that the packet has traversed >>> the check points in the networks. >>> There is also IOAM namespace that is used to collect >>> specific data types in trace options and a node can be >>> configured to process trace options with a specific >>> namespace, this is useful when we have nodes with >>> varying implementation of trace option data types defined. >>> Restricting IOAM option in NSH to a specific number will >>> make it difficult to deploy. Hence I don't see a need to >>> update the current draft to add any of this >>> restrictions. Let's use draft-ietf-ippm-ioam-deployment >>> to understand the use cases and deployment modes. >>> >>> Thanks >>> Shwetha >>> >>> >>> On Wed, May 4, 2022, 3:01 AM Greg Mirsky >>> <gregimirsky@gmail.com> wrote: >>> >>> Hi Joel, >>> thank you for highlighting this question, I've >>> missed it. >>> >>> As we've discussed earlier, several IOAM trace >>> options have been defined: >>> >>> * pre-allocated >>> * incremental >>> * edge-to-edge >>> * proof-of-transit >>> * direct export >>> * hybrid two-step >>> >>> I cannot find a scenario when using more than one >>> IOAM trace option that could be beneficial, and >>> useful for an operator. I think that if there is no >>> use case, then the restricting number of IOAM trace >>> options used is reasonable and helps implementors in >>> developing interoperable implementations. >>> >>> Regards, >>> Greg >>> >>> On Mon, May 2, 2022 at 2:42 PM Joel Halpern >>> <jmh@joelhalpern.com> wrote: >>> >>> (Sorry, catching up on some emails I missed.) >>> >>> If we want to allow multiple iOAM headers (up to >>> the WG) then I think the document needs to be >>> clear on the meaning. If there are multiple are >>> all supposed to be processed, just the top one >>> until something removes it, a random one of the >>> receivers choice? (Yes, that last is unlikely.) >>> >>> Yours, >>> >>> Joel >>> >>> On 4/27/2022 4:44 AM, Shwetha Bhandari wrote: >>>> Hi Med, >>>> >>>> Thanks for the confirmation and quick review. >>>> >>>> On, >>>> >>>> This means the new requested TBD_IOAM value >>>> will also be a valid next protocol. >>>> However, I wonder whether IOAM in IOAM in >>>> NSH is really something you want to have. >>>> If not, I suggest the text is updated to >>>> exclude it from the allowed value in the >>>> above excerpt. >>>> >>>> Per earlier discussion in this thread, quoting >>>> Frank's mail here for reference: >>>> >>>> In addition, I don’t think that >>>> draft-ietf-sfc-ioam-nsh would be the >>>> appropriate place to discuss and restrict >>>> deployment options. E.g., I’m not sure why >>>> we’d want to restrict a deployment to using >>>> a single IOAM header only. E.g., one could >>>> think of using different headers for >>>> different namespaces or groups of >>>> namespaces for operational reasons. IMHO, >>>> such a discussion – if we really need it - >>>> would belong into >>>> draft-ietf-ippm-ioam-deployment, rather >>>> than into a draft that defines the encap of >>>> IOAM into NSH. >>>> >>>> I think the text on Next Protocol should be as >>>> is. We should not add restrictions on number of >>>> IOAM headers that could be added to the packet. >>>> >>>> Thanks, >>>> Shwetha >>>> >>>> >>>> >>>> On Wed, Apr 27, 2022 at 1:46 PM >>>> <mohamed.boucadair@orange.com> wrote: >>>> >>>> Hi Shwetha, all, >>>> >>>> The changes look great. Thanks. >>>> >>>> There is one specific point not addressed >>>> in previous replies. This is related to >>>> this text: >>>> >>>> Next Protocol: 8-bit unsigned integer that >>>> determines the type of >>>> >>>> header following IOAM. The semantics of >>>> this field are >>>> >>>> identical to the Next Protocol field in >>>> [RFC8300]. >>>> >>>> This means the new requested TBD_IOAM value >>>> will also be a valid next protocol. >>>> However, I wonder whether IOAM in IOAM in >>>> NSH is really something you want to have. >>>> If not, I suggest the text is updated to >>>> exclude it from the allowed value in the >>>> above excerpt. >>>> >>>> Other than that, I think that the draft is >>>> ready to move forward. >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> *De :* Shwetha Bhandari >>>> <shwetha.bhandari@thoughtspot.com> >>>> *Envoyé :* mercredi 27 avril 2022 10:06 >>>> *À :* James Guichard >>>> <james.n.guichard@futurewei.com>; >>>> sfc-chairs@ietf.org >>>> *Cc :* BOUCADAIR Mohamed INNOV/NET >>>> <mohamed.boucadair@orange.com>; Frank >>>> Brockners (fbrockne) >>>> <fbrockne=40cisco.com@dmarc.ietf.org>; >>>> sfc@ietf.org; ippm@ietf.org; Tal Mizrahi >>>> <tal.mizrahi.phd@gmail.com>; >>>> draft-ietf-sfc-ioam-nsh@ietf.org; Greg >>>> Mirsky <gregimirsky@gmail.com> >>>> *Objet :* Re: [sfc] WGLC for >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhHpnETuWA$> >>>> >>>> Dear SFC chairs, >>>> >>>> A new version of the draft >>>> I-D.ietf-sfc-ioam-nsh has been submitted >>>> per the discussion in this thread. >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09 >>>> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhFd29kDew$> >>>> >>>> >>>> Can we please progress this draft to IESG >>>> if there are no further comments? >>>> >>>> Thanks, >>>> >>>> Shwetha >>>> >>>> On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky >>>> <gregimirsky@gmail.com> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> thank you for the proposed resolution. >>>> I agree with Med, direct normative >>>> reference to I-D.ietf-sfc-oam-packet >>>> seems like the logical conclusion of >>>> our discussion of the use of the NSH O >>>> bit. Please note that we're referring >>>> to I-D.ietf-sfc-oam-packet in the >>>> Active SFC OAM draft, e.g.,: >>>> >>>> The O bit in NSH MUST be set, >>>> according to [I-D.ietf-sfc-oam-packet]. >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> On Thu, Apr 14, 2022 at 4:27 AM >>>> <mohamed.boucadair@orange.com> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> I prefer we go for an explicit >>>> reference to >>>> I-D.ietf-sfc-oam-packet rather than >>>> “any update to RFC8300”. This is >>>> consistent with the usage in the >>>> other OAM draft. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> *De :* Shwetha Bhandari >>>> <shwetha.bhandari@thoughtspot.com> >>>> *Envoyé :* jeudi 14 avril 2022 12:06 >>>> *À :* Greg Mirsky >>>> <gregimirsky@gmail.com> >>>> *Cc :* BOUCADAIR Mohamed INNOV/NET >>>> <mohamed.boucadair@orange.com>; >>>> Frank Brockners (fbrockne) >>>> <fbrockne=40cisco.com@dmarc.ietf.org>; >>>> sfc-chairs@ietf.org; sfc@ietf.org; >>>> ippm@ietf.org; James Guichard >>>> <james.n.guichard@futurewei.com>; >>>> Tal Mizrahi >>>> <tal.mizrahi.phd@gmail.com>; >>>> draft-ietf-sfc-ioam-nsh@ietf.org >>>> *Objet :* Re: [sfc] WGLC for >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!LWQuxxxKpUum5gUoK44-znjehj2YRtlGMOATxfRVSc-7JOrPsk4BA4iP0oLQE4d0rObPhOCG_1iiipywftwMIMOEWh8lJI4$> >>>> >>>> Hi Med, Greg, >>>> >>>> How about this text : >>>> >>>> “The O-bit MUST be handled >>>> following the rules in and any >>>> updates to [RFC8300] ." >>>> >>>> Given that I-D.ietf-sfc-oam-packet >>>> will update RF8300 and there could >>>> be others in future? >>>> >>>> Thanks, >>>> >>>> Shwetha >>>> >>>> On Tue, Apr 12, 2022 at 9:24 PM >>>> Greg Mirsky <gregimirsky@gmail.com> >>>> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> I believe that the text you've >>>> quoted is helpful. I would >>>> suggest changing references >>>> from [RFC8300] to >>>> [I-D.ietf-sfc-oam-packet] >>>> throughout that paragraph. >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> On Tue, Apr 12, 2022 at 7:56 AM >>>> Shwetha Bhandari >>>> <shwetha.bhandari@thoughtspot.com> >>>> wrote: >>>> >>>> Med, >>>> >>>> Thanks for the details: >>>> this is exactly what we had >>>> before the latest revision: >>>> >>>> *4.2 >>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>. >>>> IOAM and the use of the NSH >>>> O-bit* >>>> >>>> [RFC8300] defines an "O >>>> bit" for OAM packets. Per >>>> [RFC8300 >>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] >>>> the O >>>> >>>> bit must be set for OAM >>>> packets and must not be set >>>> for non-OAM >>>> >>>> packets. Packets with >>>> IOAM data included MUST >>>> follow this >>>> >>>> definition, i.e. the O >>>> bit MUST NOT be set for >>>> regular customer >>>> >>>> traffic which also >>>> carries IOAM data and the O >>>> bit MUST be set for >>>> >>>> OAM packets which carry >>>> only IOAM data without any >>>> regular data >>>> >>>> payload. >>>> >>>> This was removed as per the >>>> discussion in this thread. >>>> Please check >>>> https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/ >>>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$> >>>> >>>> It looks like we are going >>>> in a loop here. This >>>> definition of SFC OAM >>>> packet to include the OAM >>>> data that comes in inner >>>> packets via the next >>>> protocol header chain is >>>> introduced in >>>> draft-ietf-sfc-oam-packet >>>> to update the RFC8300. >>>> >>>> Jim, What are you thoughts >>>> on this? Should we >>>> reintroduce the above text ? >>>> >>>> Thanks, >>>> Shwetha >>>> >>>> _________________________________________________________________________________________________________________________ >>>> >>>> >>>> >>>> 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. >>>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!MZ3Fw45to5uY!KzP7tEXj2r_E1qNyQ90q9rykJ0iG0HA0CecIGBFXEIXiWITYay7wwoC0HbiFfO2GyUarxht3JEY45vcV4uCtZ8Xkud0uv58$> >>>
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… xiao.min2
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari