Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Sat, 10 November 2018 05:15 UTC
Return-Path: <ietf@kuehlewind.net>
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 423D2131094; Fri, 9 Nov 2018 21:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham 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 QFcOmcwKl1CF; Fri, 9 Nov 2018 21:15:14 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1AF1C131091; Fri, 9 Nov 2018 21:15:14 -0800 (PST)
Received: from vpn-global-dhcp3-221.ethz.ch ([129.132.210.221]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gLLbz-0002g2-QD; Sat, 10 Nov 2018 06:15:12 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557DE0DC@njmtexg5.research.att.com>
Date: Sat, 10 Nov 2018 12:15:08 +0700
Cc: "draft-ietf-ippm-port-twamp-test.all@ietf.org" <draft-ietf-ippm-port-twamp-test.all@ietf.org>, "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "ippm@ietf.org" <ippm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A972B43E-5423-4210-B494-FF1D2132A9B6@kuehlewind.net>
References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE0DC@njmtexg5.research.att.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1541826914;bb82f5a5;
X-HE-SMSGID: 1gLLbz-0002g2-QD
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/UWLIhCYP34wMryedodm3bVdgpsU>
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: Sat, 10 Nov 2018 05:15:17 -0000
Okay, I’ll check! > Am 10.11.2018 um 12:12 schrieb MORTON, ALFRED C (AL) <acm@research.att.com>: > > Mirja wrote: > It’s called Downref registry and it's here: > https://datatracker.ietf.org/doc/downref/ > > My understanding is that it will go there automatically > if once referenced as a downref but I can double-check > during the publication process. > > I believe we need to make a specific request for inclusion > of RFC7594 (because I think we've already been down the > "Downref road" for 7594, at least LMAP has). This will > come-up repeatedly, and it's worth any extra steps IMO. > > thanks Mirja! > Al > >> -----Original Message----- >> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >> Sent: Friday, November 9, 2018 11:59 PM >> To: MORTON, ALFRED C (AL) <acm@research.att.com> >> Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org; >> spencerdawkins.ietf@gmail.com; ippm@ietf.org >> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >> >> Hi Al, >> >> see inline. >> >>> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) >> <acm@research.att.com>: >>> >>> Hi Mirja, and Spencer, >>> >>> replies below, with a question for the "Outgoing AD" >>> Al >>> >>>> -----Original Message----- >>>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >>>> Sent: Friday, November 9, 2018 9:22 PM >>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>> Cc: ippm@ietf.org >>>> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>> >>>> Hi all, >>>> >>>> sorry one more question: RFC7594 would be a downref and I think it is >>>> correct that this is a normative reference because it pointed to in the >>>> security sec. On the other it seems a bit weird to point normatively to >>>> the security section of an informational doc. So just double-checking >> if >>>> that is all right (given downrefs need to be called out in the last >> call, >>>> so we have to decide before I start last call)? >>> [acm] >>> >>> Yes, I'd like to keep the Downref, and also ask to place RFC 7594 >>> on the "permanent Downref exception list". I don't know the exact >>> name of this list, but the IPPM Framework RFC 2330 was placed on it. >>> >>> @Spencer: "Outgoing AD" may be able to help us find the list above, >>> before you go please. :-) >> >> It’s called Downref registry and it's here: >> >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_downref_&d=DwIFaQ&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=- >> 2gjXWN8GSCH2I3PCN4fQ5jyDn_86Nn1_deP7q0CqEg&s=cZzpWhZWLQvFArAhIg4- >> xhQhpyQnELhBfagtUfaTjTU&e= >> >> My understanding is that it will go there automatically if once referenced >> as a downref but I can double-check during the publication process. >> >>> >>>> >>>> Also looking at the references again, I think RFC6335 does not need to >> be >>>> a normative reference. >>> [acm] >>> If our colleagues in IANA are ok with that, so am I. >> >> Okay. Actually we can do this later and don’t have to do it before last >> call, which I will respectively start now. >> >> Thanks! >> Mirja >> >> >>> >>>> >>>> @Tianran: a downref is a normative reference to a document with a lower >>>> maturity level, so also a normative reference from a draft that is >>>> intended for Proposed Standard to an informational RFC is a downref. In >>>> the shepherd write-up you only say that there are normative reference >> to >>>> RFCs, however, you would next time also need to check the status of >> these >>>> RFCs. Thanks! Btw. could you please update the shepherd write-up? >>> [acm] >>> +1, thanks Tianran. >>> >>>> >>>> Mirja >>>> >>>> >>>>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) >>>> <acm@research.att.com>: >>>>> >>>>> 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= >>> >
- [ippm] AD review of draft-ietf-ippm-port-twamp-te… Mirja Kuehlewind (IETF)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Spencer Dawkins at IETF
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Mirja Kuehlewind (IETF)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Mirja Kuehlewind (IETF)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Mirja Kuehlewind (IETF)
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Spencer Dawkins at IETF
- Re: [ippm] AD review of draft-ietf-ippm-port-twam… Mirja Kuehlewind (IETF)