Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-registry-22: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Fri, 13 December 2019 00:47 UTC
Return-Path: <kaduk@mit.edu>
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 13DFB120113; Thu, 12 Dec 2019 16:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 arLEAPfQ40z4; Thu, 12 Dec 2019 16:47:27 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C49AF120090; Thu, 12 Dec 2019 16:47:25 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBD0lKFY014680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Dec 2019 19:47:22 -0500
Date: Thu, 12 Dec 2019 16:47:19 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ippm-metric-registry@ietf.org" <draft-ietf-ippm-metric-registry@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ietf@wjcerveny.com" <ietf@wjcerveny.com>, "ippm@ietf.org" <ippm@ietf.org>
Message-ID: <20191213004719.GB81833@kduck.mit.edu>
References: <157553269383.11096.11664366118558898995.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA6F0974B@njmtexg5.research.att.com> <20191212045648.GT13890@kduck.mit.edu> <4D7F4AD313D3FC43A053B309F97543CFA6F0B3CE@njmtexg5.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6F0B3CE@njmtexg5.research.att.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/uUV7tmeXWCBFXGd4y53Q47u62lA>
Subject: Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-registry-22: (with COMMENT)
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: Fri, 13 Dec 2019 00:47:29 -0000
On Thu, Dec 12, 2019 at 11:36:40PM +0000, MORTON, ALFRED C (AL) wrote: > Hi Benjamin, > > I'll trim this message down to focus on the last few points, Thanks; I probably should have done some trimming too. > Al > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: Wednesday, December 11, 2019 11:57 PM > > To: MORTON, ALFRED C (AL) <acm@research.att.com> > > Cc: The IESG <iesg@ietf.org>; draft-ietf-ippm-metric-registry@ietf.org; > > ippm-chairs@ietf.org; ietf@wjcerveny.com; ippm@ietf.org > > Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-ippm-metric- > > registry-22: (with COMMENT) > > > > Hi Al, > > > > Thanks for all the updates. Just a few more notes inline... > > > ... > > > > particular example is the LMAP framework [RFC7594]. Using the > > > > LMAP terminology, the Performance Metrics Registry is used in > > the > > > > LMAP Control protocol to allow a Controller to request a > > > > measurement task to one or more Measurement Agents. In order to > > > > > > > > nit: please check the grammar of "request a measurement task to". > > > [acm] > > > Yes, it matches the LMAP control framework. > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__tools.ietf.org_html_rfc7594&d=DwIBAg&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8- > > 6zYMI&m=MzVZrMUvKmgZUrc2Qyn-SPWdwhnUOKygq- > > TCWAfOpjI&s=o0bDjUeJH_LTfE10Zmgr5u1Gil0KGRd3Yloz5WMbG0A&e= > > > > I'm not sure that it does ... in common English usage (ignoring any 7594 > > jargon), one would "send a request to an agent to perform a measurement > > task" or "request an action of an agent" or "request that an agent perform > > a task" or "task an agent to perform an operation". While I didn't read > > all 50 pages of RFC 7594, some targeted searching fails to find a jargon > > usage where "request a task to an agent" has a specific meaning. > [acm] > ok, probably "schedule a task" would have. I was focusing on the "request" > part. Controllers send tasks to measurement agents and they can be refused. > > Let's try: > LMAP Control protocol to allow a Controller > to schedule a measurement task for one or more Measurement Agents. That does the trick; thanks for working through it with me. > > > > > > > > > > > Section 4.2 > > > > > > > > different (and incompatible) ways. Having a registry would allow > > > > both the IETF community and external people to have a single list > > of > > > > > > > > nit: I suggest rephrasing "external people" as needlessly divisive; > > > > perhaps "other communities"? > > > [acm] > > > Sounds better to me. > > > > > > > > > > > Section 7 > > > > > > > > form of registry extension. The specification defining the new > > > > column(s) MUST give guidelines to populate the new column(s) for > > > > existing entries (in general). > > > > > > > > Is "MUST (in general)" really still a "MUST"? > > > [acm] > > > I think so, we're talking about new columns having a similar > > > level of detail in their description as the columns in the > > > current registry (future version 2.0). > > > > I guess that there's a couple ways one could parse this sentence: "in > > general" could apply to the way the columns are populated, or to what the > > specification defining the new columns has to do. I was reading it in the > > second variant, and qualifying a MUST like that is fairly dicey with the > > current IESG. But the former parsing is not problematic, and it sounds > > like that's what you intended. Perhaps "MUST give general guidelines for > > populating" would avoid the misparse, though it may have problems of its > > own. > [acm] > Let's try your suggestion. > > The specification defining the new column(s) MUST give general guidelines > for populating the new column(s) for existing entries. > > > > > > > > ... > > > > Section 7.3.5 > > > > > > > > devices. For example, parameters that include an IPv4 address can > > be > > > > encoded as a 32 bit integer (i.e. binary base64 encoded value) or > > ip- > > > > address as defined in [RFC6991]. The actual encoding(s) used must > > be > > > > > > > > nit: YANG types are specified distinctly from their possible > > encodings; > > > > indicating an XML or JSON encoded version of the YANG ip-address would > > > > be appropriate here. > > > [acm] > > > Yes, and we go on in the next sentence to say: > > > The actual encoding(s) used must be explicitly defined for each Run- > > time parameter. > > > > Whoops, sorry for missing that. > [acm] > NP > > > > > > > > > > > explicitly defined for each Run-time parameter. IPv6 addresses and > > > > options MUST be accomodated, allowing Registered Metrics to be used > > > > in either address family. > > > > > > > > nit: is "either" too limiting, here? > > > [acm] > > > No, especially for active testing, where we generate the test traffic > > > in one address family at a time. > > > > I meant, we're implicitly saying that IPv4 and IPv6 are the only address > > families that anyone will ever care about. IANA has quite a few more than > > two that are defined... > [acm] > I didn't see that coming. I don't read any of the examples of > Run-time Parameters as the limiting set in this section. > > Let's try: > IPv6 addresses and options MUST be accommodated, allowing Registered > Metrics to be used in *that* address family. > *Other address families are permissable.* Thanks. > > > > > > > ... > > > > Thanks :) > > > > -Ben > > > [acm] Thank you, Ben. > > I'll be holding these changes in another working version, > pending a few more questions from Michelle/IANA. Sounds good. -Ben
- [ippm] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [ippm] Benjamin Kaduk's No Objection on draft… MORTON, ALFRED C (AL)
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's No Objection on draft… MORTON, ALFRED C (AL)
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk