Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sun, 04 November 2018 21:58 UTC

Return-Path: <acm@research.att.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 61956128CB7; Sun, 4 Nov 2018 13:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 s_JeLYQ5a6a8; Sun, 4 Nov 2018 13:58:34 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 3591212872C; Sun, 4 Nov 2018 13:58:34 -0800 (PST)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wA4LtKUH042780; Sun, 4 Nov 2018 16:58:33 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049462.ppops.net-00191d01. with ESMTP id 2nj1552h01-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Nov 2018 16:58:32 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwVdS046086; Sun, 4 Nov 2018 15:58:32 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwOcL045957; Sun, 4 Nov 2018 15:58:25 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id A0A0D40004A2; Sun, 4 Nov 2018 21:58:24 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id 827EC4000491; Sun, 4 Nov 2018 21:58:24 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwOwt012416; Sun, 4 Nov 2018 15:58:24 -0600
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwIh3012244; Sun, 4 Nov 2018 15:58:18 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 3A364F1946; Sun, 4 Nov 2018 16:58:18 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Sun, 4 Nov 2018 16:57:30 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, "draft-ietf-ippm-port-twamp-test.all@ietf.org" <draft-ietf-ippm-port-twamp-test.all@ietf.org>
CC: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] AD review of draft-ietf-ippm-port-twamp-test
Thread-Index: AQHUb7IS2QGrObPQyUeFS1fWuZHhsKVAJHPw
Date: Sun, 04 Nov 2018 21:57:29 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com>
References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net>
In-Reply-To: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.148.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_16:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040209
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/MAqjWV6jfwYKaY72drkckmxJpOQ>
Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test
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: Sun, 04 Nov 2018 21:58:37 -0000

Hi Mirja,
please see replies in-line.
Al

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
> (IETF)
> Sent: Monday, October 29, 2018 2:06 PM
> To: draft-ietf-ippm-port-twamp-test.all@ietf.org
> Cc: ippm@ietf.org
> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test
> 
> Hi authors,
> 
> first of all sorry for the rather long delay for this short draft. The bad
> news it that I probably have to delay the processing even further as I
> will not be able to join the next telechat on Nov 21 and we have to wait
> for the telechat on Dec 6. The good news is that gives us plenty of time
> for the IETF last call :-)
> 
> I reviewed this document and I don’t think there are any issues that would
> not allow me to start the IETF last cal, but given we have time I would
> like to ask a few questions/comments:
> 
> 1) The document gives plenty of background information and talks about
> impacts, however, it says very little about why it is good to have a fixed
> port, beside this:
> "It may simplify some operations to have a well-
>    known port available for the Test protocols, or for future
>    specifications involving TWAMP-Test to use this port as a default
>    port.“
> Is there any chance to say more than this?
[acm] 
yes, mentioned BBF TR-390 implementations as benefactors. 
> 
> 2) Also, I agree with the shepherd that I don’t think it is necessary to
> detail the history as much as done in section 4, e.g. rather discuss the
> why than the actually comments by Lars and Tim. Also this section is
> called „definition“ but this background information seems to go beyond
> just defining something.
[acm] 
Ok the section is now titled, Definitions and Background,
and most of the details describing comments from Lars and Tim
are moved to an Appendix A.

> 
> Btw. Tianran, it would be nice if you could update your comments in the
> shepherd write-up accordingly if they have been addressed or are obsolete.
> Thanks!
[acm] 
Yes, please consider incorporating some of the details from
my e-mail last August, thanks!

> 
> 3) I don’t think there is any normative language require in this doc. As
> you are „just“ stating what has been normatively defined in other
> documents, it is actually preferred to not re-state normatively.
[acm] 
The Scope says: 
	The scope of this memo is to re-allocate well-known ports for the UDP 
	Test protocols that compose necessary parts of their respective 
	standards track protocols, OWAMP and TWAMP, along with clarifications 
	of the complete protocol composition for the industry.

The controversy about TWAMP composition is partly what brought us here!
We used the term REQUIRED in the Definitions to resolve the small ambiguity
created when OWAMP authors did not use normative language when describing
the protocols that comprise OWAMP, and TWAMP authors followed that choice of
wording (unfortunately).
  
> 
> 4) An update in the registry does not necessary mean an „update“ of the
> RFCs that registered that ports in the first place, especially as rfc4656
> doesn’t even mention the UDP port at all. Of course the use of „update“ is
> very loosely defined and can be used if that is preferred but it is not
> strictly necessary. Or is there another reason to update these RFCs? If
> so, it should be clearly spelled out in the draft.
[acm] 
Ok, drawing on the point from the Scope, and requirement Language above,
the Abstract now ends with:

The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-known port 
assignments, and clarifies the complete OWAMP and TWAMP protocol composition 
for the industry.

> 
> 5) Given that these entries are updates it would be nice to also fill the
> missing information about contact information and assignee in the
> registry. Instruction for IANA would need to be added to the IANA section
> in this case. Assignee should be the IESG and contact the IETF chair. I
> assume the modification date will be filled by IANA respectively.
[acm] 
ok

> 
> Thanks!
> Mirja
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fczRvYcfFcuwftALPl3iddxBqrOCp
> UTLa2qfPshPmRY&s=D-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=