Re: [ippm] AD review of draft-ietf-ippm-stamp
Greg Mirsky <gregimirsky@gmail.com> Thu, 08 August 2019 15:56 UTC
Return-Path: <gregimirsky@gmail.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 AB22712019C; Thu, 8 Aug 2019 08:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpFAPQNaeSjc; Thu, 8 Aug 2019 08:56:43 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B354120168; Thu, 8 Aug 2019 08:56:42 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id p17so89404155ljg.1; Thu, 08 Aug 2019 08:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w+Pwov9UXbku1M1SJnlVWXf9lwXFKa4d43Vkkb8fzGU=; b=sIWdCn+X6YsmaOIc/CaPWCMttxIsG+C95tVNIE0OtHp/8iSv0raqcEyxUCIuBdjbtZ 0nArSnW3dXL90VS2rsJw9rFlVWa73kLBORFjk03CJwZz3lTkBtGLoAE4tsUWa+bB+cUS ozvlF7d+QdC7HgY0i8eWWnLMcdXAZc7QNhw+rhc90KrNCGZnZGXQAjlRwz3e81ab6ufz yc6ew5vrWu3UDeC24elZIMi+wLGzdEKnYKQ7NilEuD0TFwATrBtKkvID3h2IoMkt2+qF JXT3j76f+0IRSQkWSIupovEOAkjNaj/mPROPFSIJpfsakaoo/MGdsBtoWOXi8Tqgif+c wZUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w+Pwov9UXbku1M1SJnlVWXf9lwXFKa4d43Vkkb8fzGU=; b=EpFe0GC8DoHbieDRin76VQm3FzKAadGohzvvPD0SVfPtxiQWa7F54g7CMikgBYL/DN c3dosJo9SDWKgmAcvAg44Fccayv/zp33wvORCUeJ0dO/5UpTWR/7yFy1a0+CVkHb4fS2 O1IOEmRXDujk987m415bSUi4Z6YZR6onPrMQoa7+dHzO/MZ0GfII5QyWuGIUiY6PgO7k 7gxd/IZxAiO2MdbV1semPqVGMIGJ7dNyKbs53OMfamYrVmaCJhlra5XZYnF+aDuZQGhy +LUHxZxAKD6Yv9zgrYKZZDXBYJg0rHisFnmQEcZsL/6SYTkNHxjADwXGTBv37IKzg+CJ WFbw==
X-Gm-Message-State: APjAAAVhP7HmfCXXDlG77IrXpPtr5ZBr2nlNONgFQ2zFJsRyaW/mcF/Y Nmrltwx15r9BTcVgmOublkT5xwwRF6nXmlrnytk=
X-Google-Smtp-Source: APXvYqwyd0sQ8DWNdf8duMrWE6sQk31CacGWzLGujmVce78bwn6jSI2/HNg49t4gZqaxZQFCTYrJQxSUhe1nqVICd/w=
X-Received: by 2002:a2e:8696:: with SMTP id l22mr8569804lji.201.1565279799923; Thu, 08 Aug 2019 08:56:39 -0700 (PDT)
MIME-Version: 1.0
References: <B617B303-6EBE-4E3B-AE5C-1438FF1C5D7F@kuehlewind.net> <CA+RyBmVEmKQu=LGp9eVT+x5e01LCSk_A4tQD=RE8Ett-R35BVg@mail.gmail.com> <11938018-8A65-483B-8176-A6E1C2A265A3@kuehlewind.net> <CA+RyBmX=Jx2yXrMXu4Y2VKX36iKphymb1Hkyfy0XhPGFmsUGzQ@mail.gmail.com> <B8047CA0-2F5E-48F8-9BE4-3FA41D742F12@kuehlewind.net> <CA+RyBmXPCe7TZQqPgsKsVnifZDG8O8wGafDn-nzYfGpx2OiaXQ@mail.gmail.com> <F167C330-76F4-48FC-B720-415CA190239C@broadcom.com> <CA+RyBmVtfXcwqu1RH-1JXnhpCZcbGgm30ubKGctUPnLNJCgVZQ@mail.gmail.com> <CAMZsk6f=x1j_fXAoqZ874y0nw7Y1wP0OeS9eFuToSBQfrqkJLQ@mail.gmail.com> <CA+RyBmVWZ3utikyBRm4TDhRDuMd3cZ9-otbuX=Mbg0ioAGjwHg@mail.gmail.com> <CAMZsk6eJf2xjsRJwnBtd5KFHbwO4KX3gEjs_Nv1Dhf39ZWjegA@mail.gmail.com> <CA+RyBmXHTjpbWv4FGpOsfL94Zip3MsVvESyka5M8PrmNKFB=YQ@mail.gmail.com> <CAMZsk6dGneYXFr3Xk_DuQnbwa=-ObV_SNdGOSj1Z203wW-PzTg@mail.gmail.com> <CALhTbppn9jpCLaSLR3QSN=yA0uDyXXMCQ+Rm4qFrR5OrjS31Dw@mail.gmail.com> <CAMZsk6eidFR-doLCvMim6HJZ142q_Q0V7XmiLP6Ki5_jmNvUxw@mail.gmail.com> <CALhTbppD+GSRf2U_eSPfm4RkTC1-vm-+rfuVJUesHmFiPxmnGw@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA0ADA7AE@njmtexg4.research.att.com> <CAMZsk6fODTiLctxJArHyVz9AvyKfrUwefPw0GPg+T3uhRFv6dg@mail.gmail.com> <CALhTbpqzriiZ8RqtFWR0+tjYUwj6A4AV=0d=w6_cMBHFHrF6Fw@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA0ADAA75@njmtexg4.research.att.com> <9AEB8751-44B2-41C0-84D8-39B69F7D55BF@cisco.com>
In-Reply-To: <9AEB8751-44B2-41C0-84D8-39B69F7D55BF@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 08 Aug 2019 08:56:28 -0700
Message-ID: <CA+RyBmXteNOH6nfoeF5cH8v2U7mOQPFxX6wHMqKSSPugCKZGrQ@mail.gmail.com>
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Cc: "MORTON, ALFRED C (AL)" <acm@research.att.com>, Henrik Nydell <hnydell@accedian.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>, "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072da16058f9d1ace"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/YRKUMaUEZQtHPEvp9tY22e-2rNA>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Aug 2019 15:57:03 -0000
Hi Rakesh and Henrik, thank you for a very informative discussion. Do you think the wording in Section 4.4 of the STAMP specification needs modification: Thus STAMP Session-Sender MUST be able to send test packets to destination UDP port number from the Dynamic and/or Private Ports range 49152-65535, test management system should find a port number that both devices can use. ... In the latter scenario, the test management system SHOULD set STAMP Session-Reflector to use UDP port number from the Dynamic and/or Private Ports range. I think that the text is not restrictive and can stay. What do you think? We can review and update STAMP YANG model in a separate thread. Regards, Greg On Thu, Aug 8, 2019 at 6:09 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote: > Thanks Henrik and Al for your feedbacks and discussions. > > > > I have few comments on the TWAMP yang model draft-ietf-ippm-twamp-yang: > > > > 1) Reflector side does not have autoallocate option. Only sender > side has it and both allow dynamic range ports only (and 862). > > leaf reflector-udp-port { > > type inet:port-number { > > range "862 | 49152..65535"; > > } > > > > leaf sender-udp-port { > > type union { > > type dynamic-port-number; > > type enumeration { > > enum autoallocate { > > description > > "Indicates that the Contol-Client will > > auto-allocate the TWAMP-Test (UDP) port number > > from the dynamic port range."; > > } > > > > 2) Autoallocate is still from the dynamic port range only. > > 3) Even with the dynamic UDP port, the backend and controller still > need to handle the case where the UDP port has been allocated to something > else on that node, as it is dynamic. > > 4) Well known ports can be handled by the backend similarly if there > was an error in provisioning. > > 5) This range issue seems to get propagated to the new work like > draft-ietf-ippm-stamp. > > > > Other than the VOIP example below, there is another example of the similar > case on Page 31 in https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt > as pointed out by Mirja in another thread. > > > > At this point, two vendors are saying the UDP port range for TWAMP is an > issue for them. As the existing implementations do not have such range > limit, operators may be using an UDP port outside this range, this means > moving to the TWAMP Yang model could be troublesome. > > > > Thanks, > > Rakesh > > > > > > *From: *ippm <ippm-bounces@ietf.org> on behalf of "MORTON, ALFRED C (AL)" > <acm@research.att.com> > *Date: *Thursday, August 8, 2019 at 5:02 AM > *To: *Henrik Nydell <hnydell@accedian.com>, Rakesh Gandhi < > rgandhi.ietf@gmail.com> > *Cc: *"draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, > IPPM Chairs <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, > IETF IPPM WG <ippm@ietf.org> > *Subject: *Re: [ippm] AD review of draft-ietf-ippm-stamp > > > > Hi Rakesh and Henrik, > > > > working from the VoIP testing example below, it seems as though > > “ability to test on a specific port in the User range, > > with prior agreement of users on the tested network” > > should have been asked for-as a feature during > > YANG model development? > > > > the authors used the Dynamic Range to avoid *accidentally* > > stepping on IANA-allocated User ports during auto-allocation: > > > > leaf sender-udp-port { > > type union { > > type dynamic-port-number; > > type enumeration { > > enum autoallocate { > > description > > "Indicates that the Contol-Client will > > auto-allocate the TWAMP-Test (UDP) port number > > from the dynamic port range."; > > } > > with RFC 6335: > > 6. Port Number Ranges > > > > TCP, UDP, UDP-Lite, SCTP, and DCCP use 16-bit namespaces for their > > port number registries. The port registries for all of these > > transport protocols are subdivided into three ranges of numbers > > [RFC1340], and Section 8.1.2 describes the IANA procedures for each > > range in detail: > > > > o the System Ports, also known as the Well Known Ports, from 0-1023 > > (assigned by IANA) > > > > o the User Ports, also known as the Registered Ports, from 1024- > > 49151 (assigned by IANA) > > > > providing our over-riding guidance. > > > > If we agree that the sort of testing you describe means > > adding a new feature to the model, then let’s give some thought > > to how that might best be done. > > > > Al > > > > *From:* Henrik Nydell [mailto:hnydell@accedian.com] > *Sent:* Thursday, August 8, 2019 3:51 AM > *To:* Rakesh Gandhi <rgandhi.ietf@gmail.com> > *Cc:* MORTON, ALFRED C (AL) <acm@research.att.com>; IPPM Chairs < > ippm-chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org>; Mirja Kuehlewind < > ietf@kuehlewind.net>; draft-ietf-ippm-stamp@ietf.org > *Subject:* Re: [ippm] AD review of draft-ietf-ippm-stamp > > > > Agree Rakesh. > > There is value in being able to for example as close as possibly mimic for > example a VoIP flow on a network path, using typical UDP ports (5060 for > example), and a typical VoIP IPG (20ms) and proper payload length to make > the TWAMP flows be treated in the same way as the real RTP traffic by the > network elements (firewalls, NAT or other port-sensitive devices). > > > > > > On Wed, Aug 7, 2019 at 6:02 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > > > Thanks Al and Henrik. > > If there is no specific requirement to add a limit on the UDP port range, > it would be good to not have it in the STAMP draft as well as in the TWAMP > Yang model. Let implementations decide what ports they can support (keeping > in mind the assigned ones) and let operators decide what port they like to > provision. > > > > Thanks, > > Rakesh > > > > > > On Wed, Aug 7, 2019 at 10:34 AM MORTON, ALFRED C (AL) < > acm@research.att.com> wrote: > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Henrik Nydell > *Sent:* Wednesday, August 7, 2019 4:30 AM > *To:* Rakesh Gandhi <rgandhi.ietf@gmail.com> > *Cc:* IPPM Chairs <ippm-chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org>; > Mirja Kuehlewind <ietf@kuehlewind.net>; draft-ietf-ippm-stamp@ietf.org > *Subject:* Re: [ippm] AD review of draft-ietf-ippm-stamp > > > > The range probably comes from the IANA definition of the ephemeral ports > (49152 to 65535) although these are defined for short-lived TCP and not > explicitly for UDP. Why this made it into the yang model for TWAMP-test > (which is UDP) I dont know, probably someone mixed it up with TCP and it > passed the reviewers without much thought. > > *[acm] * > > https://tools.ietf.org/html/rfc6335#section-6 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6335-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=Y3I4sW9cQ0UXh8cUXuPymXo9soP2KQFzein5oCkPdKE&e=> > > seems clear to me, without making the distinction between TCP and UDP > > you mention. There was discussion on the ippm-list IIRC, too. > > > > Most, if not all, implementations of TWAMP I have seen does not impose > limitations on the source UDP ports for the TWAMP-test packets when > configuring via CLI. For example neither Accedian, Exfo, Viavi, Juniper, > Nokia, Huawei impose any limitation like that when configuring via CLI or > GUI. > > > > With a yang model based configuration the user will of course be limited > if they use the yang model that only defines the ephemeral range as valid. > I see no severe disadvantages of this, but it would of course have been > better if the yang model was less restrictive, since the restriction has no > real value in itself. > > > > *[acm] ...*except avoiding a port assigned by IANA... > > > Al > > > > On Tue, Aug 6, 2019 at 8:07 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > Thanks Henrik. Where does this requirement come from? Also, how do I > configure the UDP port outside the range using the TWAMP Yang model? > > > > Thanks, > > Rakesh > > > > On Tue, Aug 6, 2019 at 11:19 AM Henrik Nydell <hnydell@accedian.com> > wrote: > > There is a distinction between "must be able to send to these destination > ports" and "must only be able to send to these destination ports" > > > > The first wording does not prohibit senders to be able to send also to > other destination ports. > > > > > > On Tue, Aug 6, 2019 at 4:57 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > Hi Greg, > > Many thanks for the reply. > > As there are already implementations out there where such restrictions do > not exist as discussed in another email thread (just forwarded them), the > following text with MUST is already violated. The TWAMP Yang model > draft-ietf-ippm-twamp-yang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> > should also not place such restriction. > > Section 4.4 > > Thus STAMP Session-Sender MUST be able to send test > > packets to destination UDP port number from the Dynamic and/or > > Private Ports range 49152-65535, test management system should find > a > > port number that both devices can use. > > > > Thanks, > > Rakesh > > > > On Sat, Aug 3, 2019 at 1:05 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Rakesh, > > my apologies for the misspelling of your name. > > Thank you for your kind consideration of the proposed update. > > Regarding the definition of the range of the valid UDP port numbers, > draft-ietf-ippm-twamp-yang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> uses > type dynamic-port-number as follows: > > typedef dynamic-port-number { > type inet:port-number { > range 49152..65535; > } > description "Dynamic range for port numbers."; > } > > to specify the valid range for a sender-udp-port. The range for a UDP port > number of a Session-Reflector has been specified slightly differently > because it includes the well-known port 862: > > leaf reflector-udp-port { > type inet:port-number { > range "862 | 49152..65535"; > } > description > "The destination UDP port number used in the > TWAMP-Test (UDP) test packets belonging to this > test session."; > } > > But, as we observe, in both cases definitions include the Dynamic/Private > range explicitly defined. I think that keeping STAMP specification > consistent with the TWAMP, TWAMP YANG data model in particular, in the way > the valid range of UDP ports is being specified, is beneficial to the STAMP > document. Hope you'll agree. > > > > Regards, > > Greg > > > > On Fri, Aug 2, 2019 at 10:53 AM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > Thanks Greg for considering my review comments. Good to see the message > format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ 30. This > should fix the interoperability issue between the two. This also gives few > (3) bytes for any future extensions. > > ------------------------------------------------------------------------ > > You may fix the spelling of my name and another typo below: > > OLD: > > and Rakesh Gandi or their > > > > NEW: > > and Rakesh Gandhi for their > > ---------------------------------------------------------------------- > > > > I did not see following comment addressed. Is that intentional? > > ------------------------------------------------ > > On Tue, Jul 9, 2019 at 9:11 AM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > > > Thanks Greg for the reply. > > > > In this case, should the draft just state that the Session-Sender can > select destination UDP port number following the guidelines specified in > [RFC6335], instead of specifying following? > > > > Section 4.4 > > Thus STAMP Session-Sender MUST be able to send test > > packets to destination UDP port number from the Dynamic and/or > > Private Ports range 49152-65535, test management system should find > a > > port number that both devices can use. > > ---------------------------------------------- > > > > Thanks, > > Rakesh > > > > > > On Fri, Aug 2, 2019 at 1:00 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Rakesh, > > thank you for your helpful comments. We've updated the format of the base > STAMP test packet. Appreciate your feedback on the proposed changes, > comments and questions, > > > > Regards, > > Greg > > > > On Tue, Jul 9, 2019 at 9:27 AM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > > Hi Greg, > > Regarding the size of the padding, yes, it's good to use the same size > payload for query and response. > > However, the STAMP payload with TLV extension > (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size > (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it > mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 > for all 30 bytes. If the responder supports Server Octets and see the size > > 27, it may find the Server Octet size of 0 confusing? > > > > Thanks, > > Rakesh > > > > > > > > > > > > On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Shahram, > > thank you for the review and questions. Please find my answers below > tagged GIM>>. > > > > Regards, > > Greg > > > > On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <shahram.davari@broadcom.com> > wrote: > > HI Greg > > > > I read your draft and have the following questions: > > > > 1) Does it require any UDP/TCP port number or it reuses the one from > TWAMP? if it reuses from TWAMP then how does the receiver differentiate > between TWAMP and STAMP? > > GIM>> STAMP uses the well-known UDP port number allocated for the > OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination > UDP port number.. STAMP may use destination UDP port number from the > Dynamic and/or Private Ports range 49152-65535. > > 2) What is the benefit of STAMO compared to TWAMP? > > GIM>> The work was driven by several observations, among them: > > - challenges in achieving interoperability among implementations of > TWAMP-Light; > - industry interest in standardizing performance monitoring in IP > broadband access networks (TR-390); > - improve extensibility of IP performance monitoring tool to support > measurements, testing of new metrics and parameters, e.g., consistency of > CoS in the network. > > 3) Why is there so much MBZ byte? > > GIM>> It was agreed to make the symmetrical size of STAMP test packets the > default. RFC 6038 defined it for TWAMP and TR-390 requires it to be > supported by TWAMP-Light implementations. > > > > Thx > > Shahram > > > > On Jul 8, 2019, at 10:17 AM, Greg Mirsky <gregimirsky@gmail.com> wrote: > > > > Hi Mirja, > > thank you for the suggested text. The new paragraph now reads as: > > Load of STAMP test packets offered to a network MUST be carefully > estimated, and the possible impact on the existing services MUST > be thoroughly analyzed before launching the test session. > [RFC8085] section 3.1.5 provides guidance on handling network load > for UDP-based protocol. While the characteristic of test traffic > depends on the test objective, it is highly recommended to stay in > the limits as provided in [RFC8085]. > > > > If it is acceptable, I'd like to upload the updated version of > draft-ieff-ippm-stamp before the cut-off deadline. > > > > Regards, > > Greg > > > > On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <ietf@kuehlewind.net> > wrote: > > Hi Greg, > > See below. > > > On 8. Jul 2019, at 16:54, Greg Mirsky <gregimirsky@gmail.com> wrote: > > > > Hi Mirja, > > thank you for the reference to RFC 8085. I agree that the document is > very much relevant and a reference to RFC 8085 in STAMP is useful. While > reading Section 3.1.3 I came to think that the discussion and guidance in > other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT > and Loss Measurements on Congestion Control. Would adding the reference to > that section in the new text proposed for the Security Considerations > section work? I'll put RFC 8085 as Informational reference as it is BCP. > > NEW TEXT: > > Load of STAMP test packets offered to a network MUST be carefully > > estimated, and the possible impact on the existing services MUST > > be thoroughly analyzed using [RFC8085] and its Section 3.1.5 in > > particular before launching the test session.... > > > Not sure if “using” is the right word but otherwise fine for me. Or you > could have a separate sentence like: > > “RFC8085 section 3.1.5 provides guidance on handling network load for > UDP-based protocol. While the characteristic of test traffic depends on the > test objective, it is highly recommended to say in the limits as provided > in RFC8085.” > > Or something similar… > > BCP is the same maturity level as PS. So it wouldn’t be a downref. > However, I think having this as informational ref is fine. > > Mirja > > > > > > > Regards, > > Greg > > > > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <ietf@kuehlewind.net> > wrote: > > Hi Greg, > > > > Thanks a lot for you reply. Changes are good. I wonder if it would be > useful to provide a reference to RFC8085 because it has a lot of > information about congestion control of UDP based traffic? It recommends to > send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it > doesn’t make sense to require this for testing traffic, however, it could > maybe still be a good recommendation? What do you think? > > > > Also I’ve just resend my review to the IPPM list, as I unfortunately > cc’ed only the IPPM chairs instead of the whole list. Can you resend you > proposed changes to the list, so other people are aware of these changes. > Sorry for the unconvience. > > > > Mirja > > > > > > > On 6. Jul 2019, at 17:46, Greg Mirsky <gregimirsky@gmail.com> wrote: > > > > > > Hi Mirja, > > > thank you for your thorough review, very pointed and helpful comments. > Please find my responses in-lined and tagged GIM>>. Attached the diff. > > > > > > Regards, > > > Greg > > > > > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <ietf@kuehlewind.net> > wrote: > > > Hi authors, hi all, > > > > > > Thanks for this well-written document and very good shepherd write-up! > I would like discuss one point before I start IETF last call. > > > > > > I believe this document should say something about network load and > congestion (control). OWAMP and TWAMP discuss quite a bit sender > scheduling, however, as this is a simplified version, so I think it could > at least be good to put a waring in this document that packet sending > should be somehow rate limited. I know it might be hard to provide more > concrete guidance but at least having some discussion or warning in this > document could be good. > > > GIM>> Thank you for your suggestion. Security Considerations section > points to the fact that STAMP does not include control and management > components: > > > Because of the control > > > and management of a STAMP test being outside the scope of this > > > specification only the more general requirement is set: > > > adding the new text here: > > > Load of STAMP test packets offered to a network MUST be carefully > > > estimated, and the possible impact on the existing services MUST > > > be thoroughly analyzed before launching the test session. > > > > > > > > > Another comment: You only say at the very end that a certain UDP port > is used, which implies that STAMP runs over UDP. However, I think you > should mention at the very beginning that this is a UDP-based protocol. > Just to make things crystal clear. > > > GIM>> Adding the reference to "UDP transport" into the first sentence > of Theory of Operations section: > > > STAMP Session-Sender transmits test packets over UDP transport > toward STAMP Session-Reflector. > > > > > > Mirja > > > > > > P.S.: > > > Nit: s/This document defines active performance measurement test > protocol/ This document defines an active performance measurement test > protocol/ > > > -> “an” missing > > > GIM>> Thank you. Done. > > > <Diff_ draft-ietf-ippm-stamp-06.txt - > draft-ietf-ippm-stamp-07....txt.html> > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=> > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=> > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > [image: https://i.xink.io/Images/Get/N63832/a65.png] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=> > [image: https://i.xink.io/Images/Get/N63832/f97.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> > [image: https://i.xink.io/Images/Get/N63832/t99.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=> > [image: https://i.xink.io/Images/Get/N63832/l54.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=> > [image: https://i.xink.io/Images/Get/N63832/l.jpg] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=> > *accedian.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>* > > > > Avis de confidentialité > > Les informations contenues dans le présent message et dans toute pièce qui > lui est jointe sont confidentielles et peuvent être protégées par le secret > professionnel. Ces informations sont à l’usage exclusif de son ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s’il vous > plait communiquer immédiatement avec l’expéditeur et en détruire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusive > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank you. > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > [image: https://i.xink.io/Images/Get/N63832/a65.png] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=> > [image: https://i.xink.io/Images/Get/N63832/f97.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> > [image: https://i.xink.io/Images/Get/N63832/t99.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=> > [image: https://i.xink.io/Images/Get/N63832/l54.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=> > [image: https://i.xink.io/Images/Get/N63832/l.jpg] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=> > *accedian.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>* > > > > Avis de confidentialité > > Les informations contenues dans le présent message et dans toute pièce qui > lui est jointe sont confidentielles et peuvent être protégées par le secret > professionnel. Ces informations sont à l’usage exclusif de son ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s’il vous > plait communiquer immédiatement avec l’expéditeur et en détruire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusive > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank you. > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > [image: https://i.xink.io/Images/Get/N63832/a65.png] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=> > [image: https://i.xink.io/Images/Get/N63832/f97.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=0ltpwFIjvuZ8sVhjuD2RN1tIgObw07RIgL_4j3vK9Zc&e=> > [image: https://i.xink.io/Images/Get/N63832/t99.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=QTHdaq6bXMydVVJSnS8pfuhqEnLCWzO0tP9A-gyMWBA&e=> > [image: https://i.xink.io/Images/Get/N63832/l54.png] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=V_ehVarzjW8vvOqJeyq61146LyKQ_Rgz1fNJzJw1waI&e=> > [image: https://i.xink.io/Images/Get/N63832/l.jpg] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=9V6-ggZb009wP2eti0vCu9OWNz1EgxcbDPqe0xCailk&e=> > *accedian.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>* > > > > Avis de confidentialité > > Les informations contenues dans le présent message et dans toute pièce qui > lui est jointe sont confidentielles et peuvent être protégées par le secret > professionnel. Ces informations sont à l’usage exclusif de son ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s’il vous > plait communiquer immédiatement avec l’expéditeur et en détruire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusive > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank you. >
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Mirja Kuehlewind
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Mirja Kuehlewind
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Reshad Rahman (rrahman)
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Civil, Ruth
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Civil, Ruth
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Mirja Kuehlewind
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Henrik Nydell
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi