Re: [ippm] AD review of draft-ietf-ippm-stamp
Rakesh Gandhi <rgandhi.ietf@gmail.com> Tue, 06 August 2019 15:06 UTC
Return-Path: <rgandhi.ietf@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 BBB591201D5; Tue, 6 Aug 2019 08:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 7mxlyioYkS07; Tue, 6 Aug 2019 08:06:18 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 C02AA12018A; Tue, 6 Aug 2019 08:06:17 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id b17so61441477lff.7; Tue, 06 Aug 2019 08:06:17 -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=pkUgDAiA8xjsF1GX5YT7nH7k5cD/PnlYJuYQIJhwAtU=; b=Z2CzUYdACBDVB+3yg8FjIXiDWmkq+D6IOiQoYQicWCFEUjLTx+eaAL4GHcDDAj/XxN rC/hL3nlo1o8m3rG7VOsXVbg7rlpB4v9WwSU4w4ZvVf1KNnLoJjQ5rnI/hmd87Wsz2v2 npkY0CfbvG8af94N5o9NfDxmOx+0S/nxCXq43CdzYfgsNY5ypLHLtbAMtYKhAIgwkTNO 9qmdgNRQ1znl11i4JwU2BXpKtGe3DoPq8jTbO3PNExV0Lw1HUCWEPnVhuCAv1wEX/XRD avA4dCjzJD/ZHaVk52smsfYiHhIqlMfSKvLYn8ALM5dXx6r7rkudVn/KQOm5/A7G9EeI ZMZQ==
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=pkUgDAiA8xjsF1GX5YT7nH7k5cD/PnlYJuYQIJhwAtU=; b=j2Z3nBQ4ISngkczfHn8WghaqMPL1Lloq2F6pYQRXcA7V3eQrfe6HT1eOP8eT+lbEVU CtlRCy0LGxuawd81F8I/okQr5Yd2dOe2n2T+iF4xE/5IcgiRHPyBU+QNipUmLpL6mT5n Q/YoJoxiTwV3+0xe+QZqQi3OWCHJ1qyspcb1TD7RK+LOWtBfBSBXvfUx0Nkg+nA/ruE2 0csEVsP94OVUl+eJn+J7Z9rqLMR+aWoyx8dKppH1gsEuIVch0DYM/ja3pN7iaUL5Gj6D oPG59TPt1zt/1s1LX9GfWVR++/OLV0z8S6Mp0k85NM9Wq3rEPcXdblA8jqvTr5UadN1Q e7Cg==
X-Gm-Message-State: APjAAAUlFKB7i/JFw3S2U4VrzyhoLxCoTXyi2K74ojv7X/nLQ0qs9Xr1 mtzQDf2zWAPtbyapqe5vN5INdBLvNbYXZsE4Sg==
X-Google-Smtp-Source: APXvYqxeD9HdrS8iiloWxf3aTlIhmB6lssbKboiI4d8L9smFQvY5yP6X32uTxG/A3BjjqXGPZ2NrsHMMOKeQrDSjPYo=
X-Received: by 2002:ac2:4157:: with SMTP id c23mr2702680lfi.173.1565103975808; Tue, 06 Aug 2019 08:06:15 -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> <CAMZsk6e-bcFNz327p_u6KEHV2qnJUytPwPmJVgXxEWbzsQr9OA@mail.gmail.com> <CA+RyBmW01TgyXPAk3OGhdKqDTszkf0KzT+dDVTdaEhFu7GA7-Q@mail.gmail.com>
In-Reply-To: <CA+RyBmW01TgyXPAk3OGhdKqDTszkf0KzT+dDVTdaEhFu7GA7-Q@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Tue, 06 Aug 2019 11:06:04 -0400
Message-ID: <CAMZsk6eUOTxjWy=r62SNvSLzOe8KGQ8CGgbW-H2uoLgDPmPsTA@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Shahram Davari <shahram.davari@broadcom.com>, 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="00000000000083c283058f742a1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/LH4zH2-lROVCWQ0LtuyCHNJUIlU>
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: Tue, 06 Aug 2019 15:06:22 -0000
Hi Greg, Couple of additional comments on the draft: There are TWAMP extensions for Checksum complement in RFC 7820 and DSCP-ECN in RFC 7750. Good to add some text for STAMP if they can be supported or not supported. I can see they can be supported as following, and should not break anything: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | S-DSCP-ECN | Checksum Complement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Rakesh On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Rakesh, > thank you for your question. In my experience, some implementations of > TWAMP-Light have taken the liberty to allow using UDP port numbers outside > the Dynamic/Private range. I believe that is not the right decision. In the > note of IANA's Service Name and Transport Protocol Port Number Registry we > read: > > Service names and port numbers are used to distinguish between different > services that run over transport protocols such as TCP, UDP, DCCP, and > SCTP. > > Service names are assigned on a first-come, first-served process, as > documented in [RFC6335]. > > Port numbers are assigned in various ways, based on three ranges: System > Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private > Ports (49152-65535); the difference uses of these ranges is described in > [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are > assigned by the "IETF Review" or "IESG Approval" procedures described in > [RFC8126]. User Ports are assigned by IANA using the "IETF Review" > process, > the "IESG Approval" process, or the "Expert Review" process, as per > [RFC6335]. Dynamic Ports are not assigned. > > The registration procedures for service names and port numbers are > described in [RFC6335]. > > Assigned ports both System and User ports SHOULD NOT be used without > or prior to IANA registration. > > My interpretation is that ports in System and User ranges, even if not yet > assigned, must not be used without following the assignment process. Thus, > regardless of whether a number had not yet been assigned to a service, it > must not be used as the destination UDP port number. Also, consider > operational issues if a new service is assigned a new port number from the > User Ports range. One day the number was "free" and tomorrow it may be > assigned. Handling such a scenario will add complexity while benefits are, > in my opinion, questionable. > > Regards, > Greg > > On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> > wrote: > >> Hi Greg, >> >> Why limit the UDP port range to 49152-65535? Any free UDP port can be >> used, no? >> >> 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 >>>> >>>> >>>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>
- 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