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

"Civil, Ruth" <gcivil@ciena.com> Thu, 15 August 2019 16:54 UTC

Return-Path: <prvs=71309824c1=gcivil@ciena.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 EFFBF120074; Thu, 15 Aug 2019 09:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=ciena.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 U2q-tVxmpvEi; Thu, 15 Aug 2019 09:54:32 -0700 (PDT)
Received: from mx0a-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9621200CD; Thu, 15 Aug 2019 09:54:31 -0700 (PDT)
Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7FGknu7019874; Thu, 15 Aug 2019 12:54:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=06252019; bh=dFbo8AYGi7QsvPz3fsfw+knkDE8UKwNvIhbEoU8+yVA=; b=rKLM/Ol1jWH0kMikKmUY2PAOCy8+l6rt0QyzsEPSkT9XiYl6Qu8ze1bOBZR8FrCl7IIh qkvxN9Q+t320amL0a4969Z6gfGMv0crmECku84+ZJM4cAh2Me1WZBQLbEXJTsNJWb36g /yTOaqD02dD5BRdsDzhRl0N1yMLkHzdrUiAd3zVH9M2jjiBpw9e8DTWDfz9UAn45sA5l Jn0nNgppsHSNv88E6MWzrHfHvDUF+34SB/5JcJZxeQSmDS5ilkUjPD7M5drqNopHekR/ nEbYPKIThXwWqm1EWOE4Wc8dvFqOy2lhFHTqjoXBZnCmE4mboEGbdX0dlXXDM5MDthKv SA==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2052.outbound.protection.outlook.com [104.47.38.52]) by mx0b-00103a01.pphosted.com with ESMTP id 2ubf8fee08-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 12:54:17 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dLuP2sOeLWQJzjJepA8YabHot7Qg+b6eFqMCDxKvCyIm3fdkeybLxQaCFygUtTVK4x/I+QHNOEqjMp6QimqYOPRT19xjsuZXI+oRe7bNIlRNlkZO4NSUlp1bL3g3a/tlM24hQDLNEc5CaBL0fSxhZ2at3Nv8E4+MidIJo57UR6fc/OeM7RxC6Fs6DGH4NFzdSK6IrxeysK8PNyjLH2TLwkjgnGdEbyCv2W4KCZpzGQvPylXrSmmt3kYUDTBnWrEHvEiyfBl+cezVjfnG/l6oaVjMO5UTODQpabNVVAc0rVi9gex89p8BJV1ZkKvS5jfaDbFikADLfVUmCbEg77dQjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFbo8AYGi7QsvPz3fsfw+knkDE8UKwNvIhbEoU8+yVA=; b=Hnf3pl8zo+yRaoqGkgdglQTy65n3XCBQSL1mA6JSVWD/+TEZryKXuGjB09BbZgytF28VsRXJyd5pfsjSzbgPr1t0NwY41LnMGCHnbkbiouwvOc5BEnyV/yrddSU6qxD86+0w9xRyDuwDwx6cVGGbFvLJfUl3/DOhc4/fklfvvSGJLie9NS+tPaA0vyDcLbq1nuSk0IZwBckalTTaJOUEKHcu7rqTTMqocYPJK9V6HRZSK01yNkRJbO9LrxvAqnAB/OtSeyI4+2eQSAXLcq6qzhaAnY2A//eXWolDJWE9GVSteq8Hy8/aEQInrll2xsiCrbaU1nEQQSAKYPauZlWnrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none
Received: from CH2PR04MB6570.namprd04.prod.outlook.com (10.186.136.210) by CH2PR04MB6840.namprd04.prod.outlook.com (20.180.15.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Thu, 15 Aug 2019 16:54:15 +0000
Received: from CH2PR04MB6570.namprd04.prod.outlook.com ([fe80::82a:a49c:3426:2e68]) by CH2PR04MB6570.namprd04.prod.outlook.com ([fe80::82a:a49c:3426:2e68%3]) with mapi id 15.20.2157.022; Thu, 15 Aug 2019 16:54:15 +0000
From: "Civil, Ruth" <gcivil@ciena.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>, Henrik Nydell <hnydell@accedian.com>
CC: Greg Mirsky <gregimirsky@gmail.com>, "rrahman@cisco.com" <rrahman@cisco.com>, Shahram Davari <shahram.davari@broadcom.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>, "draft-ietf-ippm-twamp-yang@ietf.org" <draft-ietf-ippm-twamp-yang@ietf.org>
Thread-Topic: [**EXTERNAL**] Re: [ippm] AD review of draft-ietf-ippm-stamp
Thread-Index: AQHVTR97Di7Hvy9iy0KjR0ijBI1bHab8eA1g
Date: Thu, 15 Aug 2019 16:54:15 +0000
Message-ID: <CH2PR04MB657072ABD626806915BC94F7CBAC0@CH2PR04MB6570.namprd04.prod.outlook.com>
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> <CAMZsk6e=eDds8fEWgqTs6anYb0m2jciZ7EHBtNtNWp3i6s+0=w@mail.gmail.com>
In-Reply-To: <CAMZsk6e=eDds8fEWgqTs6anYb0m2jciZ7EHBtNtNWp3i6s+0=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [165.225.36.125]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4bac2453-da0a-42dd-6358-08d721a134ce
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7167020)(49563074)(7193020); SRVR:CH2PR04MB6840;
x-ms-traffictypediagnostic: CH2PR04MB6840:
x-microsoft-antispam-prvs: <CH2PR04MB684035B20A15CC5146129AAFCBAC0@CH2PR04MB6840.namprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01304918F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39850400004)(376002)(136003)(366004)(13464003)(189003)(199004)(81166006)(81156014)(8936002)(5660300002)(8676002)(229853002)(86362001)(14454004)(26005)(110136005)(54906003)(99286004)(186003)(55236004)(53546011)(478600001)(6506007)(102836004)(33656002)(45080400002)(7696005)(52536014)(76176011)(11346002)(446003)(486006)(476003)(316002)(7416002)(3846002)(4326008)(25786009)(5024004)(256004)(6436002)(74316002)(6116002)(9686003)(2906002)(66476007)(66616009)(64756008)(66446008)(55016002)(66946007)(66556008)(6246003)(76116006)(53936002)(99936001)(66066001)(305945005)(71190400001)(71200400001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR04MB6840; H:CH2PR04MB6570.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mYvmj9oYJKTB5XkrBs1JUkF30CF7iVeRt1hI2r8UMAWF0bZ6y8epa/Y+xVZ7ZSgBA83Z/KTHAy2/MSWUDi+Cbf76Ymo/HN4L40MnfB1kyZXiGTGCiwvBPaa2//VkbczkfRkqRKfr59xFUg0YUhFi1FSG9qJtv+z9KXhEk22HRmtzufnJ0ePa5VHg++cTnEPFlLvY9rEvJqVpzNgk9IUdLkdhxi4K0/3xFEuurm3JTHcrpleSnYlKwUWS1WAzZUQTPdFlv5n/t/hQBeJOOKWnR/8rTFfL8XJ51onDWnJ5fPQ33Nn/hnE0q8hVewlUHzNBLo/4o6UPvHzcRliKl2UZLftP3CQhi4d5S5ddN3+aSjOxaJyGfK8O4IfIVMH0eRh1piAhw822/FiaGu+0UB/RAzvumo/doe7g+12E8lNAit4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_CH2PR04MB657072ABD626806915BC94F7CBAC0CH2PR04MB6570namp_"
MIME-Version: 1.0
X-OriginatorOrg: ciena.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bac2453-da0a-42dd-6358-08d721a134ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2019 16:54:15.4035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wgVtSYFliXFylQOC5L/xjBmtB+LXW7C0wuXy/lvf2oGITHW8t73ZtuRi2IPb9rXvL3BxjkTBWdea+JiSLEZejg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR04MB6840
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-15_06:2019-08-14,2019-08-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 clxscore=1011 adultscore=0 spamscore=0 mlxscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908150164
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/4S-LJOsF7W1bBaOZH-hYy-nMXCg>
X-Mailman-Approved-At: Thu, 15 Aug 2019 09:59:12 -0700
Subject: Re: [ippm] [**EXTERNAL**] Re: 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, 15 Aug 2019 16:54:36 -0000

We did have a long discussion about allowing UDP ports outside of the dynamic range in the TWAMP Yang model (see the attached outlook thread).

I'm not sure of the repercussions of allowing TWAMP test traffic with UDP port numbers that are assigned to other protocols. 
For example,  if we started sending TWAMP test packets with a destination UDP port of 123 (NTP) to an IP address on a remote device.  How would an NTP application running on that device know that these are not NTP packets - and therefore that it should not intercept them and attempt to process them as such?

Cheers,
	Ruth


-----Original Message-----
From: Rakesh Gandhi <rgandhi.ietf@gmail.com> 
Sent: Wednesday, August 07, 2019 8:56 AM
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>; draft-ietf-ippm-twamp-yang@ietf.org
Subject: [**EXTERNAL**] Re: [ippm] AD review of draft-ietf-ippm-stamp

Thanks Henrik.
Adding the authors of the TWAMP Yang model to see if they have any thoughts on the UDP port range. It is still not an RFC, so may be this comment can be addressed if needed.
Thanks,
Rakesh


On Wed, Aug 7, 2019 at 4:30 AM Henrik Nydell <hnydell@accedian.com> wrote:

> 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.
>
> 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
--- Begin Message ---
How about this?

The base model as we publish in the draft talks only about the dynamic range.

An example in appendix shows how one could deviate the model and add in the well-known ports.

Mahesh Jethanandani
mjethanandani@gmail.com

> On Jun 29, 2016, at 6:49 AM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
> 
> Apologies for not being clear, what I forgot to add is “I don’t know how
> to do that”.
> 
> 
> 
> 
>> On 2016-06-29, 9:19 AM, "MORTON, ALFRED C (AL)" <acmorton@att.com> wrote:
>> 
>> That works for me, thanks for the suggestion.
>> Al
>> 
>>> -----Original Message-----
>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
>>> Sent: Wednesday, June 29, 2016 8:22 AM
>>> To: MORTON, ALFRED C (AL); Mahesh Jethanandani
>>> Cc: Kostas Pentikousis; Civil, Ruth
>>> Subject: Re: Telco Minutes 2016-06-28
>>> 
>>> I think what Mahesh is saying is that the question is how do we model a
>>> dynamic range in the standard model and allow for less restrictions in
>>> other implementations. Optional features usually relate to new
>>> leaf/container nodes. Here we¹d have a port which is 49152..65535 in the
>>> base model and we want to allow an ³augment² which would be less
>>> restrictive say 1Š 65535.
>>> 
>>> 
>>> 
>>> 
>>> On 2016-06-28, 10:37 PM, "MORTON, ALFRED C (AL)" <acmorton@att.com>
>>> wrote:
>>> 
>>>> I suppose the well-known and registered ranges are an if-feature,
>>>> as we discussed on the call for something else today.
>>>> 
>>>> The model has to have some way to deal with mandatory and optional
>>>> features, right?
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
>>>>> Sent: Tuesday, June 28, 2016 10:30 PM
>>>>> To: MORTON, ALFRED C (AL)
>>>>> Cc: Kostas Pentikousis; Reshad Rahman; Civil, Ruth
>>>>> Subject: Re: Telco Minutes 2016-06-28
>>>>> 
>>>>> The question would still be how do we model it. We either remove the
>>>>> range and allow all ports or we force implementations to deviate.
>>>>> 
>>>>> Mahesh Jethanandani
>>>>> mjethanandani@gmail.com
>>>>> 
>>>>>> On Jun 28, 2016, at 7:25 PM, MORTON, ALFRED C (AL)
>>> <acmorton@att.com>
>>>>> wrote:
>>>>>> 
>>>>>> Hi Mahesh,
>>>>>> 
>>>>>> I think Brian's point was that we want to allow a wider
>>>>>> range of ports for specialized testing, and still guide
>>>>>> the user to normal == dynamic port range for typical tests.
>>>>>> So, Dynamic range is mandatory, other ranges are optional.
>>>>>> 
>>>>>> There would be no requirement to support the exhaustive
>>>>>> range of ports, but extra points for providing that support.
>>>>>> 
>>>>>> Al
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
>>>>>>> Sent: Tuesday, June 28, 2016 8:03 PM
>>>>>>> To: MORTON, ALFRED C (AL)
>>>>>>> Cc: Kostas Pentikousis; Reshad Rahman; Civil, Ruth
>>>>>>> Subject: Re: Telco Minutes 2016-06-28
>>>>>>> 
>>>>>>> Al,
>>>>>>> 
>>>>>>> The current definition of the dynamic-port-numbers restricts the
>>> port
>>>>>>> numbers to the range 49152 .. 65535. The current set of sender-
>>> udp-
>>>>> port
>>>>>>> and reflector-udp-port use the definition of dynamic-port-range
>>>>>>> effectively restricting the ports to that range. If we have to
>>>>> support
>>>>>>> ³well known² ports, we would have to drop the type definition,
>>>>> allowing
>>>>>>> users to use any port. Is that a desirable behavior? Can we let
>>>>>>> individual implementations deviate if they want to provide that
>>>>> support?
>>>>>>> 
>>>>>>> I thought the standard restricted the port range to the dynamic
>>> port
>>>>>>> range...
>>>>>>> 
>>>>>>>>> On Jun 28, 2016, at 1:22 PM, MORTON, ALFRED C (AL)
>>>>> <acmorton@att.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi TWAMP YANG-o-philes,
>>>>>>>> 
>>>>>>>> On:
>>>>>>>> AP2: Al to check A/V recording in order to see if something needs
>>> to
>>>>>>>> be done in -01 to address Brian's comment about "application
>>> level
>>>>>>>> changes". Due 1 July 2016
>>>>>>>> 
>>>>>>>> What Brian was asking about was TWAMP's ability to perform port-
>>>>>>> specific
>>>>>>>> tests, assuming the network IS reactive to the UDP port in use
>>> and
>>>>>>>> configuring the Reflector to receive traffic on a specific UDP
>>> port.
>>>>>>>> The example Brian gave was TWAMP testing to see if QUIC would
>>> work
>>>>>>>> on UDP port 80.  This is outside the dynamic range for typical
>>> TWAMP
>>>>>>>> use. See https://en.wikipedia.org/wiki/QUIC
>>>>>>>> 
>>>>>>>> If we want to support testing of well-known ports or registered
>>>>> ports
>>>>>>>> *as an option*, beyond the typical use, we would have to say so
>>> in
>>>>> the
>>>>>>>> paragraph below:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> sender-udp-port
>>>>>>>>         The UDP port number that is to be used by the Session-
>>>>> Sender
>>>>>>>>         for this TWAMP-Test session.  The number is restricted
>>> to
>>>>>>> the
>>>>>>>>         dynamic port range (49152 .. 65535).  A value of zero
>>>>>>>>         indicates that the Control-Client SHALL auto-allocate a
>>> UDP
>>>>>>>>         port number for this TWAMP-Test session.  The configured
>>>>> (or
>>>>>>>>         auto-allocated) value is advertized in the Sender Port
>>>>> field
>>>>>>>>         of the Request-TW-session message (see also Section 3.5
>>> of
>>>>>>>>         [RFC5357]).  Note that in the scenario where a device
>>> auto-
>>>>>>>>         allocates a UDP port number for a session, and the
>>> repeat
>>>>>>>>         parameter for that session indicates that it should be
>>>>>>>>         repeated, the device is free to auto-allocate a
>>> different
>>>>>>> UDP
>>>>>>>>         port number when it negotiates the next (repeated)
>>>>> iteration
>>>>>>>>         of this session.
>>>>>>>> 
>>>>>>>> Perhaps:
>>>>>>>> ... .           The number is normally restricted to the
>>>>>>>>         dynamic port range (49152 .. 65535). For specialized
>>>>> testing
>>>>>>>>         of well-known ports or registered ports, these port
>>> number
>>>>>>> ranges
>>>>>>>>         MUST also be made available.
>>>>>>>> 
>>>>>>>> see:
>>>>>>>> https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>>>>>>>> 
>>>>>>>> Similar changes are required here (and in the Session Reflector
>>>>>>> section,
>>>>>>>> just search on "dynamic") :
>>>>>>>> 
>>>>>>>> reflector-udp-port
>>>>>>>>         This parameter defines the UDP port number that will be
>>>>> used
>>>>>>>>         by the Session-Reflector for this TWAMP-Test session.
>>> The
>>>>>>>>         number is restricted to the dynamic port range (49152 ..
>>>>>>>>         65535).  This value will be placed in the Receiver Port
>>>>>>> field
>>>>>>>>         of the Request-TW-Session message.  If this value is not
>>>>>>> set,
>>>>>>>>         the device SHALL use the same port number as defined in
>>> the
>>>>>>>>         server-tcp-port parameter of this twamp-session-
>>> request's
>>>>>>>>         parent twamp-client-ctrl-connection.
>>>>>>>> 
>>>>>>>> And we need to repeat these typedefs for well-known and
>>> registered:
>>>>>>>> 
>>>>>>>> typedef dynamic-port-number {
>>>>>>>> type inet:port-number {
>>>>>>>>  range "49152 .. 65535";
>>>>>>>> }
>>>>>>>> description "Dynamic range for port numbers";
>>>>>>>> 
>>>>>>>> And, these leafs need to reflect the choice of range:
>>>>>>>> 
>>>>>>>>        leaf sender-udp-port {
>>>>>>>>        type dynamic-port-number;
>>>>>>>>        description "Sender UDP port.";
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Kostas Pentikousis [mailto:k.pentikousis@travelping.com]
>>>>>>>>> Sent: Tuesday, June 28, 2016 1:48 PM
>>>>>>>>> To: 'Mahesh Jethanandani'; MORTON, ALFRED C (AL); 'Reshad
>>> Rahman';
>>>>>>>>> 'Civil, Ruth'
>>>>>>>>> Subject: [draft-ietf-ippm-twamp-yang] Telco Minutes 2016-06-28
>>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Please find below my rough notes and APs from the telco today.
>>>>> Please
>>>>>>>>> correct/amend as needed, I may have missed something.
>>>>>>>>> 
>>>>>>>>> 1. IETF 95 IPPM Proceedings comments:
>>>>>>>>> https://www.ietf.org/proceedings/95/minutes/minutes-95-ippm):
>>>>>>>>> Greg Mirsky - Document the port ranges.
>>>>>>>>> Brian T - What about Application level changes.
>>>>>>>>> Fred Baker asked about an IPv6 example in the document.
>>>>>>>>> Al Morton - Need to add there
>>>>>>>>> 
>>>>>>>>> We agreed to add an IPv6 example and check if anything is
>>> required
>>>>> to
>>>>>>>>> address Brian's comment.
>>>>>>>>> 
>>>>>>>>> 2. YANG Doctor's (Jan Lindblad <janl@tail-f.com>) Review:
>>>>>>>>> 
>>>>>>>>> Based on the comments (and YANG's pov about formal
>>> specification),
>>>>> we
>>>>>>>>> discussed where should parameter descriptions appear and
>>> concluded
>>>>>>>>> that we should as a first step we will move the parameter
>>>>>>> descriptions
>>>>>>>>> from section 4 to section 5. Naming will also be simplified
>>> (first
>>>>>>>>> proposal attached). We will subsequently update the UML diagrams
>>>>> and
>>>>>>>>> adjust text accordingly.
>>>>>>>>> 
>>>>>>>>> Regarding the comment about scope/value given lack of
>>> operational
>>>>>>>>> commands and a way to collect results we agreed to move the 1st
>>>>> para
>>>>>>>>> from Appendix B into Scope. An Author's reply to Jan could point
>>> to
>>>>>>>>> LMAP etc. at this point.
>>>>>>>>> 
>>>>>>>>> We have no solution for the following comment: "Alternatively,
>>> it
>>>>>>>>> might be more convenient for operators if this was modeled as a
>>>>> small
>>>>>>>>> power of two value with the range 10..31." (context: leaf max-
>>> count
>>>>>>>>> range).
>>>>>>>>> 
>>>>>>>>> There's a bit of inconsistency about SHALL/MAY/SHOULD in the
>>> text
>>>>> and
>>>>>>>>> its representation in YANG. Example comment from Jan:
>>>>>>>>> 
>>>>>>>>>> Section 4.1 and section 4.2 describes the max-count leaf like
>>>>> this:
>>>>>>>>>> max-count
>>>>>>>>>>        If an attacking system sets the maximum value in Count
>>>>>>>>>>        (2**32), then the system under attack would stall for a
>>>>>>>>>>        significant period of time while it attempts to
>>> generate
>>>>>>>>>>        keys.  Therefore, TWAMP-compliant systems SHOULD have a
>>>>>>>>>>        configuration control to limit the maximum Count value.
>>>>>>>>> The
>>>>>>>>>>        default max-count value SHOULD be 32768.
>>>>>>>>>> 
>>>>>>>>>> Since the YANG module specifies a configurable max-count with a
>>>>>>>>> default of 32768, there is no longer any SHOULD about this, it's
>>>>> now
>>>>>>>>> MUST. Also the description seems to be cut out of its context
>>> and
>>>>>>>>> pasted here. There was no reference to attacking systems before
>>>>> this,
>>>>>>>>> so maybe a line of introduction would be in order.
>>>>>>>>>> 
>>>>>>>>>> Section 4.4 has similar wording
>>>>>>>>>>        The default value of
>>>>>>>>>>        REFWAIT SHALL be 900 seconds, and this waiting time MAY
>>> be
>>>>>>>>>>        configurable.
>>>>>>>>>> 
>>>>>>>>>> The YANG module specifies a leaf refwait that makes this
>>>>>>>>> configurable. There is no MAY about it. If we would want to keep
>>>>> the
>>>>>>>>> MAY in this statement, the leaf would have to be flagged with an
>>>>>>>>> if-feature.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *Action Points*
>>>>>>>>> 
>>>>>>>>> AP1: Reshad to address Fred's comment and add IPv6 example. Due
>>> 4
>>>>>>> July
>>>>>>>>> 2016.
>>>>>>>>> 
>>>>>>>>> AP2: Al to check A/V recording in order to see if something
>>> needs
>>>>> to
>>>>>>>>> be done in -01 to address Brian's comment about "application
>>> level
>>>>>>>>> changes". Due 1
>>>>>>>>> July 2016
>>>>>>>>> 
>>>>>>>>> AP3: Kostas to move descriptions from section 4 into the YANG
>>>>> module
>>>>>>>>> (and then back into section 5), adjust section 4. Due 5 July
>>> 2016
>>>>>>>>> 
>>>>>>>>> AP4: Kostas to edit Scope and incorporate para from Appendix B
>>> re:
>>>>>>>>> results collection. Due 5 July 2016
>>>>>>>>> 
>>>>>>>>> AP5: Mahesh will get in touch with Jan for an elegant YANG
>>> solution
>>>>>>> to
>>>>>>>>> describe ranges as power of two. Due 5 July 2016.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *Next Telco*
>>>>>>>>> 
>>>>>>>>> 7 July 2016, 5 pm CEST/11 am ET/8 am PT. Kostas will send a
>>>>> blocker,
>>>>>>>>> Mahesh/Reshad to arrange bridge.
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> 
>>>>>>>>> Kostas
>>>>>>> 
>>>>>>> Mahesh Jethanandani
>>>>>>> mjethanandani@gmail.com
> 
--- End Message ---