From nobody Sun Sep 6 08:46:37 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C11B3C37; Sun, 6 Sep 2015 08:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 zN74Kw0znhz6; Sun, 6 Sep 2015 08:46:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB921B3C31; Sun, 6 Sep 2015 08:46:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150906154633.18296.30662.idtracker@ietfa.amsl.com> Date: Sun, 06 Sep 2015 08:46:33 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-active-passive-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 15:46:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Active and Passive Metrics and Methods (and everything in-between, or Hybrid) Author : Al Morton Filename : draft-ietf-ippm-active-passive-01.txt Pages : 12 Date : 2015-09-06 Abstract: This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as Active or Passive. Some methods may use a subset of both active and passive attributes, and we refer to these as Hybrid Methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-active-passive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-active-passive-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-active-passive-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 6 09:31:21 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7CD1B4833 for ; Sun, 6 Sep 2015 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FcT33cwSFs0d for ; Sun, 6 Sep 2015 09:31:18 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E86461B47E1 for ; Sun, 6 Sep 2015 09:31:17 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 763C51201E2 for ; Sun, 6 Sep 2015 12:54:04 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id 90B23E1072 for ; Sun, 6 Sep 2015 12:28:33 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sun, 6 Sep 2015 12:28:33 -0400 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Date: Sun, 6 Sep 2015 12:28:32 -0400 Thread-Topic: I-D Action: draft-ietf-ippm-active-passive-01.txt Thread-Index: AdDou0PoPBmFS966RhSfjk/787sdkAABR+LA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB27973EF@NJFPSRVEXG0.research.att.com> References: <20150906154633.18296.30662.idtracker@ietfa.amsl.com> In-Reply-To: <20150906154633.18296.30662.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-active-passive-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 16:31:19 -0000 In Prague IETF, I felt the active-passive draft was nearly done, but by addressing Tiziano's comment to add "Hybrid" to the title, it prompted Brian Trammell to ask for more detail and traceability to the Hybrid definitions we have discussed in the past. This was a discussion we had in 2012. The relevant links to archive are: https://www.ietf.org/mail-archive/web/ippm/current/msg02953.html and https://www.ietf.org/mail-archive/web/ippm/current/msg02952.html (with a link to Brian's draft at the time). I have included all the possibilities we have discussed in the=20 draft now, including Spatial Metrics RFC 5644 that I mentioned at the session. regards, Al > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Sunday, September 06, 2015 11:47 AM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: I-D Action: draft-ietf-ippm-active-passive-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Performance Metrics Working Group > of the IETF. >=20 > Title : Active and Passive Metrics and Methods (and > everything in-between, or Hybrid) > Author : Al Morton > Filename : draft-ietf-ippm-active-passive-01.txt > Pages : 12 > Date : 2015-09-06 >=20 > Abstract: > This memo provides clear definitions for Active and Passive > performance assessment. The construction of Metrics and Methods can > be described as Active or Passive. Some methods may use a subset of > both active and passive attributes, and we refer to these as Hybrid > Methods. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-active-passive/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ippm-active-passive-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-active-passive-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Sep 7 04:47:04 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE01B4FF6 for ; Mon, 7 Sep 2015 04:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 vl2Fj2ENZgb7 for ; Mon, 7 Sep 2015 04:47:00 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 4FBAC1B4FF0 for ; Mon, 7 Sep 2015 04:47:00 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t87Bj450030841; Mon, 7 Sep 2015 04:46:58 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 1wqywgmwv4-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 07 Sep 2015 04:46:58 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 7 Sep 2015 14:46:55 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1044.021; Mon, 7 Sep 2015 14:46:55 +0300 From: Tal Mizrahi To: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Thread-Topic: I-D Action: draft-ietf-ippm-active-passive-01.txt Thread-Index: AQHQ6MF4gof5/5B5REqqreWzKTvJ454w5htw Date: Mon, 7 Sep 2015 11:46:54 +0000 Message-ID: <7670eedc2615415187c57a33ae4e748a@IL-EXCH02.marvell.com> References: <20150906154633.18296.30662.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D0BB27973EF@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB27973EF@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509070179 Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-active-passive-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 11:47:02 -0000 Hi Al, I believe the draft is both useful and well written. A few comments / questions: 1. I was wondering how to classify Y.1731 loss measurement (LM). It appears= to fit into Hybrid Type I, since you could say that Y.1731 augments or mod= ifies the stream of interest, by occasionally injecting an LM message. It looks like Y.1731 delay measurement (DM) and synthetic loss measurem= ent (SLM) fall under active measurement. 2. In general, it may be nice to add some discussion about protocols that u= se OAM messages for Hybrid Type I measurement. Y.1731 is just an example, b= ut there are others (e.g., RFC 6374, RFC 7456). 3. It is probably a good idea to mention the term "synthetic" (=3D=3Dactive= ), which is used in Y.1731. 4. It may be worthwhile to mention the terminology of RFC 6374. I believe:= =20 direct measurement (RFC 6374) =3D=3D passive / hybrid type I inferred measurement (RFC 6374) =3D=3D active measurement Minor comments: - "Since measurement usually requires determining the corresponding packets= at multiple measurement points, a sequence number is the most common infor= mation dedicated to measurement." There is a hidden assumption that we are talking about a loss metric, but= if we are talking about other metrics (e.g., delay), then this "informatio= n" may be a timestamp rather than a sequence number. - " If you augment of modify a stream of interest" --> If you augment *or* = modify a stream of interest Thanks, Tal. >-----Original Message----- >From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED >C (AL) >Sent: Sunday, September 06, 2015 7:29 PM >To: ippm@ietf.org >Subject: Re: [ippm] I-D Action: draft-ietf-ippm-active-passive-01.txt > >In Prague IETF, I felt the active-passive draft was nearly done, but by >addressing Tiziano's comment to add "Hybrid" to the title, it prompted Bri= an >Trammell to ask for more detail and traceability to the Hybrid definitions= we >have discussed in the past. This was a discussion we had in 2012. > >The relevant links to archive are: >https://www.ietf.org/mail-archive/web/ippm/current/msg02953.html >and >https://www.ietf.org/mail-archive/web/ippm/current/msg02952.html >(with a link to Brian's draft at the time). > >I have included all the possibilities we have discussed in the draft now, >including Spatial Metrics RFC 5644 that I mentioned at the session. > >regards, >Al > > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Sunday, September 06, 2015 11:47 AM >> To: i-d-announce@ietf.org >> Cc: ippm@ietf.org >> Subject: I-D Action: draft-ietf-ippm-active-passive-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Performance Metrics Working Group >> of the IETF. >> >> Title : Active and Passive Metrics and Methods (and >> everything in-between, or Hybrid) >> Author : Al Morton >> Filename : draft-ietf-ippm-active-passive-01.txt >> Pages : 12 >> Date : 2015-09-06 >> >> Abstract: >> This memo provides clear definitions for Active and Passive >> performance assessment. The construction of Metrics and Methods can >> be described as Active or Passive. Some methods may use a subset of >> both active and passive attributes, and we refer to these as Hybrid >> Methods. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ippm-active-passive/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ippm-active-passive-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-active-passive-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Sep 11 07:48:16 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685AE1B4C35; Fri, 11 Sep 2015 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 f5BFQHvWsYRx; Fri, 11 Sep 2015 07:48:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3531ACE12; Fri, 11 Sep 2015 07:48:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150911144814.30700.18166.idtracker@ietfa.amsl.com> Date: Fri, 11 Sep 2015 07:48:14 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-owamp-registry-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 14:48:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Registries for the One-Way Active Measurement Protocol - OWAMP Author : Al Morton Filename : draft-ietf-ippm-owamp-registry-03.txt Pages : 7 Date : 2015-09-11 Abstract: This memo describes the registries for OWAMP - the One-Way Active Measurement Protocol. The registries allow assignment of MODE bit positions and OWAMP Command numbers. The memo also requests that IANA establish the registries for new features, called the OWAMP- Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-owamp-registry/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-owamp-registry-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-owamp-registry-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 14 10:37:32 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1490A1B3DDB for ; Mon, 14 Sep 2015 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 X4t84SDCTYu0 for ; Mon, 14 Sep 2015 10:37:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C141B3DDF for ; Mon, 14 Sep 2015 10:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914173727.6405.84778.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 10:37:27 -0700 From: IETF Secretariat Archived-At: Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 17:37:31 -0000 Changed milestone "Submit a draft defining terminology for the continuum of passive and active measurement to the IESG as Informational", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ippm/charter/ From nobody Mon Sep 14 15:46:37 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220E81B3AE3 for ; Mon, 14 Sep 2015 15:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RrndmQ88dBh7 for ; Mon, 14 Sep 2015 15:46:34 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 986381B3A65 for ; Mon, 14 Sep 2015 15:46:34 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id A5FCA121C70 for ; Mon, 14 Sep 2015 19:12:28 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 01C82E0FE1 for ; Mon, 14 Sep 2015 18:44:56 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 14 Sep 2015 18:46:29 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "ippm@ietf.org" Date: Mon, 14 Sep 2015 18:46:29 -0400 Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 22:46:36 -0000 Hi Barbara, Thanks for your review and comments. please see a reply to one comment below, Al > -----Original Message----- ... > 4. Scope > FROM > This document is meant for two different audiences. > TO > This document is meant for three different purposes. >=20 > ADD the following as penultimate paragraph: > The third purpose is to define a Performance Metrics Registry format > that will be used by the IANA Performance Metrics Registry and other > Performance Metrics Registries. This will be particularly useful to > implementation of the Large-scale Measurement Platform framework > [framework reference] and information model [information model > reference], who will need to use registries for Performance Metrics > defined by other entities. >=20 [ACM]=20 One key theme in your comments is the proposal to separate the registry for= mat from the IANA Registry creation/process, and possibly re-use the format= elsewhere. There's quite a bit of editorial work to accomplish the separat= ion and include the additional goal of a separable registry format. Perhaps the goal of a re-usable format can be accomplished with far fewer e= dits by saying that the format *may* serve other purposes, rather than maki= ng re-use an equal goal (at the end of section 2, Introduction): Barbara's proposed re-wording: This document therefore creates an IANA-maintained Performance Metrics Regi= stry and a Performance Metrics Registry format (that will be usable by IANA= and any other organization which wishes to create a Performance Metrics Re= gistry). NEW This document therefore requests that IANA create and maintain a Performanc= e Metrics Registry, according to the maintenance procedures and the Perform= ance Metrics Registry format defined in this memo. Although the Registry fo= rmat is primarily for use by IANA, any other organization that wishes to cr= eate a local Performance Metrics Registry MAY use the format for its purpos= es. I think this is effectively the same outcome. We probably have some words a= bout re-use because I remember Phil was an advocate of that possibility. I discussed this approach with the co-authors. We don't want the additional= goal of a re-usable format to open a new can of worms that we never though= t-of ... that would be tragic at this point. By making re-use a MAY, we fe= nd-off any expansions someone might dream-up more easily, and keep the fini= sh line in sight. Can you live with this compromise? From nobody Wed Sep 16 06:57:04 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002AA1B3C9D for ; Wed, 16 Sep 2015 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 gidutWUWqpcm for ; Wed, 16 Sep 2015 06:57:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 737831B3C9F for ; Wed, 16 Sep 2015 06:57:01 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8GDsda2021850 for ; Wed, 16 Sep 2015 09:57:01 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 1wy3qpk8xt-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Sep 2015 09:57:00 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8GDuxBl027281 for ; Wed, 16 Sep 2015 09:57:00 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8GDusmY027245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 09:56:54 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor) for ; Wed, 16 Sep 2015 13:56:36 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 09:56:35 -0400 From: "STARK, BARBARA H" To: "MORTON JR., AL" , "ippm@ietf.org" Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQAE+PB7A= Date: Wed, 16 Sep 2015 13:56:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.65.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-16_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509160189 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:57:03 -0000 > Barbara's proposed re-wording: > This document therefore creates an IANA-maintained Performance Metrics > Registry and a Performance Metrics Registry format (that will be usable b= y > IANA and any other organization which wishes to create a Performance > Metrics Registry). >=20 > NEW > This document therefore requests that IANA create and maintain a > Performance Metrics Registry, according to the maintenance procedures and > the Performance Metrics Registry format defined in this memo. Although th= e > Registry format is primarily for use by IANA, any other organization that > wishes to create a local Performance Metrics Registry MAY use the format > for its purposes. > The authors make no guarantee of the format's applicability to *any* > possible set of Performance Metrics envisaged by other organizations. > > >=20 > I think this is effectively the same outcome. We probably have some words > about re-use because I remember Phil was an advocate of that possibility. >=20 > I discussed this approach with the co-authors. We don't want the addition= al > goal of a re-usable format to open a new can of worms that we never > thought-of ... that would be tragic at this point. By making re-use a MA= Y, we > fend-off any expansions someone might dream-up more easily, and keep > the finish line in sight. >=20 > Can you live with this compromise? Hi Al (and Marcelo), Sorry it took me a couple of days to reply. I needed to go back and look at= the detailed comments I provided the authors (in a separate email sent jus= t to the authors) to see if I could figure out why my suggestion for this d= raft to have a goal of creating a common registry format is objectionable. = Given I provided (in that email to the authors) a very detailed proposal fo= r dealing with my comments, I have to disagree with Marcelo that what I sug= gest would add years to the approval process for metric-registry. I believe that IETF could provide a big service to the industry as a whole = if it presented metric-registry as defining a format explicitly intended to= be usable by others. It would then be possible for lmap-information-model = to normatively reference metric-registry, instead of informatively. A norma= tive reference in lmap-information-model would mean that software could be = written to follow the registry URI (that is a data element in lmap-informat= ion-model ) and pull out certain information for presentation to the user o= r to act upon. Having the format of a registry entry behind an lmap-informa= tion-model registry URI be non-standard weakens the usefulness of the overa= ll lmap solution significantly.=20 This weakened overall solution is particularly unfortunate, since all it wo= uld take (IMO) would be to state that a goal of metric-registry is to provi= de a standard format, and then normatively reference metric-registry in lma= p-information-model as specifying the required (or strongly recommended, i.= e., SHOULD) registry format for a registry URI. And doing this doesn't impa= ct the proposed format in metric-registry at all. In all but one instance, = the changes I suggested were to text that describes the purpose of the docu= ment. The only normative element of registry-format that I proposed modifyi= ng was the mandatory naming requirement of inserting "Act_" or "Pas_" in fr= ont of the name. But if people also intend to be steadfast in refusing to have metric-regist= ry as a normative reference in lmap-information-model, then I don't really = care whether any changes are made to metric-registry to suggest this as a d= istant possibility. Without a normative reference in lmap-information-model= , my suggestion is irrelevant. The lmap platform will be weaker than hoped.= It would take significantly more work to get to the level of standardizati= on that could have been achieved by these changes, and I think it's unlikel= y anyone will bother with that. I won't stand in the way if I'm alone in believing that a standardized regi= stry format would make the overall lmap solution much stronger. Barbara From nobody Wed Sep 16 16:43:48 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138AE1A90A6 for ; Wed, 16 Sep 2015 16:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UzoGclUTYgLI for ; Wed, 16 Sep 2015 16:43:45 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C226F1A909E for ; Wed, 16 Sep 2015 16:43:44 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 238E91204B5 for ; Wed, 16 Sep 2015 20:08:02 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 12B40E1014 for ; Wed, 16 Sep 2015 19:40:22 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 16 Sep 2015 19:41:57 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "ippm@ietf.org" Date: Wed, 16 Sep 2015 19:41:55 -0400 Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQAE+PB7AAFW/W0A== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 23:43:47 -0000 Hi Barbara, Let's see if we can sort this out. Sorry for the long message. Co-authors don't want to add a *goal* that the Registry format be re-used, because: - it potentially adds an unknown amount of work to meet that goal. work on the registry has been in-progress for almost 3 years now. - we could be asked to liaise the registry with some number of SDOs, wait for their feedback, and implement the changes they want. I can imagine that process taking months alone, just to get feedback. - we are completely fine if others use this exact Registry Format, but we can't assure them it will be fit for all imaginable purposes. If the amount of time we spent on this is any indication, we should have extremely good coverage for network performance measurements. Adding the goal doesn't change the technical content (immediately), but somehow allows the Registry to become a normative reference in the LMAP Information Model draft. I don't understand how this works: you wrote: > I believe that IETF could provide a big service to the industry as a > whole if it presented metric-registry as defining a format explicitly > intended to be usable by others. It would then be possible for lmap- > information-model to normatively reference metric-registry, instead of > informatively. A normative reference in lmap-information-model would > mean that software could be written to follow the registry URI (that is > a data element in lmap-information-model ) and pull out certain > information for presentation to the user or to act upon. ... We can't require others to use our registry format in their local registrie= s from the Registry draft itself. But it seems to me that adding an Information Model requirement to use a=20 URI identical to the one in the Registry, and to connect the Info Model=20 URI to the URI and the related the Standardized Registry Format entry throu= gh a=20 normative reference is sufficient. > ... Having the > format of a registry entry behind an lmap-information-model registry URI > be non-standard weakens the usefulness of the overall lmap solution > significantly. I'm having trouble following the sentence above: The Registry Format is part of a Best Current Practice doc., certainly not Informational or Experimental. When other SDOs follow the format of the BCP, there's no problem for the URI to link to the right registry entry= . It seems like we need a very carefully crafted requirement in the=20 LMAP Information Model. A standard URI linked to the URI in the Registry and the format of Registry entries by a normative reference. So... Tell me where the copied URI and Reference doesn't work,=20 or how we can *encourage* Registry Format adoption beyond IANA without doing more than saying it,=20 explicitly, in the draft. regards, Al > -----Original Message----- > From: STARK, BARBARA H > Sent: Wednesday, September 16, 2015 9:57 AM > To: MORTON, ALFRED C (AL); ippm@ietf.org > Subject: RE: review of draft-ietf-ippm-metric-registry-03 >=20 > > Barbara's proposed re-wording: > > This document therefore creates an IANA-maintained Performance Metrics > > Registry and a Performance Metrics Registry format (that will be > > usable by IANA and any other organization which wishes to create a > > Performance Metrics Registry). > > > > NEW > > This document therefore requests that IANA create and maintain a > > Performance Metrics Registry, according to the maintenance procedures > > and the Performance Metrics Registry format defined in this memo. > > Although the Registry format is primarily for use by IANA, any other > > organization that wishes to create a local Performance Metrics > > Registry MAY use the format for its purposes. > > > The authors make no guarantee of the format's applicability to *any* > > possible set of Performance Metrics envisaged by other organizations. > > > > > > > I think this is effectively the same outcome. We probably have some > > words about re-use because I remember Phil was an advocate of that > possibility. > > > > I discussed this approach with the co-authors. We don't want the > > additional goal of a re-usable format to open a new can of worms that > > we never thought-of ... that would be tragic at this point. By making > > re-use a MAY, we fend-off any expansions someone might dream-up more > > easily, and keep the finish line in sight. > > > > Can you live with this compromise? >=20 > Hi Al (and Marcelo), > Sorry it took me a couple of days to reply. I needed to go back and look > at the detailed comments I provided the authors (in a separate email > sent just to the authors) to see if I could figure out why my suggestion > for this draft to have a goal of creating a common registry format is > objectionable. Given I provided (in that email to the authors) a very > detailed proposal for dealing with my comments, I have to disagree with > Marcelo that what I suggest would add years to the approval process for > metric-registry. >=20 > I believe that IETF could provide a big service to the industry as a > whole if it presented metric-registry as defining a format explicitly > intended to be usable by others. It would then be possible for lmap- > information-model to normatively reference metric-registry, instead of > informatively. A normative reference in lmap-information-model would > mean that software could be written to follow the registry URI (that is > a data element in lmap-information-model ) and pull out certain > information for presentation to the user or to act upon. Having the > format of a registry entry behind an lmap-information-model registry URI > be non-standard weakens the usefulness of the overall lmap solution > significantly. >=20 > This weakened overall solution is particularly unfortunate, since all it > would take (IMO) would be to state that a goal of metric-registry is to > provide a standard format, and then normatively reference metric- > registry in lmap-information-model as specifying the required (or > strongly recommended, i.e., SHOULD) registry format for a registry URI. > And doing this doesn't impact the proposed format in metric-registry at > all. In all but one instance, the changes I suggested were to text that > describes the purpose of the document. The only normative element of > registry-format that I proposed modifying was the mandatory naming > requirement of inserting "Act_" or "Pas_" in front of the name. >=20 > But if people also intend to be steadfast in refusing to have metric- > registry as a normative reference in lmap-information-model, then I > don't really care whether any changes are made to metric-registry to > suggest this as a distant possibility. Without a normative reference in > lmap-information-model, my suggestion is irrelevant. The lmap platform > will be weaker than hoped. It would take significantly more work to get > to the level of standardization that could have been achieved by these > changes, and I think it's unlikely anyone will bother with that. >=20 > I won't stand in the way if I'm alone in believing that a standardized > registry format would make the overall lmap solution much stronger. > Barbara From nobody Thu Sep 17 07:02:55 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A591A0015; Thu, 17 Sep 2015 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VET4-lxMYEur; Thu, 17 Sep 2015 07:02:53 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D21A00B9; Thu, 17 Sep 2015 07:02:50 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id CC28D1229CD; Thu, 17 Sep 2015 10:28:53 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 91E99E101C; Thu, 17 Sep 2015 10:01:14 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 17 Sep 2015 10:02:50 -0400 From: "MORTON, ALFRED C (AL)" To: Alan DeKok , "secdir@ietf.org" Date: Thu, 17 Sep 2015 10:02:49 -0400 Thread-Topic: Secdir review of draft-ietf-ippm-owamp-registry-03 Thread-Index: AdDwr+ejrlXABYCpRsygInVxFp7LpAAn3HQw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581583@NJFPSRVEXG0.research.att.com> References: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> In-Reply-To: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-ads@ietf.org" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-owamp-registry@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Secdir review of draft-ietf-ippm-owamp-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:02:55 -0000 Hi Alan, thanks for your review, please see replies below. FWIW - I had to look-up the details. Al > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Wednesday, September 16, 2015 2:03 PM > To: secdir@ietf.org > Cc: draft-ietf-ippm-owamp-registry@tools.ietf.org > Subject: Secdir review of draft-ietf-ippm-owamp-registry-03 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. >=20 > This document requests IANA allocation of registries for OWAMP. As > such, it has minimal security impact. >=20 > One practical note is the request to assign an "Experimentation" > OWAMP-Control Command Number. Experience shows that such numbers are > either never used, or used as experiments... which then get widely > deployed before standards action catches up to practical needs. [ACM]=20 I understand how this might happen, but IETF already has a=20 BCP that covers this topic: https://tools.ietf.org/html/bcp82 >=20 > It may be good to add some discussion as to *how* experiments are > done, and how experiments can transition from the "Experimentation" > number to a standard number. [ACM]=20 IMO, BCP82 covers this aspect adequately.=20 >=20 > One suggestion would be to change the label from "Experimentation" to > "Site-Local". That would still allow sites to experiment with OWAMP- > Control commands, but would make it clearer that such experimentation is > only for the local site, and MUST NOT be used in a wider context. [ACM]=20 Site-local is not a valid registry assignment, see: https://tools.ietf.org/html/rfc5226#section-4 Also, I would expect that an Internet performance characterization protocol will be deployed on the Internet when using an experimental comman= d to conduct experiments, so not Site-Local. Note that the existing reference to RFC5226 makes a clear reference to BCP 82 in section 4. From nobody Thu Sep 17 07:05:38 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0EF1A01E2 for ; Thu, 17 Sep 2015 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 My-YaOuxKp_J for ; Thu, 17 Sep 2015 07:05:35 -0700 (PDT) Received: from mx0b-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 083971A038D for ; Thu, 17 Sep 2015 07:04:48 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8HDxWnH018414 for ; Thu, 17 Sep 2015 10:04:48 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 1wy3qqfe89-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 17 Sep 2015 10:04:47 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8HE4lUJ021787 for ; Thu, 17 Sep 2015 10:04:47 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8HE4fXD021626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 10:04:41 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 17 Sep 2015 14:04:33 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 10:04:33 -0400 From: "STARK, BARBARA H" To: "MORTON JR., AL" , "ippm@ietf.org" Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQAE+PB7AAFW/W0AAfEhpQ Date: Thu, 17 Sep 2015 14:04:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA04728@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-17_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509170211 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:05:37 -0000 > Co-authors don't want to add a *goal* that the Registry format be re-used= , Would it be possible for the document to at least say that it defines a Per= formance Metrics Registry format in addition to defining the IANA Performan= ce Metrics Registry? Make the format definition a distinct and important a= spect of the draft? No need to say that a reason is for re-use. Just that t= he document defines a Performance Metrics Registry format. That makes it ea= sier for others to reference just the format. From an external org perspect= ive, referencing a format in a document that doesn't even acknowledge in it= s abstract, introduction, and scope that it defines a format is very awkwar= d. And then (preferably) recommend (no need to capitalize) that anyone wanting= to create a registry that is intended to be used within the context of the= LMAP framework and information model use the same format. If not willing to "recommend", then don't use MAY (which suggests "you can = if you want, but we don't know why you'd want to and don't really see a ben= efit to it"). Say rather "can". Anyone wanting to create a registry that is= intended to be used within the context of the LMAP framework and informati= on model can use the same format. But then also maybe mention that there are benefits to doing this, like: Us= ing the same format can benefit developers of Measurement Agents by allowin= g them to develop code that can parse entries in any Registry that uses thi= s format. But the big thing really is just acknowledging that the document defines a = Registry format. It would be great to mention that the format can be used b= y other registries, but that wasn't really the biggest thing I was trying t= o accomplish. Does this bring us any closer? Barbara From nobody Thu Sep 17 15:50:10 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5E11A1EF2 for ; Thu, 17 Sep 2015 15:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 pkjlYLAM2zjh for ; Thu, 17 Sep 2015 15:50:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 448991A1DBE for ; Thu, 17 Sep 2015 15:50:07 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8HMo6o3023580 for ; Thu, 17 Sep 2015 18:50:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 1wy3qq8y2e-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 17 Sep 2015 18:50:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8HMo5qo020768 for ; Thu, 17 Sep 2015 18:50:05 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8HMnwSA020678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 18:50:01 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 17 Sep 2015 22:49:46 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 18:49:46 -0400 From: "STARK, BARBARA H" To: "MORTON JR., AL" , "ippm@ietf.org" Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQAE+PB7AAFW/W0AAyAdFw Date: Thu, 17 Sep 2015 22:49:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA06396@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.214.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509170284 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 22:50:08 -0000 > Co-authors don't want to add a *goal* that the Registry format be re-used= , > because: I've thought some more, and would like to suggest the following, much brief= er, slightly modified, and more concrete proposal. This is mostly consisten= t with the previous proposal. 1. Acknowledge in Abstract, Introduction, and Scope that the document defin= es a Registry format. [This is really important, in order for other orgs to= feel comfortable referencing just the format.] 2. Mention in the Introduction that while the Registry format is being defi= ned for the IANA Registry, other Registries may choose to use it as well. (= that's the non-normative may) 3. Also in the Introduction, mention that others who are creating Registrie= s to be used in the context of an LMAP framework are encouraged to use the = Registry format, because this makes it easier for developers of LMAP Measur= ement Agents (MAs) to programmatically use information found in those other= Registries' entries. Barbara From nobody Thu Sep 17 20:41:48 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB7D1A1B34 for ; Thu, 17 Sep 2015 20:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LuUI4UPgbgBS for ; Thu, 17 Sep 2015 20:41:44 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id AA75B1A1B47 for ; Thu, 17 Sep 2015 20:41:42 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 781A81228F3 for ; Fri, 18 Sep 2015 00:07:46 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 3F2C2F04F5 for ; Thu, 17 Sep 2015 23:41:41 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 17 Sep 2015 23:41:41 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "ippm@ietf.org" Date: Thu, 17 Sep 2015 23:41:40 -0400 Thread-Topic: review of draft-ietf-ippm-metric-registry-03 Thread-Index: AdDDD+y3tLoWXB/ISqG16GTQ1S2CNwsLUaOQAE+PB7AAFW/W0AAyAdFwAAnNJuA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB45816BF@NJFPSRVEXG0.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113AA06396@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA06396@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 03:41:47 -0000 Thanks Barbara, this helps a lot and I think the co-authors will probably agree. See replies below (which are hopefully readable, it's getting late here...). regards, Al > -----Original Message----- > From: STARK, BARBARA H > Sent: Thursday, September 17, 2015 6:50 PM > To: MORTON, ALFRED C (AL); ippm@ietf.org > Subject: RE: review of draft-ietf-ippm-metric-registry-03 >=20 > > Co-authors don't want to add a *goal* that the Registry format be > > re-used, > > because: >=20 > I've thought some more, and would like to suggest the following, much > briefer, slightly modified, and more concrete proposal. This is mostly > consistent with the previous proposal. >=20 > 1. Acknowledge in Abstract, Introduction, and Scope that the document > defines a Registry format. [This is really important, in order for other > orgs to feel comfortable referencing just the format.] [ACM]=20 I think that's fine, at least the text I proposed for the Intro (Monday) di= d that. It's fairly easy to separate the request to create the Registry, the format, and the process to admin the registry, because they're all in different sections. There's some editing to do, but it seems=20 reasonable to me. > 2. Mention in the > Introduction that while the Registry format is being defined for the > IANA Registry, other Registries may choose to use it as well. (that's > the non-normative may)=20 [ACM]=20 Yes, also in the text I proposed for the Intro. > 3. Also in the Introduction, mention that others > who are creating Registries to be used in the context of an LMAP > framework are encouraged to use the Registry format, because this makes > it easier for developers of LMAP Measurement Agents (MAs) to > programmatically use information found in those other Registries' > entries. >=20 And that's what us hockey players call a "hat trick", and as you suggest, we'll s/MAY/are encouraged to/ and add the last part of your sentence above [ACM]=20 NEW (from Monday, yet to be modified). This document therefore requests that IANA create and maintain a Performanc= e Metrics Registry, according to the maintenance procedures and the Perform= ance Metrics Registry format defined in this memo. Although the Registry fo= rmat is primarily for use by IANA, any other organization that wishes to cr= eate a local Performance Metrics Registry MAY use the format for its purpos= es. From nobody Thu Sep 17 21:56:02 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901B01A8AB6 for ; Thu, 17 Sep 2015 21:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 vuATobBWeVwE for ; Thu, 17 Sep 2015 21:55:58 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 60BEA1A6F34 for ; Thu, 17 Sep 2015 21:55:58 -0700 (PDT) Received: by wicge5 with SMTP id ge5so16504525wic.0 for ; Thu, 17 Sep 2015 21:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=K7PNFI7xr8qRsx4HQLv572bAo46GbAKmuc8Av9hE1uE=; b=JiJRdEbT6ZgZbM4OEbTeUkgDkp+t6kUQFkBXKhq0oJR1klqJe6BiKYfBRwuLD9hcPD kl/TEgwtCe7UmbPVjZSMNPfV88K07DWnwtExr8uQLd9LbnUyvokrwktsluc2Tk7+LaWE /F74uGt7pLoja6bEFZ3TrMW06vF9Qs/GG4ltYJNCQFRmEEY+Bm5ToI7DJalpBJBEY3oZ OeoC2CZPfbRnnFJOER5uuL9bwxcMUrRsF9STKPGYaklsrBie3u/n5JHfElQKLSSUTeu5 p6xI93EYJHOkUW54keAoxrlSBJTAJgyVXc6zGjoj5I2/rS2KtA1GHeKorXzo7sOflBJT 5t2g== X-Gm-Message-State: ALoCoQlsKweGP6BJ+XVJvN1UZDLELn3JonWpHA5m10JDuUy2Z23qWmvLCq4VzT9ZdhdXKXSiGvOz X-Received: by 10.194.117.70 with SMTP id kc6mr4382019wjb.13.1442552157006; Thu, 17 Sep 2015 21:55:57 -0700 (PDT) Received: from Macintosh-6.local (67.249.222.87.dynamic.jazztel.es. [87.222.249.67]) by smtp.gmail.com with ESMTPSA id fr10sm13442032wib.14.2015.09.17.21.55.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2015 21:55:56 -0700 (PDT) To: ippm@ietf.org References: <2D09D61DDFA73D4C884805CC7865E61132A79DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB458122D@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113A9FFAA0@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB4581540@NJFPSRVEXG0.research.att.com> <2D09D61DDFA73D4C884805CC7865E6113AA06396@GAALPA1MSGUSRBF.ITServices.sbc.com> <4AF73AA205019A4C8A1DDD32C034631D0BB45816BF@NJFPSRVEXG0.research.att.com> From: marcelo bagnulo braun Message-ID: <55FB995B.2000503@it.uc3m.es> Date: Fri, 18 Sep 2015 06:55:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB45816BF@NJFPSRVEXG0.research.att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] review of draft-ietf-ippm-metric-registry-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 04:56:01 -0000 I am ok with this (or something in these lines) thanks, marcelo El 18/09/15 a las 05:41, MORTON, ALFRED C (AL) escribió: > Thanks Barbara, this helps a lot and I think the co-authors will > probably agree. See replies below (which are hopefully readable, > it's getting late here...). > > regards, > Al > >> -----Original Message----- >> From: STARK, BARBARA H >> Sent: Thursday, September 17, 2015 6:50 PM >> To: MORTON, ALFRED C (AL); ippm@ietf.org >> Subject: RE: review of draft-ietf-ippm-metric-registry-03 >> >>> Co-authors don't want to add a *goal* that the Registry format be >>> re-used, >>> because: >> I've thought some more, and would like to suggest the following, much >> briefer, slightly modified, and more concrete proposal. This is mostly >> consistent with the previous proposal. >> >> 1. Acknowledge in Abstract, Introduction, and Scope that the document >> defines a Registry format. [This is really important, in order for other >> orgs to feel comfortable referencing just the format.] > [ACM] > I think that's fine, at least the text I proposed for the Intro (Monday) did that. > It's fairly easy to separate the request to create the Registry, > the format, and the process to admin the registry, because they're > all in different sections. There's some editing to do, but it seems > reasonable to me. > >> 2. Mention in the >> Introduction that while the Registry format is being defined for the >> IANA Registry, other Registries may choose to use it as well. (that's >> the non-normative may) > [ACM] > Yes, also in the text I proposed for the Intro. > >> 3. Also in the Introduction, mention that others >> who are creating Registries to be used in the context of an LMAP >> framework are encouraged to use the Registry format, because this makes >> it easier for developers of LMAP Measurement Agents (MAs) to >> programmatically use information found in those other Registries' >> entries. >> > And that's what us hockey players call a "hat trick", and as you suggest, > we'll s/MAY/are encouraged to/ > and add the last part of your sentence above > [ACM] > > NEW (from Monday, yet to be modified). > This document therefore requests that IANA create and maintain a Performance Metrics Registry, according to the maintenance procedures and the Performance Metrics Registry format defined in this memo. Although the Registry format is primarily for use by IANA, any other organization that wishes to create a local Performance Metrics Registry MAY use the format for its purposes. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > From nobody Tue Sep 29 09:08:44 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C570B1B46C2 for ; Tue, 29 Sep 2015 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eajce0tO1Hmk for ; Tue, 29 Sep 2015 09:08:40 -0700 (PDT) Received: from teledg002ba020.telecomitalia.it (teledg002ba020.telecomitalia.it [156.54.233.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E2D1B46C0 for ; Tue, 29 Sep 2015 09:08:38 -0700 (PDT) Received: from TELCAH001BA020.telecomitalia.local (10.188.101.214) by teledg002ba020.telecomitalia.it (10.188.101.211) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 29 Sep 2015 18:08:34 +0200 Received: from TELMBA001BA020.telecomitalia.local ([169.254.1.132]) by TELCAH001BA020.telecomitalia.local ([10.188.101.214]) with mapi id 14.03.0181.006; Tue, 29 Sep 2015 18:08:34 +0200 From: Fioccola Giuseppe To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-tempia-ippm-p3m-01.txt Thread-Index: AQHQ9Fjap2NEVjOY2kKkzJW6UXsTuZ5TL7OwgAAAZkA= Date: Tue, 29 Sep 2015 16:08:34 +0000 Message-ID: <23126F6FC5CA3E44916CF99D4E0B878B44E54C01@TELMBA001BA020.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.188.101.189] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [ippm] I: New Version Notification for draft-tempia-ippm-p3m-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:08:43 -0000 RGVhciBJUFBNZXJzLA0KDQpkcmFmdC10ZW1waWEtaXBwbS1wM20tMDEgaGFzIGJlZW4gcG9zdGVk LiBJdCB0cmllcyB0byBnZW5lcmFsaXplIHRoZSBhbHRlcm5hdGUgbWFya2luZyBtZXRob2RvbG9n eSwgaW4gb3JkZXIgdG8gaGF2ZSBhIHJlZmVyZW5jZSBwb2ludCBmb3Igb3RoZXIgc29sdXRpb25z IGJhc2VkIG9uIHRoaXMgdGVjaG5pcXVlLg0KDQpDb21tZW50cyBhbmQgcXVlc3Rpb25zIGFyZSB3 ZWxjb21lLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkdpdXNlcHBlDQoNCi0tLS0tTWVzc2FnZ2lvIG9y aWdpbmFsZS0tLS0tDQpEYTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KSW52aWF0bzogbHVuZWTDrCAyMSBzZXR0ZW1icmUgMjAxNSAx MjozMw0KQTogQ2FzdGFsZGVsbGkgTHVjYSBNYXJpYTsgRmlvY2NvbGEgR2l1c2VwcGU7IEFsYmVy dG8gVGVtcGlhIEJvbmRhOyBDYXBlbGxvIEFsZXNzYW5kcm87IEZpb2Njb2xhIEdpdXNlcHBlOyBD b2NpZ2xpbyBNYXVybzsgQ29jaWdsaW8gTWF1cm87IENhc3RhbGRlbGxpIEx1Y2EgTWFyaWE7IENh cGVsbG8gQWxlc3NhbmRybzsgQWxiZXJ0byBUZW1waWEgQm9uZGENCk9nZ2V0dG86IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGVtcGlhLWlwcG0tcDNtLTAxLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10ZW1waWEtaXBwbS1wM20tMDEudHh0IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR2l1c2VwcGUgRmlvY2NvbGEgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtdGVtcGlhLWlw cG0tcDNtDQpSZXZpc2lvbjogICAgICAgMDENClRpdGxlOiAgICAgICAgICBBIHBhY2tldCBiYXNl ZCBtZXRob2QgZm9yIHBhc3NpdmUgcGVyZm9ybWFuY2UgbW9uaXRvcmluZw0KRG9jdW1lbnQgZGF0 ZTogIDIwMTUtMDktMjENCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOiAgICAgICAgICAyMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC10ZW1waWEtaXBwbS1wM20tMDEudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGlhLWlwcG0tcDNt Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1w aWEtaXBwbS1wM20tMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtdGVtcGlhLWlwcG0tcDNtLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBwYXNzaXZlIG1ldGhvZCB0byBwZXJmb3JtIHBhY2tldCBsb3Nz LA0KICAgZGVsYXkgYW5kIGppdHRlciBtZWFzdXJlbWVudHMgb24gbGl2ZSB0cmFmZmljLiAgVGhp cyBtZXRob2QgaXMgYmFzZWQNCiAgIG9uIEFsdGVybmF0ZSBNYXJraW5nIHRlY2huaXF1ZSwgYWxz byBjYWxsZWQgUE5QTSAoUGFja2V0IE5ldHdvcmsNCiAgIFBlcmZvcm1hbmNlIE1vbml0b3Jpbmcp LiAgSXQgaGFzIGJlZW4gaW52ZW50ZWQgYW5kIGVuZ2luZWVyZWQgaW4NCiAgIFRlbGVjb20gSXRh bGlhLiAgVGhpcyB0ZWNobmlxdWUgY2FuIGJlIGFwcGxpZWQgaW4gdmFyaW91cyBzaXR1YXRpb25z DQogICAoZS5nLiAgW0ktRC5icnlhbnQtbXBscy1zeW5vbnltb3VzLWZsb3ctbGFiZWxzXSwNCiAg IFtJLUQuaWV0Zi1iaWVyLW1wbHMtZW5jYXBzdWxhdGlvbl0pLiAgVGhlIFRlbGVjb20gSXRhbGlh IHVzZSBjYXNlIGlzDQogICBleHBsYWluZWQgaW4gb3JkZXIgdG8gZ2l2ZSBhbiBleGFtcGxlIGFu ZCBzaG93IHRoZSBtZXRob2QNCiAgIGFwcGxpY2FiaWxpdHkuICBUaGUgcHJldmlvdXMgSUVURiBk cmFmdHMgYnkgVGVsZWNvbSBJdGFsaWEgYWJvdXQgdGhpcw0KICAgdGVjaG5pcXVlIHdlcmU6IFtJ LUQuY29jaWdsaW8tbWJvbmVkLW11bHRpY2FzdC1wbV0gYW5kDQogICBbSS1ELnRlbXBpYS1vcHNh d2ctcDNtXS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0K DQo= From nobody Wed Sep 30 03:27:49 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92B01B2E11 for ; Wed, 30 Sep 2015 03:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dnW05KBv4pNN for ; Wed, 30 Sep 2015 03:27:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B336B1B2E12 for ; Wed, 30 Sep 2015 03:27:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80022EA3 for ; Wed, 30 Sep 2015 12:27:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5HcV0DNDITc6 for ; Wed, 30 Sep 2015 12:27:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 30 Sep 2015 12:27:44 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C2F520053 for ; Wed, 30 Sep 2015 12:27:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4Kx4oFvsRRba; Wed, 30 Sep 2015 12:27:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DD792004E; Wed, 30 Sep 2015 12:27:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7676A376A808; Wed, 30 Sep 2015 12:27:42 +0200 (CEST) Date: Wed, 30 Sep 2015 12:27:41 +0200 From: Juergen Schoenwaelder To: ippm@ietf.org Message-ID: <20150930102741.GA1699@elstar.local> Mail-Followup-To: ippm@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [ippm] metric registry data formats X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:27:49 -0000 Hi, the metrics registry seems to mandate data encoding. For example, entries say that an IPv4 address is a 32 bit unsigned integer or that a timestampe is to be represented as a specific NTP encoding. The general assumption here seems to be that metric parameters (and outputs) are encoded in binary formats. Given that LMAP intends to use the metrics registry with protocols that use XML or JSON as their encoding, it seems kind of odd to represent parameters in binary (which essentially leads to base64 encoded values). My proposal would be that the metrics registry entries instead define clearly what the parameters are and what the precision requirements are but that they leave the encoding details to users of the registry. I would also be fine if there are specific suggestions, e.g., for use with YANG, the IP address parameters are represented as an ip-address as defined in RFC 6991. Or anything in between is fine - I just would dislike to configure parameters in binary base64 encoded values. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 30 03:29:24 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09C1B2E1F for ; Wed, 30 Sep 2015 03:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uKjdgToBwuqj for ; Wed, 30 Sep 2015 03:29:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB771B2E11 for ; Wed, 30 Sep 2015 03:29:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 484F1EA3 for ; Wed, 30 Sep 2015 12:29:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2lIHRbvxZi8w for ; Wed, 30 Sep 2015 12:29:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 30 Sep 2015 12:29:20 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C21B20053 for ; Wed, 30 Sep 2015 12:29:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sslfcb2JKHqv; Wed, 30 Sep 2015 12:29:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E5D32004E; Wed, 30 Sep 2015 12:29:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C8AF2376A85F; Wed, 30 Sep 2015 12:29:17 +0200 (CEST) Date: Wed, 30 Sep 2015 12:29:17 +0200 From: Juergen Schoenwaelder To: ippm@ietf.org Message-ID: <20150930102916.GB1699@elstar.local> Mail-Followup-To: ippm@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [ippm] metric registry parameter names X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:29:24 -0000 Hi, I think it would be desirable if parameters of metrics have well defined names. In section 4.3.5 of draft-morton-ippm-initial-registry-00.txt I see: o Upper limit on Poisson distribution (values above this limit will be clipped and set to the limit value). (if fixed, Upper limit = 30 seconds.) So what is the name of this option if I want to configure it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 30 03:37:45 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D3D1B2E2A for ; Wed, 30 Sep 2015 03:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E2GlDkVM7YPR for ; Wed, 30 Sep 2015 03:37:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7F31B2E29 for ; Wed, 30 Sep 2015 03:37:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9AA69FEF for ; Wed, 30 Sep 2015 12:37:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TKjMlu3VJbs1 for ; Wed, 30 Sep 2015 12:37:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 30 Sep 2015 12:37:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C55520054 for ; Wed, 30 Sep 2015 12:37:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id leFJi3l8xQ6y; Wed, 30 Sep 2015 12:37:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 471452004E; Wed, 30 Sep 2015 12:37:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29A9F376A89A; Wed, 30 Sep 2015 12:37:40 +0200 (CEST) Date: Wed, 30 Sep 2015 12:37:40 +0200 From: Juergen Schoenwaelder To: ippm@ietf.org Message-ID: <20150930103740.GC1699@elstar.local> Mail-Followup-To: ippm@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [ippm] metric registry url and related format / automation question X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:37:44 -0000 Hi, every registry entry has a set of identifiers: - a number (registry unique) - a (longish) name (registry unique) - a URN (a concatenation of the name with a registry prefix) (globally unique) - a URL to point to something retrivable The last one seems rather underspecified. Is the URL pointing to a web page that is intended for humans to read about the metric or is the idea that I get a machine readable version of the registry entry? In the later case, the format would have to be defined somehow. I guess the underlying question is whether tools are expected to access the registry in order to for example dynamically learn about the possible parameters (and their data types) for a metric or is the idea that essentially the conversion of the registry content into running code is a manual process? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 30 07:15:39 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208DB1A874A for ; Wed, 30 Sep 2015 07:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 rJBl7fWrlVZm for ; Wed, 30 Sep 2015 07:15:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B7AC21A877F for ; Wed, 30 Sep 2015 07:15:36 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t8UE4mN7015169; Wed, 30 Sep 2015 10:15:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 1x5ne5te01-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2015 10:15:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UEFY6d028639; Wed, 30 Sep 2015 10:15:34 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UEFQxf028380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2015 10:15:31 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 30 Sep 2015 14:15:08 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 10:15:08 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "ippm@ietf.org" Thread-Topic: [ippm] metric registry data formats Thread-Index: AQHQ+2quZT0IfQnn40qmBz4HHBjNXp5VAO2g Date: Wed, 30 Sep 2015 14:15:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA2F52A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150930102741.GA1699@elstar.local> In-Reply-To: <20150930102741.GA1699@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509300192 Archived-At: Subject: Re: [ippm] metric registry data formats X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:15:38 -0000 > the metrics registry seems to mandate data encoding. For example, entries > say that an IPv4 address is a 32 bit unsigned integer or that a timestamp= e is to > be represented as a specific NTP encoding. The general assumption here > seems to be that metric parameters (and > outputs) are encoded in binary formats. Given that LMAP intends to use th= e > metrics registry with protocols that use XML or JSON as their encoding, i= t > seems kind of odd to represent parameters in binary (which essentially le= ads > to base64 encoded values). >=20 > My proposal would be that the metrics registry entries instead define cle= arly > what the parameters are and what the precision requirements are but that > they leave the encoding details to users of the registry. > I would also be fine if there are specific suggestions, e.g., for use wit= h YANG, > the IP address parameters are represented as an ip-address as defined in > RFC 6991. Or anything in between is fine - I just would dislike to config= ure > parameters in binary base64 encoded values. I agree with Juergen that the data format (encoding) of run-time parameters= does not need to be specified. My expectation of the registry entries for the Run-time Parameters column w= ould be that the parameters listed use precisely the names of parameters fr= om the referenced specification (which is what the example from https://www= .ietf.org/proceedings/interim/2015/09/29/lmap/slides/slides-interim-2015-lm= ap-3-1.pdf mostly did). What's not clear to me is how these parameter names= are delimited in the registry. In order for them to be machine parsable (w= hich would be great), I really need to understand how they are delimited in= the registry entry. I would think comma delimited would be good, with quot= es around the names? "Src", "Dst", "T0", "Tf", "upper bound" [note that the upper bound, which t= he example has as "Upper limit on Poisson distribution" is problematic beca= use the reference (RFC2681) only loosely describes this concept and does no= t list it as a parameter] =20 I'm even more concerned with the format of registry entries that would be v= ery useful if they were machine-parsable, such as Fixed Parameters. The exa= mple of fixed parameters that was on slide 9 of https://www.ietf.org/procee= dings/interim/2015/09/29/lmap/slides/slides-interim-2015-lmap-3-1.pdf is ve= ry unparsable. Something like=20 "IPv4.dscp"=3D"0", "IPv4.ttl"=3D"255", "IPv4.protocol"=3D"17", "Tmax"=3D"3 = seconds", "payload.length"=3D"16 octets" [I was going to put the other elements listed as fixed parameters on that s= lide, but got really confused as to how a locally generated (at run-time?) = checksum, sequence number, and timestamp were "fixed" parameters -- really = what these seem to be are attempts to specify unspecified portions of the r= eference that hint at the need to include timestamp and sequence number in = the payload, which is awkward.] But something like this means there would need to be a list of these sorts = of fixed parameter names and how to express them. I would be tempted to use= something like Wireshark names for protocol components. Barbara From nobody Wed Sep 30 10:06:41 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B91A701A for ; Wed, 30 Sep 2015 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 7ris2XCI8z5e for ; Wed, 30 Sep 2015 10:06:37 -0700 (PDT) Received: from mx0b-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 63C231A870C for ; Wed, 30 Sep 2015 10:06:37 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8UH46nn021583; Wed, 30 Sep 2015 13:06:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 1x5qr8gaxg-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2015 13:06:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UH6ZbN030551; Wed, 30 Sep 2015 13:06:35 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UH6Uge030418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2015 13:06:32 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 30 Sep 2015 17:06:11 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 13:06:11 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "ippm@ietf.org" Thread-Topic: [ippm] metric registry parameter names Thread-Index: AQHQ+2rlYzddkP8baUWM/50Yuqg2+55VO8Mw Date: Wed, 30 Sep 2015 17:06:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA2F9D7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150930102916.GB1699@elstar.local> In-Reply-To: <20150930102916.GB1699@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-30_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509300214 Archived-At: Subject: Re: [ippm] metric registry parameter names X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 17:06:39 -0000 > I think it would be desirable if parameters of metrics have well defined > names. In section 4.3.5 of draft-morton-ippm-initial-registry-00.txt I se= e: >=20 > o Upper limit on Poisson distribution (values above this limit will > be clipped and set to the limit value). (if fixed, Upper limit =3D > 30 seconds.) >=20 > So what is the name of this option if I want to configure it? I agree. The problem here is that the referenced specification is a bit vag= ue wrt to certain "parameters", and the registry is being used as a means o= f tightening up the specification. I think that's fine, but what I would re= commend is that the Reference Definition field include the name and definit= ion of all parameters that are not explicitly named and defined in the refe= renced spec. I would rather the Fixed and Run-time Parameters simply provid= e a parsable list of parameters (and their values for Fixed Parameters), wi= th names taken either directly from the referenced spec or from a list of a= dditional parameters defined in the Reference Definition.=20 In the Act_IP_UDP_Round-trip_Delay_Raw_95th-percentile_Poisson example, the= Reference Definition would need to include text along the lines of... The following parameters are defined and/or provided default values here: "upper_limit" is the upper time limit on Poisson distribution (values above= this limit will be clipped and set to the limit value). Default is "upper_= limit"=3D"30 seconds". "seq_num" is an 8-byte field inside the payload of the test packet. The Src= host shall set the initial value of seq_num in the payload of the first te= st packet and increment it by 1 with each subsequent test packet. "timestamp" is an 8 byte field inside the payload of the test packet. The S= rc host shall set the timestamp value in each test packet payload. Both "seq_num" and "timestamp" need to be listed as Run-time Parameters, an= d not Fixed. BTW, the lambda definition in the registry sample may be wrong. RFC 2681 de= fines lambda as "a rate in reciprocal seconds" and 1/lambda as a time inter= val between packets; but the sample registry entry defines 1/lambda as a ra= te (packets/second). I think perhaps the registry parameter needs to be lam= bda and not 1/lambda. And since there seems to be a need to tighten RFC 2681 wrt default value of= lambda, I recommend putting such default recommendations also in Reference= Definition, with the other parameter definitions and defaults. Default "lambda"=3D"1 packet/second"=20 Barbara