Re: [ippm] AD review of draft-ietf-ippm-stamp
Rakesh Gandhi <rgandhi.ietf@gmail.com> Tue, 06 August 2019 18:07 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 90821120650; Tue, 6 Aug 2019 11:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, T_REMOTE_IMAGE=0.01] 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 u93D5nLFJi5G; Tue, 6 Aug 2019 11:07:02 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 8F8D0120637; Tue, 6 Aug 2019 11:07:01 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id x25so83079773ljh.2; Tue, 06 Aug 2019 11:07:01 -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=nWi/4YeoJpl+ztTo/He1BxA2oryJWZf1W/MmtQnvbJo=; b=Qi5wgOjB39MKjwa9jxMltCj3c/bNuGe53zUm04L6rUIEgec4NiRvCiL2Qga3tsA5gL 8yDMDWg1wQpOIDW8jZfYi5HhFdU23tqXghgha2++sFvbHCtaO0Db6aw/tlFzGqyc5RpA RFpPr4pOYpZNJFG0ext8B+GDxq9l0l+z3Aq/fT1pewpDZ2K7Vzm97KPvwlOCMWrTwjHE BmSbo1h+qf8Lba7N2Sdoiv8wwDPGesTYJxoH1gtV3eCuImtUbdtwsW8tyWyzhhTMSxZ5 M/BP8f67jcEx27udL11B30JZDQWP7WJF6MgvEjikDKv6p0rkfTcy3lOtK7aPl/O0qqmt 6IKQ==
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=nWi/4YeoJpl+ztTo/He1BxA2oryJWZf1W/MmtQnvbJo=; b=mQOEWEmQEV16mG+j4bD7UKTcpTqbjsEb1wWViB72gsqhL9S3vWSS+2GmmboO5BLURU 2dUHLM4vPzQkolkHceQOiB84gwR10Fx6c/+3cRkL1kVi6Pba0YKyj+na0iKk0OL8zYB2 gpajW7Sq617IVghbR2fJxrBLThlCCRNTGnUdtoEas2GVgmDRjxTxRu4xnBtRp9c8sR4W ZybqsKQM9zWJHjSrdfymojOJzOuUyNy1ed5ZVvI3zW1genV+4c5+CADgPkFpAw5k/0Kn Ij34rIKU6Nihz0j3IznaZQ+A19fHKBIG8jyRJcMsO/qepAOOqXQrqGMaTTdMfeAywwEW A/XQ==
X-Gm-Message-State: APjAAAVajMjm42C1l2gv3Vcp244YD6cvUOR/S0q6FlYsbY0rpp3FSEBJ TUgYuBHrD/f7Hh02MdLg2B5Q4F2xbAJpprYFmQ==
X-Google-Smtp-Source: APXvYqza5DwkpDgN0VCbtf16tH+P3xFQpqNx6BLIdvplfPxeo8zpqIx590r0PWZDnzB0e6Qd2Xrf+TPFLBXQCU4oel4=
X-Received: by 2002:a2e:9857:: with SMTP id e23mr2407140ljj.217.1565114819545; Tue, 06 Aug 2019 11:06:59 -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>
In-Reply-To: <CALhTbppn9jpCLaSLR3QSN=yA0uDyXXMCQ+Rm4qFrR5OrjS31Dw@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Tue, 06 Aug 2019 14:06:48 -0400
Message-ID: <CAMZsk6eidFR-doLCvMim6HJZ142q_Q0V7XmiLP6Ki5_jmNvUxw@mail.gmail.com>
To: Henrik Nydell <hnydell@accedian.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, rrahman@cisco.com, 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="000000000000da0f91058f76b029"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/9E39CLrme76a2oi14XmNFK85NsA>
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 18:07:07 -0000
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://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> 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://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> ippm mailing list >>>>>>> ippm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>>>> >>>>>> > > -- > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > <http://accedian.com> > <https://www.facebook.com/accedian/> <https://twitter.com/Accedian> > <https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca> > <http://www.accedian.com> > *accedian.com <http://accedian.com>* > > 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