Re: [ippm] AD review of draft-ietf-ippm-stamp

Henrik Nydell <hnydell@accedian.com> Tue, 06 August 2019 15:19 UTC

Return-Path: <hnydell@accedian.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 57AB61200B9 for <ippm@ietfa.amsl.com>; Tue, 6 Aug 2019 08:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=accedian-com.20150623.gappssmtp.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 OlABm7e1tvnA for <ippm@ietfa.amsl.com>; Tue, 6 Aug 2019 08:19:37 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 F0A3312021F for <ippm@ietf.org>; Tue, 6 Aug 2019 08:19:36 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id m8so58622598vsj.0 for <ippm@ietf.org>; Tue, 06 Aug 2019 08:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KXDh0/NxCBPFHEOfQQKJiuFGiFi5hhTv67ErbRiVz1g=; b=JnvtBC69o/1ZBx1e2OP9XXP6x33DmLP4zW46sKl46OJyAtaAWlxTayHVn5Ou7UWyzt 70d9Lw2+RQ+NFJDO3EUqLhkiu27JkdmE4ZM6THnAYjswa4SSlKfrraXLLSis8qdMV0ak 8tquqB9xQe51ZrZf1rUMLoc1kg5tLLIP2t6JvVo9nbSwNWks07OmM59EZvEbZqjczKKP gliZKYbB+e8AJyviWfOnnv9au914tmb2PeRaoc4y5rQl07PhQZA04p8nfdbgEuf7LOBd O8af4JETm8wVFAb/nKHdsvID4eJspAKLIjIJc0TM7Z8pOtCPJvjS3bg1MmOso0IA8BMo Kv6A==
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=KXDh0/NxCBPFHEOfQQKJiuFGiFi5hhTv67ErbRiVz1g=; b=B+4khXcYUpbQs+WunY770YGDSyLU/dq97D/p3+M6yy+Mrgb0ZA3nlII5oIM/mOE8kA zjELd/0CaPKoXHDfm2ACkKc5dS2RECMmLp+Cr7qWrKDQxvV8DkVTZ1rY+SEQ5TQo4UUy 11qfW0mnuPX0KLWPkPXXuYYY9F9CTUe7m6GdNn+ciRBxIY0RwqarXA88KHohcN5jEKJA bVMr+y5KJ+KnWth/0ydFB4dc9MRCjjwdXhv3ZMVzBK5OhCfoxP1tT263n9FqKVO6eX9I 8wOdyBz4LFBf/fFOWgqHYhqHBiWYmp086CtiLq8IRr9qzDemxcMtV+7k6JNQRG+LzKdo p/eg==
X-Gm-Message-State: APjAAAWWHny6adNNVO24zrtJxozozQoiAxZtEy8IktcSy4vxGgjRQczI IjuBv2qSc1PDeQrnDpl5sl6ldKRVWrGA2XcYfWA3B8MmWA5I0hyOOvMHytnGhxcZdRO6qeXPgpB llZcsRtsDpQ==
X-Google-Smtp-Source: APXvYqzCKO/KL8/IuCeJUJK2e/NLTYVOlwk5icCbLGfxs7rB8JAvbSYcTRBm2BizIcwe0CO1NkJVIxuniD8WR90uQ04=
X-Received: by 2002:a67:eb93:: with SMTP id e19mr2784328vso.208.1565104775713; Tue, 06 Aug 2019 08:19:35 -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>
In-Reply-To: <CAMZsk6dGneYXFr3Xk_DuQnbwa=-ObV_SNdGOSj1Z203wW-PzTg@mail.gmail.com>
From: Henrik Nydell <hnydell@accedian.com>
Date: Tue, 6 Aug 2019 17:19:25 +0200
Message-ID: <CALhTbppn9jpCLaSLR3QSN=yA0uDyXXMCQ+Rm4qFrR5OrjS31Dw@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.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="000000000000316eb5058f745a43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/6Afnt99DmlGLaVrTMUtwDOt19pM>
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:19:41 -0000

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.