From nobody Tue Oct 4 11:25:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C02129400 for ; Tue, 4 Oct 2016 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6eueDRcIpF1 for ; Tue, 4 Oct 2016 11:25:34 -0700 (PDT) Received: from mail.chartercom.com (mail.chartercom.com [24.176.92.28]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE5B12940B for ; Tue, 4 Oct 2016 11:25:34 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.31,444,1473138000"; d="scan'208,217"; a="45296092" Received: from unknown (HELO SC58MEXGP012.CORP.CHARTERCOM.com) ([172.24.253.140]) by mail.chartercom.com with ESMTP; 04 Oct 2016 13:20:10 -0500 Received: from SC58MEXGP007.CORP.CHARTERCOM.com (172.24.253.135) by SC58MEXGP012.CORP.CHARTERCOM.com (172.24.253.140) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 4 Oct 2016 13:25:32 -0500 Received: from SC58MEXGP007.CORP.CHARTERCOM.com ([fe80::bd11:e8a6:f9c9:9dea]) by SC58MEXGP007.CORP.CHARTERCOM.com ([fe80::bd11:e8a6:f9c9:9dea%19]) with mapi id 15.00.1104.000; Tue, 4 Oct 2016 13:25:32 -0500 From: "Weil, Jason A" To: "lmap@ietf.org" Thread-Topic: LMAP Interim Meeting - Oct 5 - Cancelled Thread-Index: AQHSHmyxZGxcrOjj00GtaB3ma1qcsg== Date: Tue, 4 Oct 2016 18:25:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.253.243] Content-Type: multipart/alternative; boundary="_000_D4196C5B60AF0jasonweilchartercom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP Interim Meeting - Oct 5 - Cancelled X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 18:25:35 -0000 --_000_D4196C5B60AF0jasonweilchartercom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LMAP WG, The chairs have decided to cancel tomorrow's proposed Interim meeting based= on feedback (or lack thereof) from the WG. The next meeting has been reque= sted for IETF 97 in Seoul, Korea with the date and time pending publication= of the agenda. The goal for the Seoul meeting will be to finalize the outs= tanding chartered drafts and determine if there is any interest in new work= . Thank You, Dan and Jason --_000_D4196C5B60AF0jasonweilchartercom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
LMAP WG, 

The chairs have decided to cancel tomorrow’s proposed Interim me= eting based on feedback (or lack thereof) from the WG. The next meeting has= been requested for IETF 97 in Seoul, Korea with the date and time pending = publication of the agenda. The goal for the Seoul meeting will be to finalize the outstanding chartered drafts and= determine if there is any interest in new work. 

Thank You,

Dan and Jason 
--_000_D4196C5B60AF0jasonweilchartercom_-- From nobody Fri Oct 7 11:24:13 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F51296BF for ; Fri, 7 Oct 2016 11:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQT7mswKgN6N for ; Fri, 7 Oct 2016 11:24:09 -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 1ABEC128B44 for ; Fri, 7 Oct 2016 11:24:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9A245779; Fri, 7 Oct 2016 20:24:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id COzsmSmsr6NF; Fri, 7 Oct 2016 20:24:03 +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; Fri, 7 Oct 2016 20:24:07 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DD9B2002B; Fri, 7 Oct 2016 20:24:07 +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 OZ2iWL4I-XCJ; Fri, 7 Oct 2016 20:24:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91C0A20013; Fri, 7 Oct 2016 20:24:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5A923CB3559; Fri, 7 Oct 2016 20:24:05 +0200 (CEST) Date: Fri, 7 Oct 2016 20:24:05 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20161007182405.GA20761@elstar.local> Mail-Followup-To: Ron Stana , "lmap@ietf.org" , "alissa@cooperw.in" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Data type for Option/Value X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:24:12 -0000 On Tue, Sep 27, 2016 at 09:24:34PM +0000, Ron Stana wrote: > LMAP Team, > > The data type for the option/value in the LMAP YANG model is currently defined as a string. Our tests use a structured set of input parameters, sometimes mandated by IETF YANG models such as TWAMP and TWAMP Light (see example below) so we currently have to stringify the data which makes it unnecessarily hard to read and requires an extra step before sending and parsing. > > "action":[ > > { > > "name":"Test-2016-09-27-16:54-action", > > "task":"twamp-initiator", > > "option":[ > > { > > "id":"twamp-light", > > "value":"{\"ietf-twamp-light:twamp-light\":{\"twamp-light-session-sender\":{\"sender-light-enable\":true,\"test-session\":[{\"session-id\":1,\"test-session-enable\":true,\"packet-padding-size\":425,\"session-authentication-mode\":\"unauthenticated\",\"interval\":10,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":0},{\"session-id\":2,\"test-session-enable\":true,\"packet-padding-size\":41,\"session-authentication-mode\":\"unauthenticated\",\"interval\":20,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":8}]}}}" > > } > > ], Why do you encode all twamp-light options in a single lmap task option? > > "destination":[ > > "Test-2016-09-27-16:54-results-periodic-pm", > > "Test-2016-09-27-16:54-results-periodic-rt" > > ] > > } > > ] > > > > Can the value object be changed in the LMAP YANG model so that it can contain another object (i.e. YANG's anyxml object type)? > Please take a look at appendix G of draft-ietf-lmap-yang-05.txt for a possible way to do this if plain name/value pairs are not good enough. Using anydata makes the data really opaque. But the most important aspect, I think, is that LMAP YANG module provides the proper hooks to enable future extensions (via the parameters container). /js PS: Note that options are automatically submitted with result reports; we should make sure that added structured parameters are also contained in result reports (anydata may work generically here since the format is implicitely defined). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 7 13:13:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264321296FE for ; Fri, 7 Oct 2016 13:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=viavisolutions.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 222GmpXMmUob for ; Fri, 7 Oct 2016 13:13:11 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0108.outbound.protection.outlook.com [104.47.38.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA7E129587 for ; Fri, 7 Oct 2016 13:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions.onmicrosoft.com; s=selector1-viavisolutions-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wp4tiMc+1XIWhQVoAK8YCO/iRRmZu9owtpK5hPNglwg=; b=DWN4XVmzkOaPV4smZT2fikJB1HhZFkkzeC6k7cNACkc7aO4JFT2Fu6TWXj9GKcjNqrBHwHjXmbvrYULzt53sxObt7eWKuNfAvCS6GRAnqWnjB6tsrco4GiwTb2LJoEojioGJpXqv1la7NDNopJq7ui+vpAptKbkre4DDmMExZ0Q= Received: from MWHPR18MB0960.namprd18.prod.outlook.com (10.173.123.14) by MWHPR18MB0958.namprd18.prod.outlook.com (10.173.123.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Fri, 7 Oct 2016 20:13:09 +0000 Received: from MWHPR18MB0960.namprd18.prod.outlook.com ([10.173.123.14]) by MWHPR18MB0960.namprd18.prod.outlook.com ([10.173.123.14]) with mapi id 15.01.0659.015; Fri, 7 Oct 2016 20:13:09 +0000 From: Ron Stana To: Juergen Schoenwaelder Thread-Topic: [lmap] Data type for Option/Value Thread-Index: AdIZBW2IFf380fCHS4+nER0bBjX6mAHwo66AAAA1ugA= Date: Fri, 7 Oct 2016 20:13:09 +0000 Message-ID: References: <20161007182405.GA20761@elstar.local> In-Reply-To: <20161007182405.GA20761@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ron.Stana@viavisolutions.com; x-originating-ip: [104.129.204.50] x-ms-office365-filtering-correlation-id: 4325f89f-53e9-4fc9-0044-08d3eeee5b89 x-microsoft-exchange-diagnostics: 1; MWHPR18MB0958; 6:J3j16G6eRNivKgI1me0lQMP+VeCzjvsG5ESTuhl94TpqDp5kOsmfgXZJhAb7ScRACE2hTmU+H0EBMJ4UhSMF9xzd6FUu5lUMaultqiOl8DcuwtFIu1nvtXUYp4YEJ5gqb0JgSPMueVdAzj6YTK4O9/57QEa22cxetfXnX2KA0Qt1S7n0czg6o8f+FXBgSMmdTBnnmRiIySaNlAYUlDscarQx5vQm6bLoERVwcu6GsgedgKyR0WCtJZJgQxqfgml2qeJ3vq1iNBvWoFbo0s0zCbklTwjDxKJlxZsihQmqJWrnCZH0MX/hYvObepezOQ4SRwTbauSkI9c8ggjj/+VmPDv4ycyvKqiBtd3Np8n1Myk=; 5:VjOr6//fGyDdoozQbj2ZFibOxb3HA0h/3F11vZVRuffpTyCURt1yuJc3P3hbzAkf+7rhDxKmR0B6aerBC5ZBu7AF9ywHOFmjQkqx12ueucp0WgiiaDkrBC+hEBk2SS8bPd8sVtoNKH80/iT8yTm3dQ==; 24:RoYinlPw3m34cBIoldPl6wpOXIZO40Sef47nToUc2eDZnPMmMxLpQ7ptgxCZ4tuQxSmugDe7ewrRBH3eDkga9ukpuF/qIS712JNsIRiO3J0=; 7:nd1UKwjwNBBLftLpjRGYYIzQ0KefJ4POgc1bqCW2soYeFGFSK7upCWY/wf84fkxJBv8h0CxV5XmR1B+igFJJ8aYyA2t6Nq9GvL6Ik8bnUgu9kMzWK1An5yacakVd9JjdUu6kd2C5ymu1nWhbKrcwfm1KJGJEdMb6e6/o2gbdf48HYfTPKeBqLufXEkHZeOpsJVQx+uShUupqNiU5fjwC/s5Fgf1g6ibDNK7jcnmDDF2whhzi7g9M6LhoV0onSOBZPvxVMGRNBJkpX3CEsUz30JsI07toHgrcXeJiN9OQm+ZuN3n8FzdAgOx+2kD2ek9s x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR18MB0958; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:MWHPR18MB0958; BCL:0; PCL:0; RULEID:; SRVR:MWHPR18MB0958; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(24454002)(189002)(377454003)(11100500001)(5002640100001)(97736004)(110136003)(8936002)(7696004)(189998001)(87936001)(10400500002)(5660300001)(586003)(15975445007)(3846002)(6116002)(102836003)(66066001)(2900100001)(76576001)(77096005)(2906002)(86362001)(8676002)(3660700001)(33656002)(4326007)(122556002)(81166006)(81156014)(3280700002)(19580395003)(19580405001)(54356999)(50986999)(76176999)(101416001)(7846002)(7736002)(305945005)(92566002)(74316002)(68736007)(106356001)(2950100002)(9686002)(99286002)(6916009)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR18MB0958; H:MWHPR18MB0960.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: viavisolutions.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: viavisolutions.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 20:13:09.2752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c44ec86f-d007-4b6c-8795-8ea75e4a6f9b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR18MB0958 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Data type for Option/Value X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:13:13 -0000 Juergen, The reason we want to pass structured data is because we have tests that de= fine hundreds of network paths, and each network path is defined by a group= of parameters. The example in appendix G is good for defining one network= path but does not scale to multiple since it only supports the definition = of one src/dest pair. TWAMP is one example of a test that takes multiple network paths. It has Y= ANG models defined for it:=20 https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01 https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-03 Which model is used depends on whether the network path requires special se= tup steps. A single test could then consist of one or both of these models= . For these reasons we are using one LMAP id/value option for each of the TWA= MP models above. The example in appendix G requires an extension of the LMAP model. While I= can see that it is a nice way of combining the two models, my understandin= g is LMAP was trying to prevent the need for customer extensions, especiall= y in this situation where two well-known models are used. The Appendix F example seems to define the new objects for use both within = action/parameter and action/object. If that understanding is correct, can = you explain the difference between using them in the two places? I didn't = see anything in the information model document (version 11) that explained = this. Ron -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 07, 2016 2:24 PM To: Ron Stana Cc: lmap@ietf.org; alissa@cooperw.in Subject: Re: [lmap] Data type for Option/Value On Tue, Sep 27, 2016 at 09:24:34PM +0000, Ron Stana wrote: > LMAP Team, >=20 > The data type for the option/value in the LMAP YANG model is currently de= fined as a string. Our tests use a structured set of input parameters, som= etimes mandated by IETF YANG models such as TWAMP and TWAMP Light (see exam= ple below) so we currently have to stringify the data which makes it unnece= ssarily hard to read and requires an extra step before sending and parsing. >=20 > "action":[ >=20 > { >=20 > "name":"Test-2016-09-27-16:54-action", >=20 > "task":"twamp-initiator", >=20 > "option":[ >=20 > { >=20 > "id":"twamp-light", >=20 > "value":"{\"ietf-twamp-light:twamp-light\":{\"twamp-l= ight-session-sender\":{\"sender-light-enable\":true,\"test-session\":[{\"se= ssion-id\":1,\"test-session-enable\":true,\"packet-padding-size\":425,\"ses= sion-authentication-mode\":\"unauthenticated\",\"interval\":10,\"sender-ip\= ":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.2= 0\",\"reflector-udp-port\":50000,\"dscp\":0},{\"session-id\":2,\"test-sessi= on-enable\":true,\"packet-padding-size\":41,\"session-authentication-mode\"= :\"unauthenticated\",\"interval\":20,\"sender-ip\":\"192.168.2.10\",\"sende= r-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\"= :50000,\"dscp\":8}]}}}" >=20 > } >=20 > ], Why do you encode all twamp-light options in a single lmap task option? >=20 > "destination":[ >=20 > "Test-2016-09-27-16:54-results-periodic-pm", >=20 > "Test-2016-09-27-16:54-results-periodic-rt" >=20 > ] >=20 > } >=20 > ] >=20 >=20 >=20 > Can the value object be changed in the LMAP YANG model so that it can con= tain another object (i.e. YANG's anyxml object type)? > Please take a look at appendix G of draft-ietf-lmap-yang-05.txt for a possi= ble way to do this if plain name/value pairs are not good enough. Using anydata makes the data really opaque. But the most important aspect, = I think, is that LMAP YANG module provides the proper hooks to enable futur= e extensions (via the parameters container). /js PS: Note that options are automatically submitted with result reports; we should make sure that added structured parameters are also contained in result reports (anydata may work generically here since the format is implicitely defined). --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 06:42:01 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA81296CF for ; Mon, 10 Oct 2016 06:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdNctx3QRF_W for ; Mon, 10 Oct 2016 06:41:58 -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 EB2501296CC for ; Mon, 10 Oct 2016 06:41:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4E2736D5; Mon, 10 Oct 2016 15:41:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NyRSNBRNfZZY; Mon, 10 Oct 2016 15:41:49 +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; Mon, 10 Oct 2016 15:41:55 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66C7220037; Mon, 10 Oct 2016 15:41:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dJGUrUwuc_A5; Mon, 10 Oct 2016 15:41:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD8AC20035; Mon, 10 Oct 2016 15:41:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 84C353CB6A07; Mon, 10 Oct 2016 15:41:52 +0200 (CEST) Date: Mon, 10 Oct 2016 15:41:52 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20161010134152.GB28557@elstar.local> Mail-Followup-To: Ron Stana , "lmap@ietf.org" , "alissa@cooperw.in" References: <20161007182405.GA20761@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Data type for Option/Value X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 13:42:01 -0000 On Fri, Oct 07, 2016 at 08:13:09PM +0000, Ron Stana wrote: > Juergen, > > The reason we want to pass structured data is because we have tests that define hundreds of network paths, and each network path is defined by a group of parameters. The example in appendix G is good for defining one network path but does not scale to multiple since it only supports the definition of one src/dest pair. Ron, I pointed you to the appendix not because the appendix solves your problem but instead it shows how a model can augment model specific parameters into the core LMAP data model. You can make this a list of list of list if there is a need to do this. > TWAMP is one example of a test that takes multiple network paths. It has YANG models defined for it: > https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01 > https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-03 > > Which model is used depends on whether the network path requires special setup steps. A single test could then consist of one or both of these models. > > For these reasons we are using one LMAP id/value option for each of the TWAMP models above. OK. Anyway, if your test requires complex parameters, one option is to write a model augmentation to define the structure of the complex parameters. The other option that you used is to serialize things and put the result into an option. A third option is to have parameters that are opaque anydata. All three options have their pros and cons. If you have alreay TWAMP models, there might be a chance to reuse a grouping if you were to augment the LMAP YANG model. > The example in appendix G requires an extension of the LMAP model. While I can see that it is a nice way of combining the two models, my understanding is LMAP was trying to prevent the need for customer extensions, especially in this situation where two well-known models are used. There are trade-offs. If you serialize complex structures into string option values, then any LMAP implementation will be able to move these options around. Of course, this requires some additional serialization and non-sense input will likely be detected only at test run-time. If you augment the model, you of course require implementations to support the augmentation but then you get the benefit of data validation etc. > The Appendix F example seems to define the new objects for use both within action/parameter and action/object. If that understanding is correct, can you explain the difference between using them in the two places? I didn't see anything in the information model document (version 11) that explained this. > The augmentation only adds something to parameters of an action object. It is actually missing a second augmentation that is needed in order to ship the parameters in reports back to the collector. The information model is silent about this kind of extensibility, which I think is OK, unless we want to make this a first class property of the information model itself. I added parameters essentially as a hook we might use when it turns out to be needed. (And there should be a second matching hook for the report model.) /js > Ron > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 07, 2016 2:24 PM > To: Ron Stana > Cc: lmap@ietf.org; alissa@cooperw.in > Subject: Re: [lmap] Data type for Option/Value > > On Tue, Sep 27, 2016 at 09:24:34PM +0000, Ron Stana wrote: > > LMAP Team, > > > > The data type for the option/value in the LMAP YANG model is currently defined as a string. Our tests use a structured set of input parameters, sometimes mandated by IETF YANG models such as TWAMP and TWAMP Light (see example below) so we currently have to stringify the data which makes it unnecessarily hard to read and requires an extra step before sending and parsing. > > > > "action":[ > > > > { > > > > "name":"Test-2016-09-27-16:54-action", > > > > "task":"twamp-initiator", > > > > "option":[ > > > > { > > > > "id":"twamp-light", > > > > "value":"{\"ietf-twamp-light:twamp-light\":{\"twamp-light-session-sender\":{\"sender-light-enable\":true,\"test-session\":[{\"session-id\":1,\"test-session-enable\":true,\"packet-padding-size\":425,\"session-authentication-mode\":\"unauthenticated\",\"interval\":10,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":0},{\"session-id\":2,\"test-session-enable\":true,\"packet-padding-size\":41,\"session-authentication-mode\":\"unauthenticated\",\"interval\":20,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":8}]}}}" > > > > } > > > > ], > > Why do you encode all twamp-light options in a single lmap task option? > > > > > "destination":[ > > > > "Test-2016-09-27-16:54-results-periodic-pm", > > > > "Test-2016-09-27-16:54-results-periodic-rt" > > > > ] > > > > } > > > > ] > > > > > > > > Can the value object be changed in the LMAP YANG model so that it can contain another object (i.e. YANG's anyxml object type)? > > > > Please take a look at appendix G of draft-ietf-lmap-yang-05.txt for a possible way to do this if plain name/value pairs are not good enough. > Using anydata makes the data really opaque. But the most important aspect, I think, is that LMAP YANG module provides the proper hooks to enable future extensions (via the parameters container). > > /js > > PS: Note that options are automatically submitted with result reports; > we should make sure that added structured parameters are also > contained in result reports (anydata may work generically here > since the format is implicitely defined). > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 10:28:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89AC12975B; Mon, 10 Oct 2016 10:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekjj2_f7BhZJ; Mon, 10 Oct 2016 10:28:08 -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 1DEB212975F; Mon, 10 Oct 2016 10:28:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F10E39D4; Mon, 10 Oct 2016 19:28:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UvPTA6-TH5Ol; Mon, 10 Oct 2016 19:27:55 +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; Mon, 10 Oct 2016 19:28:02 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F02422003A; Mon, 10 Oct 2016 19:28:01 +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 BTaAi2TE2OY5; Mon, 10 Oct 2016 19:28:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7C1620037; Mon, 10 Oct 2016 19:28:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D006C3CB7305; Mon, 10 Oct 2016 19:27:59 +0200 (CEST) Date: Mon, 10 Oct 2016 19:27:59 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161010172759.GA29411@elstar.local> Mail-Followup-To: Martin Bjorklund , draft-ietf-lmap-yang.all@ietf.org, yang-doctors@ietf.org, lmap@ietf.org References: <20160823.144636.1796310931546236457.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160823.144636.1796310931546236457.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: yang-doctors@ietf.org, lmap@ietf.org, draft-ietf-lmap-yang.all@ietf.org Subject: Re: [lmap] YANG doctor review of draft-ietf-lmap-yang-05 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:28:13 -0000 Martin, thanks for your review. See my response inline. I am also adding the LMAP WG to this thread. On Tue, Aug 23, 2016 at 02:46:36PM +0200, Martin Bjorklund wrote: > Hi, > > I am the assigned YANG doctor for this document. I have reviewed this > document from a pure YANG standpoint. I have not checked that the > YANG model matches the information model etc. > > As expected, this model is in good shape. Here are my comments: > > > o The typedef glob-pattern use \ in a double qouted string. > Specifically, it uses the characters \\ which actually expand to a > single '\'. Also in YANG 1.1 the sequences \* and \? are illegal. > > I suggest this text is re-written to avoid backslahses, or that a > single quote string is used. Changed the description statement to use a single quoted string. > o The device-id is of type inet:uri. I see that this is specified in > the information model as well. But why is it a URI? As an > operator, which URI should I choose? The information model says this is configurable but frankly this does not seem to make much sense. I think this really should be a read-only state object and not a configurable object. Need to check this with the LMAP WG. The URI value itself does not really matter, any URI that provides a reasonably stable and unique identification is good enough. Note that the entity (aka hardware) YANG model has a similar URI. How to implement this? It could be a urn:uuid or urn:clei or something else. There once was an I-D proposing a URN namespace for device identifiers but this seems to have stalled (unfortunately). I think the entity (aka hardware) model also leaves it open what kind of URIs are used to identify hardware components so I think we are fine to leave this open as well. (See also below for some further comments.) > o lmap/agent/device-id's description says: > > The device-id identifies a property of the > device running the measurement agent. > > Should this be s/a property of//? Otherwise, which property is > being referred to? Yes, removed the property text. > o lmap-state/agent/device-id is marked as 'mandatory true', but its > description says that is optional. This is a good catch. I removed mandatory for now. The bigger issue, however, is that in the information model certain elements are marked as optional because of security concerns while in the YANG module I would find it more natural to make these objects mandatory and leave it to an access control model to suppress access to sensitive leafs. Right now, the design strictly follows the information model but it kind of feels wrong to say in the definition of a YANG leaf that it is _optional to implement_ given the security requirements different _deployments_ may have. I would propose to the WG to make these objects mandatory in YANG and to move text concerning their sensitivity to the security considerations section. Need to check this with the LMAP WG. > o lmap/agent/controller-timeout says that "an event is raised". What > kind of event? Which protocol? [later] Ok, reading the events > subtree, I see that there is an event 'controller-lost' there. > Presumably the text refers to this event. If so, this text could > maybe be clarified. I have changed this to 'an event (controller-lost) is raised' so that readers can easily search for the event definition. > o The descriptions in several nodes in > /lmap/events/event/event-type/calendar are a bit confusing: > > leaf-list month { > type lmap:month-or-all; > min-elements 1; > description > "A month at which this calendar timing will > trigger. The wildcard means all months."; > > The description says "_A_ month", but the node is a leaf-list. > Maybe change to "A set of months". (same for other nodes in this > case as well) Yes, I could not make up my mind whether the description describes an element of the set or the set as a whole - and I think I have not been consistent with this either. I will change all leaf-list descriptions so that they describe the set as a whole. > o /lmap/tasks/task/program is optional (and marked as > nacm:default-deny-write). > > What happens if this leaf is not set? The idea is that you can do without identifying a program if the agent can map the registry URIs to a suitable program. In a pure registry-driven implementation, you would configure the measurement you want to run by pointing to a registry entry and then the system decides locally which program to execute (i.e., a controller does not need to know the internal software structure on the device). I will add: [...] If this leaf is not set, then the system will try to identify a suitable program based on the registry information present." > o Are /lmap-state/agent/{hardware,firmware} different than > /system-state/platform/{machine,os-release/os-version} in > ietf-system? They overlap. One option is to remove these two objects and instead add language to section 3 pointing to the relevant portions of the system model. If we go this route (and also conclude that the device-id is indeed read-only), we might drop the device-id as well (since it will be covered by the entity (aka hardware) model. Need to check this with the LMAP WG. > o So the MA is supposed to invoke RPCs on a controller. Is this > described somewhere? Are the details left to implementations? This is actually stated in section 3 o Reporting Information: This is modeled by the report data model to be implemented by the Collector. Measurement Agents send results to the Collector via an RPC operation. and the ietf-lmap-report module description "This module defines a data model for reporting results from measurement agents, which are part of a Large-Scale Measurement expected to be implemented by a collector."; but perhaps this just does not stand out enough. Perhaps add a more explicit overview figure? +------------------------+ | LMAP Controller | | | | Client: | | ietf-lmap-comman.yang | | ietf-lmap-control.yang | +------------------------+ +------------------------+ | | LMAP Measurement Agent | | | | <- request | | Server: |<---------------------' | ietf-lmap-comman.yang | response -> | ietf-lmap-control.yang | | | | | request -> | Client: |----------------------. | ietf-lmap-comman.yang | <- response | | ietf-lmap-report.yang | | +------------------------+ v +------------------------+ | LMAP Collector | | | | Server: | | ietf-lmap-comman.yang | | ietf-lmap-report.yang | +------------------------+ I tend to agree that the Introduction section is perhaps a bit terse. /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 Mon Oct 10 10:33:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747E9129573 for ; Mon, 10 Oct 2016 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkTTZTt2dHu6 for ; Mon, 10 Oct 2016 10:33:23 -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 DF5D7129758 for ; Mon, 10 Oct 2016 10:33: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 ACDD9E4D for ; Mon, 10 Oct 2016 19:33:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OjlFc7ZAKQcY for ; Mon, 10 Oct 2016 19:33:15 +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 ; Mon, 10 Oct 2016 19:33:21 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBB120038 for ; Mon, 10 Oct 2016 19:33:21 +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 1KHpbTisiLaF; Mon, 10 Oct 2016 19:33:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 163CF20037; Mon, 10 Oct 2016 19:33:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0BCE03CB7354; Mon, 10 Oct 2016 19:33:21 +0200 (CEST) Date: Mon, 10 Oct 2016 19:33:20 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20161010173320.GB29411@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:33:25 -0000 Hi, while going through Martin's review comments for the YANG model, the question came up why the device-id in the information model is configurable. Would it not be sufficient if there is a read-only device-id? Right now, the information model have a device-id in both the ma-preconfig-obj and the ma-config-obj. In addition, we have a device-id in the ma-status-obj and it seems to me the having it only in the ma-status-obj would be enough. /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 Mon Oct 10 10:36:02 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477D3129579 for ; Mon, 10 Oct 2016 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEE4DS54b69b for ; Mon, 10 Oct 2016 10:35:57 -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 65E5A12956E for ; Mon, 10 Oct 2016 10:35:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 35628E4D for ; Mon, 10 Oct 2016 19:35:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MibnUJ4znEjj for ; Mon, 10 Oct 2016 19:35:49 +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 ; Mon, 10 Oct 2016 19:35:56 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB96720038 for ; Mon, 10 Oct 2016 19:35:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fm02pVxnu9lV; Mon, 10 Oct 2016 19:35:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80E2820037; Mon, 10 Oct 2016 19:35:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 73DBB3CB7397; Mon, 10 Oct 2016 19:35:55 +0200 (CEST) Date: Mon, 10 Oct 2016 19:35:55 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20161010173555.GC29411@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] hardware, firmware, device-id overlap with system and entity objects X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:35:59 -0000 Hi, in the YANG model, /lmap-state/agent/{hardware,firmware,device-id} overlap with /system-state/platform/{machine,os-release/os-version} and the upcoming entity (aka hardware) model provide a URI for hardware components. Shall we remove the {hardware,firmware,device-id} objects and instead add text to section 3 pointing to the places where these objects can be found? /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 Mon Oct 10 10:38:20 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8C2129583 for ; Mon, 10 Oct 2016 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0NrMWnunI7z for ; Mon, 10 Oct 2016 10:38:18 -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 C9B7C129573 for ; Mon, 10 Oct 2016 10:38:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 99DF76B3 for ; Mon, 10 Oct 2016 19:38:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1A3tVyhOR6VR for ; Mon, 10 Oct 2016 19:38:10 +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 ; Mon, 10 Oct 2016 19:38:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60DF120038 for ; Mon, 10 Oct 2016 19:38:16 +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 VGhLJynFBnbo; Mon, 10 Oct 2016 19:38:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CFD220037; Mon, 10 Oct 2016 19:38:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 25BFE3CB73DD; Mon, 10 Oct 2016 19:38:16 +0200 (CEST) Date: Mon, 10 Oct 2016 19:38:16 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20161010173816.GD29411@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:38:19 -0000 Hi, some objects in the information model (e.g., agent-id) are marked optional because of sensitivity considerations. Since there is an access control model for NETCONF (and RESTCONF), it would feel more natural to make these objects mandatory in YANG and leave it to the access control model to prevent access to them in deployments where this is needed. /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 Mon Oct 10 10:52:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A820312958C for ; Mon, 10 Oct 2016 10:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6oijPgmHgMt for ; Mon, 10 Oct 2016 10:52:34 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 AB7A7129471 for ; Mon, 10 Oct 2016 10:52:34 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 2091D166F0605; Mon, 10 Oct 2016 17:52:31 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AHqWuU028731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 17:52:33 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9AHqWoS013844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 17:52:32 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 13:52:32 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTA Date: Mon, 10 Oct 2016 17:52:33 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> In-Reply-To: <20161010173320.GB29411@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:52:37 -0000 Juergen, I believe it was because the LMAP controller wanted to control the id assig= ned to the device in the setup of the agent. It went along with the group i= dentifier and UUID of the measurement agent. In the TR-069 we already have this attribute as part of the base TR-181 dat= a model so removing it from the configuration aspect and leaving it for sta= tus is perfectly fine for us. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 12:33 PM To: lmap@ietf.org Subject: [lmap] why do we have a configurable device-id in the information = model? Hi, while going through Martin's review comments for the YANG model, the questi= on came up why the device-id in the information model is configurable. Woul= d it not be sufficient if there is a read-only device-id? Right now, the information model have a device-id in both the ma-preconfig-= obj and the ma-config-obj. In addition, we have a device-id in the ma-statu= s-obj and it seems to me the having it only in the ma-status-obj would be e= nough. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 12:12:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6012956C for ; Mon, 10 Oct 2016 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqWcbuJ9PnED for ; Mon, 10 Oct 2016 12:12:42 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 8300A129543 for ; Mon, 10 Oct 2016 12:12:42 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id E268114D4BFB4; Mon, 10 Oct 2016 19:12:38 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AJCe4h014117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 19:12:41 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u9AJCeLm018408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 19:12:40 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 15:12:40 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQ Date: Mon, 10 Oct 2016 19:12:42 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> In-Reply-To: <20161010173816.GD29411@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:12:44 -0000 Juergen, The agent id in the report is between the agent and the data collector - It= 's a privacy issue where the agent id was not to be even transmitted if the= report-agent-id was false. Does the access control model allow these kinds of checks for presence of f= ields to be transmitted.=20 Authorization for access (CRUD) is different than even transmitting the fie= ld (or value in the field depending on your protocol). BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 12:38 PM To: lmap@ietf.org Subject: [lmap] optional leafs due to sensitity concerns Hi, some objects in the information model (e.g., agent-id) are marked optional = because of sensitivity considerations. Since there is an access control mod= el for NETCONF (and RESTCONF), it would feel more natural to make these obj= ects mandatory in YANG and leave it to the access control model to prevent = access to them in deployments where this is needed. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 12:45:41 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA54129435 for ; Mon, 10 Oct 2016 12:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLm7BrqK3yS2 for ; Mon, 10 Oct 2016 12:45:38 -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 0211212945C for ; Mon, 10 Oct 2016 12:45:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5F1ECE4F; Mon, 10 Oct 2016 21:45:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1UP4ExooPCqJ; Mon, 10 Oct 2016 21:45:29 +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; Mon, 10 Oct 2016 21:45:35 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE8B620038; Mon, 10 Oct 2016 21:45:35 +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 mY4f7RtFt-gV; Mon, 10 Oct 2016 21:45:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50E0020037; Mon, 10 Oct 2016 21:45:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 72CFF3CB7C3A; Mon, 10 Oct 2016 21:45:34 +0200 (CEST) Date: Mon, 10 Oct 2016 21:45:34 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161010194533.GA31698@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:45:40 -0000 Tim, I agree, the agent-id is not a problem since we do have an explicit control whether this is included in a report. I actually stumbled about similar text (which might be a copy and paste error) for the configurable device-id but if we end up removing the configurable device-id (see other thread), then this becomes a mood point. Looking at leaf report-agent-id, I see: description "The 'report-agent-id' controls whether the 'agent-id' is reported to collectors if the 'group-id' is configured. If the 'group-id' is not configured, the agent-id is always reported."; This seems weird since removing a group-id suddenly exposes an agent-id. I kind of dislike such side-effects. Checking the information model, I see: ma-config-report-agent-id: An optional flag indicating whether the identifier (ma- config-agent-id) should be included in reports. The default value is false. This seems to be simpler and hence I suggest to remove the last sentence from the description of the report-agent-id. On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > The agent id in the report is between the agent and the data collector - It's a privacy issue where the agent id was not to be even transmitted if the report-agent-id was false. > > Does the access control model allow these kinds of checks for presence of fields to be transmitted. > > Authorization for access (CRUD) is different than even transmitting the field (or value in the field depending on your protocol). > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 12:38 PM > To: lmap@ietf.org > Subject: [lmap] optional leafs due to sensitity concerns > > Hi, > > some objects in the information model (e.g., agent-id) are marked optional because of sensitivity considerations. Since there is an access control model for NETCONF (and RESTCONF), it would feel more natural to make these objects mandatory in YANG and leave it to the access control model to prevent access to them in deployments where this is needed. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 12:57:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36302129508 for ; Mon, 10 Oct 2016 12:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwhlp8bv2UyQ for ; Mon, 10 Oct 2016 12:56:57 -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 44F3D1294C5 for ; Mon, 10 Oct 2016 12:56:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 11437B72; Mon, 10 Oct 2016 21:56:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zFlHsN4K-wIG; Mon, 10 Oct 2016 21:56:49 +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; Mon, 10 Oct 2016 21:56:55 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F07B20038; Mon, 10 Oct 2016 21:56:55 +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 jZLD_QVjENGh; Mon, 10 Oct 2016 21:56:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E122020037; Mon, 10 Oct 2016 21:56:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DACBE3CB7CAC; Mon, 10 Oct 2016 21:56:54 +0200 (CEST) Date: Mon, 10 Oct 2016 21:56:54 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161010195654.GB31698@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:56:59 -0000 Tim, I think the Controller is simply not in charge to define a device-id. The playground for the Controller is the LMAP agent-id, not any global device-ids. Or perhaps the device-id was not meant to be a global device-id but rather an LMAP specific device-id. But then, what is the use case for this, given that we have an agent-id? So I am checking RFC 7594 and it mentions a device identifier as part of the bootstrapping process: As a result of the Bootstrapping process, the MA learns the following information ([LMAP-INFO] defines the consequent list of information elements): o its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses or both. o (optionally) a Group-ID, shared by several MAs and could be useful for privacy reasons. For instance, reporting the Group-ID and not the MA-ID could hinder tracking of a mobile device. I did not find any other reference to a device identifier in RFC 7594. So unless someone speaks up soon for keeping the device-id in the ma-preconfig-obj and ma-config-obj, I will remove it from the ma-preconfig-obj and ma-config-obj. On Mon, Oct 10, 2016 at 05:52:33PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I believe it was because the LMAP controller wanted to control the id assigned to the device in the setup of the agent. It went along with the group identifier and UUID of the measurement agent. > > In the TR-069 we already have this attribute as part of the base TR-181 data model so removing it from the configuration aspect and leaving it for status is perfectly fine for us. > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 12:33 PM > To: lmap@ietf.org > Subject: [lmap] why do we have a configurable device-id in the information model? > > Hi, > > while going through Martin's review comments for the YANG model, the question came up why the device-id in the information model is configurable. Would it not be sufficient if there is a read-only device-id? > > Right now, the information model have a device-id in both the ma-preconfig-obj and the ma-config-obj. In addition, we have a device-id in the ma-status-obj and it seems to me the having it only in the ma-status-obj would be enough. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:01:04 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7E812956A for ; Mon, 10 Oct 2016 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Kby3oans2o for ; Mon, 10 Oct 2016 13:01:01 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 8951612945C for ; Mon, 10 Oct 2016 13:01:01 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id D372267AA2431; Mon, 10 Oct 2016 20:00:57 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AK0xKm023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 20:01:00 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u9AK0x5j004739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 20:00:59 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:00:59 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsA== Date: Mon, 10 Oct 2016 20:00:58 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> In-Reply-To: <20161010194533.GA31698@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:01:03 -0000 Juergen In the information model - the text in section 3.2 says: Where the Measurement Group ID is set an additional flag (the Report MA ID flag) is required to control whether the Measurement Agent ID is also to be reported. The reporting of a Group ID without the MA ID allows the MA to remain anonymous, which may be particularly useful to prevent tracking of mobile MA devices. So yes - we will report a MA ID if there is no Group ID or when the Group I= D exists and the report MA ID is false. So the group id allows the capability for MA ID to remain anonymous. The fe= ature is invoked by setting the report MA ID field to false. What has to happen is worst case either a Group ID or MA ID is always repor= ted. Sometimes both will be reported. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 2:46 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] optional leafs due to sensitity concerns Tim, I agree, the agent-id is not a problem since we do have an explicit control= whether this is included in a report. I actually stumbled about similar te= xt (which might be a copy and paste error) for the configurable device-id b= ut if we end up removing the configurable device-id (see other thread), the= n this becomes a mood point. Looking at leaf report-agent-id, I see: description "The 'report-agent-id' controls whether the 'agent-id' is reported to collectors if the 'group-id' is configured. If the 'group-id' is not configured, the agent-id is always reported."; This seems weird since removing a group-id suddenly exposes an agent-id. I = kind of dislike such side-effects. Checking the information model, I see: ma-config-report-agent-id: An optional flag indicating whether the identifier (ma- config-agent-id) should be included in reports. The default value is false. This seems to be simpler and hence I suggest to remove the last sentence fr= om the description of the report-agent-id. On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, > The agent id in the report is between the agent and the data collector - = It's a privacy issue where the agent id was not to be even transmitted if t= he report-agent-id was false. >=20 > Does the access control model allow these kinds of checks for presence of= fields to be transmitted.=20 >=20 > Authorization for access (CRUD) is different than even transmitting the f= ield (or value in the field depending on your protocol). >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 12:38 PM > To: lmap@ietf.org > Subject: [lmap] optional leafs due to sensitity concerns >=20 > Hi, >=20 > some objects in the information model (e.g., agent-id) are marked optiona= l because of sensitivity considerations. Since there is an access control m= odel for NETCONF (and RESTCONF), it would feel more natural to make these o= bjects mandatory in YANG and leave it to the access control model to preven= t access to them in deployments where this is needed. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:18:21 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540AD129752 for ; Mon, 10 Oct 2016 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeCJU7hNFLsi for ; Mon, 10 Oct 2016 13:18:18 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 AC094129503 for ; Mon, 10 Oct 2016 13:18:18 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id D3E0950DE047D; Mon, 10 Oct 2016 20:18:14 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AKIHGG027788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 20:18:17 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9AKIH14001907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 20:18:17 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:18:17 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8A== Date: Mon, 10 Oct 2016 20:18:15 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> In-Reply-To: <20161010195654.GB31698@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:18:20 -0000 Juergen, You are correct this is used the MA preconfiguration where the device ident= ifier is set. So it really should be removed from the configuration object - I don't thin= k you can set it after preconfiguration. And if you want to change it - that should be outside the scope of LMAP. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 2:57 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? Tim, I think the Controller is simply not in charge to define a device-id. The playground for the Controller is the LMAP agent-id, not any global devi= ce-ids. Or perhaps the device-id was not meant to be a global device-id but= rather an LMAP specific device-id. But then, what is the use case for this= , given that we have an agent-id? So I am checking RFC 7594 and it mentions a device identifier as part of th= e bootstrapping process: As a result of the Bootstrapping process, the MA learns the following information ([LMAP-INFO] defines the consequent list of information elements): o its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses or both. o (optionally) a Group-ID, shared by several MAs and could be useful for privacy reasons. For instance, reporting the Group-ID and not the MA-ID could hinder tracking of a mobile device. I did not find any other reference to a device identifier in RFC 7594. So unless someone speaks up soon for keeping the device-id in the ma-precon= fig-obj and ma-config-obj, I will remove it from the ma-preconfig-obj and m= a-config-obj. On Mon, Oct 10, 2016 at 05:52:33PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I believe it was because the LMAP controller wanted to control the id ass= igned to the device in the setup of the agent. It went along with the group= identifier and UUID of the measurement agent. >=20 > In the TR-069 we already have this attribute as part of the base TR-181 d= ata model so removing it from the configuration aspect and leaving it for s= tatus is perfectly fine for us. >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 12:33 PM > To: lmap@ietf.org > Subject: [lmap] why do we have a configurable device-id in the informatio= n model? >=20 > Hi, >=20 > while going through Martin's review comments for the YANG model, the ques= tion came up why the device-id in the information model is configurable. Wo= uld it not be sufficient if there is a read-only device-id? >=20 > Right now, the information model have a device-id in both the ma-preconfi= g-obj and the ma-config-obj. In addition, we have a device-id in the ma-sta= tus-obj and it seems to me the having it only in the ma-status-obj would be= enough. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:22:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80531295BA for ; Mon, 10 Oct 2016 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81YD5QXsOhJH for ; Mon, 10 Oct 2016 13:22:21 -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 DA0E6129493 for ; Mon, 10 Oct 2016 13:22:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A51EA7DE; Mon, 10 Oct 2016 22:22:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oUK-hUkj8M9A; Mon, 10 Oct 2016 22:22:12 +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; Mon, 10 Oct 2016 22:22:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D22B920038; Mon, 10 Oct 2016 22:22:18 +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 T64iE0_B-oVE; Mon, 10 Oct 2016 22:22:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 148C120037; Mon, 10 Oct 2016 22:22:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C5DD3CB7E9B; Mon, 10 Oct 2016 22:22:18 +0200 (CEST) Date: Mon, 10 Oct 2016 22:22:17 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161010202217.GA31876@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:22:23 -0000 On Mon, Oct 10, 2016 at 08:00:58PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen > > In the information model - the text in section 3.2 says: > Where the Measurement Group ID is set > an additional flag (the Report MA ID flag) is required to control > whether the Measurement Agent ID is also to be reported. The > reporting of a Group ID without the MA ID allows the MA to remain > anonymous, which may be particularly useful to prevent tracking of > mobile MA devices. > > So yes - we will report a MA ID if there is no Group ID or when the Group ID exists and the report MA ID is false. > OK. But why? Why is the flag to suppress the agent id only relevant if there is a group id? Isn't it confusing if one sets report-agent-id to 'false' but the agent continues to report agent-ids until there is finally a group-id set? I think this is a real surprise for someone who has not read the fine print. I think the design would be simpler and less surprising if the report-agent-id would always enable/disable the reporting of the agent-id. (And yes, if you set report-agent-id to false and you do not set a group-id, you get a pretty anonymous report. But I think this is better than sending the agent-id even though the report-agent-id is false.) > So the group id allows the capability for MA ID to remain anonymous. The feature is invoked by setting the report MA ID field to false. > What has to happen is worst case either a Group ID or MA ID is always reported. Sometimes both will be reported. The worst case is someone setting report-agent-id to false and the MA still sending the agent-id just because a group-id is missing. I think this design kind of violates the principle of least astonishment. /js > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 2:46 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns > > Tim, > > I agree, the agent-id is not a problem since we do have an explicit control whether this is included in a report. I actually stumbled about similar text (which might be a copy and paste error) for the configurable device-id but if we end up removing the configurable device-id (see other thread), then this becomes a mood point. > > Looking at leaf report-agent-id, I see: > > description > "The 'report-agent-id' controls whether the > 'agent-id' is reported to collectors if the > 'group-id' is configured. If the 'group-id' > is not configured, the agent-id is always > reported."; > > This seems weird since removing a group-id suddenly exposes an agent-id. I kind of dislike such side-effects. Checking the information model, I see: > > ma-config-report-agent-id: An optional flag indicating > whether the identifier (ma- > config-agent-id) should be > included in reports. The default > value is false. > > This seems to be simpler and hence I suggest to remove the last sentence from the description of the report-agent-id. > > On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > The agent id in the report is between the agent and the data collector - It's a privacy issue where the agent id was not to be even transmitted if the report-agent-id was false. > > > > Does the access control model allow these kinds of checks for presence of fields to be transmitted. > > > > Authorization for access (CRUD) is different than even transmitting the field (or value in the field depending on your protocol). > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 12:38 PM > > To: lmap@ietf.org > > Subject: [lmap] optional leafs due to sensitity concerns > > > > Hi, > > > > some objects in the information model (e.g., agent-id) are marked optional because of sensitivity considerations. Since there is an access control model for NETCONF (and RESTCONF), it would feel more natural to make these objects mandatory in YANG and leave it to the access control model to prevent access to them in deployments where this is needed. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:27:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CF9129742 for ; Mon, 10 Oct 2016 13:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQk-Ks-lK4xl for ; Mon, 10 Oct 2016 13:27:31 -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 EAC6F1295BA for ; Mon, 10 Oct 2016 13:27:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B633BE4D; Mon, 10 Oct 2016 22:27:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uira4wObWRXu; Mon, 10 Oct 2016 22:27:22 +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; Mon, 10 Oct 2016 22:27:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ED822003A; Mon, 10 Oct 2016 22:27:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iSTVGnrCMm9O; Mon, 10 Oct 2016 22:27:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A4AA20038; Mon, 10 Oct 2016 22:27:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82A7A3CB7EE9; Mon, 10 Oct 2016 22:27:27 +0200 (CEST) Date: Mon, 10 Oct 2016 22:27:27 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161010202727.GB31876@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:27:33 -0000 Tim, I would remove it also from the ma-preconfig-obj. I think that the LMAP controller learns the device-id from the device during the bootstrapping process, not the other way round. The LMAP controller is in my view not the entity to configure or bootstrap device-ids. I think this is actually a bug in RFC 7594. (Unless there is a very special LMAP specific usage of this ID, which I did not manage to find.) /js On Mon, Oct 10, 2016 at 08:18:15PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > You are correct this is used the MA preconfiguration where the device identifier is set. > So it really should be removed from the configuration object - I don't think you can set it after preconfiguration. > And if you want to change it - that should be outside the scope of LMAP. > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 2:57 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the information model? > > Tim, > > I think the Controller is simply not in charge to define a device-id. > The playground for the Controller is the LMAP agent-id, not any global device-ids. Or perhaps the device-id was not meant to be a global device-id but rather an LMAP specific device-id. But then, what is the use case for this, given that we have an agent-id? > > So I am checking RFC 7594 and it mentions a device identifier as part of the bootstrapping process: > > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): > > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. > > o (optionally) a Group-ID, shared by several MAs and could be useful > for privacy reasons. For instance, reporting the Group-ID and not > the MA-ID could hinder tracking of a mobile device. > > I did not find any other reference to a device identifier in RFC 7594. > So unless someone speaks up soon for keeping the device-id in the ma-preconfig-obj and ma-config-obj, I will remove it from the ma-preconfig-obj and ma-config-obj. > > On Mon, Oct 10, 2016 at 05:52:33PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > I believe it was because the LMAP controller wanted to control the id assigned to the device in the setup of the agent. It went along with the group identifier and UUID of the measurement agent. > > > > In the TR-069 we already have this attribute as part of the base TR-181 data model so removing it from the configuration aspect and leaving it for status is perfectly fine for us. > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 12:33 PM > > To: lmap@ietf.org > > Subject: [lmap] why do we have a configurable device-id in the information model? > > > > Hi, > > > > while going through Martin's review comments for the YANG model, the question came up why the device-id in the information model is configurable. Would it not be sufficient if there is a read-only device-id? > > > > Right now, the information model have a device-id in both the ma-preconfig-obj and the ma-config-obj. In addition, we have a device-id in the ma-status-obj and it seems to me the having it only in the ma-status-obj would be enough. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:28:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D0129777 for ; Mon, 10 Oct 2016 13:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYDmFp0lhrRA for ; Mon, 10 Oct 2016 13:28:21 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 86E0F1295BA for ; Mon, 10 Oct 2016 13:28:21 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id B898DA233CDD3; Mon, 10 Oct 2016 20:28:17 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AKSKH2012466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 20:28:20 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u9AKSJ8U003723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 20:28:19 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:28:19 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4A= Date: Mon, 10 Oct 2016 20:28:18 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> In-Reply-To: <20161010202217.GA31876@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:28:24 -0000 Juergen, I think it is because they want at least one or the other reported. Such th= at an anonymous agent would still have a group id to associate the results. Yes indeed this rule can be easily misinterpreted - I guess we ought to hav= e clarifying text in the descriptions in the reporting - maybe the attribut= e should be named report-agent-id-with-group? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 3:22 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] optional leafs due to sensitity concerns On Mon, Oct 10, 2016 at 08:00:58PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen >=20 > In the information model - the text in section 3.2 says: > Where the Measurement Group ID is set > an additional flag (the Report MA ID flag) is required to control=20 > whether the Measurement Agent ID is also to be reported. The reporting=20 > of a Group ID without the MA ID allows the MA to remain anonymous,=20 > which may be particularly useful to prevent tracking of mobile MA=20 > devices. >=20 > So yes - we will report a MA ID if there is no Group ID or when the Group= ID exists and the report MA ID is false. > OK. But why? Why is the flag to suppress the agent id only relevant if ther= e is a group id? Isn't it confusing if one sets report-agent-id to 'false' = but the agent continues to report agent-ids until there is finally a group-= id set? I think this is a real surprise for someone who has not read the fi= ne print. I think the design would be simpler and less surprising if the re= port-agent-id would always enable/disable the reporting of the agent-id. (A= nd yes, if you set report-agent-id to false and you do not set a group-id, = you get a pretty anonymous report. But I think this is better than sending = the agent-id even though the report-agent-id is false.) > So the group id allows the capability for MA ID to remain anonymous. The = feature is invoked by setting the report MA ID field to false. > What has to happen is worst case either a Group ID or MA ID is always rep= orted. Sometimes both will be reported. The worst case is someone setting report-agent-id to false and the MA still= sending the agent-id just because a group-id is missing. I think this desi= gn kind of violates the principle of least astonishment. /js =20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 2:46 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns >=20 > Tim, >=20 > I agree, the agent-id is not a problem since we do have an explicit contr= ol whether this is included in a report. I actually stumbled about similar = text (which might be a copy and paste error) for the configurable device-id= but if we end up removing the configurable device-id (see other thread), t= hen this becomes a mood point. >=20 > Looking at leaf report-agent-id, I see: >=20 > description > "The 'report-agent-id' controls whether the > 'agent-id' is reported to collectors if the > 'group-id' is configured. If the 'group-id' > is not configured, the agent-id is always > reported."; >=20 > This seems weird since removing a group-id suddenly exposes an agent-id. = I kind of dislike such side-effects. Checking the information model, I see: >=20 > ma-config-report-agent-id: An optional flag indicating > whether the identifier (ma- > config-agent-id) should be > included in reports. The default > value is false. >=20 > This seems to be simpler and hence I suggest to remove the last sentence = from the description of the report-agent-id. >=20 > On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > > The agent id in the report is between the agent and the data collector = - It's a privacy issue where the agent id was not to be even transmitted if= the report-agent-id was false. > >=20 > > Does the access control model allow these kinds of checks for presence = of fields to be transmitted.=20 > >=20 > > Authorization for access (CRUD) is different than even transmitting the= field (or value in the field depending on your protocol). > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 12:38 PM > > To: lmap@ietf.org > > Subject: [lmap] optional leafs due to sensitity concerns > >=20 > > Hi, > >=20 > > some objects in the information model (e.g., agent-id) are marked optio= nal because of sensitivity considerations. Since there is an access control= model for NETCONF (and RESTCONF), it would feel more natural to make these= objects mandatory in YANG and leave it to the access control model to prev= ent access to them in deployments where this is needed. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > >=20 > >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:36:38 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179631295A8 for ; Mon, 10 Oct 2016 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD7N7o2B0Yl2 for ; Mon, 10 Oct 2016 13:36:34 -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 62E8B1293DB for ; Mon, 10 Oct 2016 13:36:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3B407857; Mon, 10 Oct 2016 22:36:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RQA19SdYjojw; Mon, 10 Oct 2016 22:36:25 +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; Mon, 10 Oct 2016 22:36:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 494AE20038; Mon, 10 Oct 2016 22:36:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Vh10M1SzIlUi; Mon, 10 Oct 2016 22:36:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7014520037; Mon, 10 Oct 2016 22:36:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 659553CB7F61; Mon, 10 Oct 2016 22:36:30 +0200 (CEST) Date: Mon, 10 Oct 2016 22:36:30 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161010203630.GC31876@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:36:37 -0000 Tim, why not simply make the design simpler and at the same time less surprising? BTW, having a report without an agent-id and a group-id is of the same value as a report with just a group-id if all MAs have the same group-id value set. Why would the later be allowed by the model but the former be disallowed by the model? I vote for having report-agent-id as a simple unconditional boolean flag controlling the inclusion of the agent-id in reports. /js On Mon, Oct 10, 2016 at 08:28:18PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I think it is because they want at least one or the other reported. Such that an anonymous agent would still have a group id to associate the results. > Yes indeed this rule can be easily misinterpreted - I guess we ought to have clarifying text in the descriptions in the reporting - maybe the attribute should be named > report-agent-id-with-group? > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 3:22 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns > > On Mon, Oct 10, 2016 at 08:00:58PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen > > > > In the information model - the text in section 3.2 says: > > Where the Measurement Group ID is set > > an additional flag (the Report MA ID flag) is required to control > > whether the Measurement Agent ID is also to be reported. The reporting > > of a Group ID without the MA ID allows the MA to remain anonymous, > > which may be particularly useful to prevent tracking of mobile MA > > devices. > > > > So yes - we will report a MA ID if there is no Group ID or when the Group ID exists and the report MA ID is false. > > > > OK. But why? Why is the flag to suppress the agent id only relevant if there is a group id? Isn't it confusing if one sets report-agent-id to 'false' but the agent continues to report agent-ids until there is finally a group-id set? I think this is a real surprise for someone who has not read the fine print. I think the design would be simpler and less surprising if the report-agent-id would always enable/disable the reporting of the agent-id. (And yes, if you set report-agent-id to false and you do not set a group-id, you get a pretty anonymous report. But I think this is better than sending the agent-id even though the report-agent-id is false.) > > > So the group id allows the capability for MA ID to remain anonymous. The feature is invoked by setting the report MA ID field to false. > > What has to happen is worst case either a Group ID or MA ID is always reported. Sometimes both will be reported. > > The worst case is someone setting report-agent-id to false and the MA still sending the agent-id just because a group-id is missing. I think this design kind of violates the principle of least astonishment. > > /js > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 2:46 PM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > Tim, > > > > I agree, the agent-id is not a problem since we do have an explicit control whether this is included in a report. I actually stumbled about similar text (which might be a copy and paste error) for the configurable device-id but if we end up removing the configurable device-id (see other thread), then this becomes a mood point. > > > > Looking at leaf report-agent-id, I see: > > > > description > > "The 'report-agent-id' controls whether the > > 'agent-id' is reported to collectors if the > > 'group-id' is configured. If the 'group-id' > > is not configured, the agent-id is always > > reported."; > > > > This seems weird since removing a group-id suddenly exposes an agent-id. I kind of dislike such side-effects. Checking the information model, I see: > > > > ma-config-report-agent-id: An optional flag indicating > > whether the identifier (ma- > > config-agent-id) should be > > included in reports. The default > > value is false. > > > > This seems to be simpler and hence I suggest to remove the last sentence from the description of the report-agent-id. > > > > On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wrote: > > > Juergen, > > > The agent id in the report is between the agent and the data collector - It's a privacy issue where the agent id was not to be even transmitted if the report-agent-id was false. > > > > > > Does the access control model allow these kinds of checks for presence of fields to be transmitted. > > > > > > Authorization for access (CRUD) is different than even transmitting the field (or value in the field depending on your protocol). > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, October 10, 2016 12:38 PM > > > To: lmap@ietf.org > > > Subject: [lmap] optional leafs due to sensitity concerns > > > > > > Hi, > > > > > > some objects in the information model (e.g., agent-id) are marked optional because of sensitivity considerations. Since there is an access control model for NETCONF (and RESTCONF), it would feel more natural to make these objects mandatory in YANG and leave it to the access control model to prevent access to them in deployments where this is needed. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:38:22 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0A61295B1 for ; Mon, 10 Oct 2016 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_ULa_xMBp3i for ; Mon, 10 Oct 2016 13:38:19 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 431871295A8 for ; Mon, 10 Oct 2016 13:38:19 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 48EEAAF1E2371; Mon, 10 Oct 2016 20:38:15 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AKcHnu020738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 20:38:18 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u9AKcHjF012666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 20:38:17 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:38:17 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8IAASYOA//+9PoA= Date: Mon, 10 Oct 2016 20:38:16 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> In-Reply-To: <20161010202727.GB31876@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:38:21 -0000 Juergen, I wouldn't do that without bringing it to the group - the framework was cle= ar about the need to convey the device-id among other things like the contr= oller URI in the bootstrap (pre-config). If it is a bug in the framework then fine - I would remove it if the group = agrees. I can say that in telecom we do allow for device identifiers to be set in = bootstrap sequences - think about it in the mobile setting - where you migh= t set the device's external identifier to something that that provider unde= rstands...=20 BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 3:27 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? Tim, I would remove it also from the ma-preconfig-obj. I think that the LMAP con= troller learns the device-id from the device during the bootstrapping proce= ss, not the other way round. The LMAP controller is in my view not the enti= ty to configure or bootstrap device-ids. I think this is actually a bug in RFC 7594. (Unless there is a very special= LMAP specific usage of this ID, which I did not manage to find.) /js On Mon, Oct 10, 2016 at 08:18:15PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > You are correct this is used the MA preconfiguration where the device ide= ntifier is set. > So it really should be removed from the configuration object - I don't th= ink you can set it after preconfiguration. > And if you want to change it - that should be outside the scope of LMAP. >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 2:57 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the inform= ation model? >=20 > Tim, >=20 > I think the Controller is simply not in charge to define a device-id. > The playground for the Controller is the LMAP agent-id, not any global de= vice-ids. Or perhaps the device-id was not meant to be a global device-id b= ut rather an LMAP specific device-id. But then, what is the use case for th= is, given that we have an agent-id? >=20 > So I am checking RFC 7594 and it mentions a device identifier as part of = the bootstrapping process: >=20 > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): >=20 > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. >=20 > o (optionally) a Group-ID, shared by several MAs and could be useful > for privacy reasons. For instance, reporting the Group-ID and not > the MA-ID could hinder tracking of a mobile device. >=20 > I did not find any other reference to a device identifier in RFC 7594. > So unless someone speaks up soon for keeping the device-id in the ma-prec= onfig-obj and ma-config-obj, I will remove it from the ma-preconfig-obj and= ma-config-obj. >=20 > On Mon, Oct 10, 2016 at 05:52:33PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > I believe it was because the LMAP controller wanted to control the id a= ssigned to the device in the setup of the agent. It went along with the gro= up identifier and UUID of the measurement agent. > >=20 > > In the TR-069 we already have this attribute as part of the base TR-181= data model so removing it from the configuration aspect and leaving it for= status is perfectly fine for us. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 12:33 PM > > To: lmap@ietf.org > > Subject: [lmap] why do we have a configurable device-id in the informat= ion model? > >=20 > > Hi, > >=20 > > while going through Martin's review comments for the YANG model, the qu= estion came up why the device-id in the information model is configurable. = Would it not be sufficient if there is a read-only device-id? > >=20 > > Right now, the information model have a device-id in both the ma-precon= fig-obj and the ma-config-obj. In addition, we have a device-id in the ma-s= tatus-obj and it seems to me the having it only in the ma-status-obj would = be enough. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > >=20 > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 10 13:43:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732841293FE for ; Mon, 10 Oct 2016 13:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dei8WZ09Q1yL for ; Mon, 10 Oct 2016 13:43:41 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 855A8129756 for ; Mon, 10 Oct 2016 13:43:41 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 055A68E27B71D; Mon, 10 Oct 2016 20:43:38 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AKheaQ028306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 20:43:40 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u9AKheRf019405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 20:43:40 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:43:40 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4CAAEaKAP//vaKQ Date: Mon, 10 Oct 2016 20:43:39 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> In-Reply-To: <20161010203630.GC31876@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:43:44 -0000 Juergen, Because the service provider will want to correlate the results based on th= e MA or Group. I am for simplification as well - So long as we ensure at least one or the = other is always reported - that was the intent. You can say that the report-agent value cannot be false unless a group-id i= s present... Maybe that makes it simpler. Agents will error otherwise upfro= nt. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 10, 2016 3:37 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] optional leafs due to sensitity concerns Tim, why not simply make the design simpler and at the same time less surprising= ? BTW, having a report without an agent-id and a group-id is of the same valu= e as a report with just a group-id if all MAs have the same group-id value = set. Why would the later be allowed by the model but the former be disallow= ed by the model? I vote for having report-agent-id as a simple unconditional boolean flag co= ntrolling the inclusion of the agent-id in reports. /js On Mon, Oct 10, 2016 at 08:28:18PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I think it is because they want at least one or the other reported. Such = that an anonymous agent would still have a group id to associate the result= s. > Yes indeed this rule can be easily misinterpreted - I guess we ought=20 > to have clarifying text in the descriptions in the reporting - maybe the = attribute should be named report-agent-id-with-group? >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 10, 2016 3:22 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns >=20 > On Mon, Oct 10, 2016 at 08:00:58PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen > >=20 > > In the information model - the text in section 3.2 says: > > Where the Measurement Group ID is set an additional flag (the Report=20 > > MA ID flag) is required to control whether the Measurement Agent ID=20 > > is also to be reported. The reporting of a Group ID without the MA=20 > > ID allows the MA to remain anonymous, which may be particularly=20 > > useful to prevent tracking of mobile MA devices. > >=20 > > So yes - we will report a MA ID if there is no Group ID or when the Gro= up ID exists and the report MA ID is false. > > >=20 > OK. But why? Why is the flag to suppress the agent id only relevant if=20 > there is a group id? Isn't it confusing if one sets report-agent-id to=20 > 'false' but the agent continues to report agent-ids until there is=20 > finally a group-id set? I think this is a real surprise for someone=20 > who has not read the fine print. I think the design would be simpler=20 > and less surprising if the report-agent-id would always enable/disable=20 > the reporting of the agent-id. (And yes, if you set report-agent-id to=20 > false and you do not set a group-id, you get a pretty anonymous=20 > report. But I think this is better than sending the agent-id even=20 > though the report-agent-id is false.) >=20 > > So the group id allows the capability for MA ID to remain anonymous. Th= e feature is invoked by setting the report MA ID field to false. > > What has to happen is worst case either a Group ID or MA ID is always r= eported. Sometimes both will be reported. >=20 > The worst case is someone setting report-agent-id to false and the MA sti= ll sending the agent-id just because a group-id is missing. I think this de= sign kind of violates the principle of least astonishment. >=20 > /js > =20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 10, 2016 2:46 PM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] optional leafs due to sensitity concerns > >=20 > > Tim, > >=20 > > I agree, the agent-id is not a problem since we do have an explicit con= trol whether this is included in a report. I actually stumbled about simila= r text (which might be a copy and paste error) for the configurable device-= id but if we end up removing the configurable device-id (see other thread),= then this becomes a mood point. > >=20 > > Looking at leaf report-agent-id, I see: > >=20 > > description > > "The 'report-agent-id' controls whether the > > 'agent-id' is reported to collectors if the > > 'group-id' is configured. If the 'group-id' > > is not configured, the agent-id is always > > reported."; > >=20 > > This seems weird since removing a group-id suddenly exposes an agent-id= . I kind of dislike such side-effects. Checking the information model, I se= e: > >=20 > > ma-config-report-agent-id: An optional flag indicating > > whether the identifier (ma- > > config-agent-id) should be > > included in reports. The defaul= t > > value is false. > >=20 > > This seems to be simpler and hence I suggest to remove the last sentenc= e from the description of the report-agent-id. > >=20 > > On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) w= rote: > > > Juergen, > > > The agent id in the report is between the agent and the data collecto= r - It's a privacy issue where the agent id was not to be even transmitted = if the report-agent-id was false. > > >=20 > > > Does the access control model allow these kinds of checks for presenc= e of fields to be transmitted.=20 > > >=20 > > > Authorization for access (CRUD) is different than even transmitting t= he field (or value in the field depending on your protocol). > > >=20 > > > BR, > > > Tim > > >=20 > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, October 10, 2016 12:38 PM > > > To: lmap@ietf.org > > > Subject: [lmap] optional leafs due to sensitity concerns > > >=20 > > > Hi, > > >=20 > > > some objects in the information model (e.g., agent-id) are marked opt= ional because of sensitivity considerations. Since there is an access contr= ol model for NETCONF (and RESTCONF), it would feel more natural to make the= se objects mandatory in YANG and leave it to the access control model to pr= event access to them in deployments where this is needed. > > >=20 > > > /js > > >=20 > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > >=20 > > >=20 > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 14 01:41:56 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674A128DF6 for ; Fri, 14 Oct 2016 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MIOi78gJgn6 for ; Fri, 14 Oct 2016 01:41:53 -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 3FF80129713 for ; Fri, 14 Oct 2016 01:41:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 73235AC1; Fri, 14 Oct 2016 10:41:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ae9QPUoiAT1r; Fri, 14 Oct 2016 10:41: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; Fri, 14 Oct 2016 10:41:51 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B63C2003F; Fri, 14 Oct 2016 10:41:51 +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 illKIKlrCnGz; Fri, 14 Oct 2016 10:41:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0C782003D; Fri, 14 Oct 2016 10:41:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6AC83CBFCFE; Fri, 14 Oct 2016 10:41:50 +0200 (CEST) Date: Fri, 14 Oct 2016 10:41:50 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161014084150.GD42729@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 08:41:56 -0000 On Mon, Oct 10, 2016 at 08:38:16PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I wouldn't do that without bringing it to the group - the framework was clear about the need to convey the device-id among other things like the controller URI in the bootstrap (pre-config). > If it is a bug in the framework then fine - I would remove it if the group agrees. > > I can say that in telecom we do allow for device identifiers to be set in bootstrap sequences - think about it in the mobile setting - where you might set the device's external identifier to something that that provider understands... I claim that setting a device-id is not the function of an LMAP controller. There are many things that one may want to bootstrap and that are outside LMAP. Chairs, can we get this resolved somehow? The document updates are blocked on this. /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 Fri Oct 14 01:49:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461BF128DF6 for ; Fri, 14 Oct 2016 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK4wRKQ5bJsG for ; Fri, 14 Oct 2016 01:49:36 -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 621E2129721 for ; Fri, 14 Oct 2016 01:49:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2BF7EAC1; Fri, 14 Oct 2016 10:49:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LpFxWWPHzBoe; Fri, 14 Oct 2016 10:49:24 +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; Fri, 14 Oct 2016 10:49:33 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A232003F; Fri, 14 Oct 2016 10:49:33 +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 sn2BHl6oNwlR; Fri, 14 Oct 2016 10:49:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 564CD2003D; Fri, 14 Oct 2016 10:49:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46D443CBFD98; Fri, 14 Oct 2016 10:49:33 +0200 (CEST) Date: Fri, 14 Oct 2016 10:49:33 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161014084933.GE42729@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 08:49:37 -0000 On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Because the service provider will want to correlate the results > based on the MA or Group. Cool, the service provider can set things up accordingly. > I am for simplification as well - So long as we ensure at least one > or the other is always reported - that was the intent. This violates the separation of policy from mechanism. You try to encode a policy into a mechanism. I am against that. Having this flag conditional adds complexity for no real value. Setting report-agent-id to false and then sending agent-ids breaks the principle of least astonishment. Creating a longer name to express that this flag has a convoluted logic does not solve the issue. What if in the future even more IDs are added? Sorry, this is simply bad design. > You can say that the report-agent value cannot be false unless a > group-id is present... Maybe that makes it simpler. Agents will > error otherwise upfront. No, it just shows that there is complexity without any real value. There is nothing wrong with allowing no agent-id and no group-id - whether this is useful is up to the controller (and collector) to decide. (There are indeed other ways to identify results, not reporting the agent-id for example is pointless if I tag all schedules with an agent specific value.) Chairs, can you help resolve this? Document updates are blocked on this. /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 Fri Oct 14 04:10:56 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F7F1294B6 for ; Fri, 14 Oct 2016 04:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqxYJcBPPsyc for ; Fri, 14 Oct 2016 04:10:52 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 B96BE129445 for ; Fri, 14 Oct 2016 04:10:51 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 5C4C995A4822C; Fri, 14 Oct 2016 11:10:49 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u9EBAnr9019472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 11:10:50 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u9EBAnh2029885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Oct 2016 11:10:49 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 07:10:49 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8IAASYOA//+9PoCABcbwAP//5gbg Date: Fri, 14 Oct 2016 11:10:48 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> In-Reply-To: <20161014084150.GD42729@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 11:10:55 -0000 Well if we go that route - all the pre-config needs to be removed as the in= tent was that was used to config the MA for communication to the controller= . So if you remove the device-id you need to remove the pre-config concept = from the IM. Which I do not think was the intent. The IM wasn't simply betw= een a Controller and MA but was used to support the Framework. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 14, 2016 3:42 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? On Mon, Oct 10, 2016 at 08:38:16PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I wouldn't do that without bringing it to the group - the framework was c= lear about the need to convey the device-id among other things like the con= troller URI in the bootstrap (pre-config). > If it is a bug in the framework then fine - I would remove it if the grou= p agrees. >=20 > I can say that in telecom we do allow for device identifiers to be set i= n bootstrap sequences - think about it in the mobile setting - where you mi= ght set the device's external identifier to something that that provider un= derstands... I claim that setting a device-id is not the function of an LMAP controller.= There are many things that one may want to bootstrap and that are outside = LMAP. Chairs, can we get this resolved somehow? The document updates are blocked = on this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 14 04:14:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FD81294AB for ; Fri, 14 Oct 2016 04:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y2xtzkVCLQm for ; Fri, 14 Oct 2016 04:14:41 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 2E865129445 for ; Fri, 14 Oct 2016 04:14:41 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id B3EA3BEA33C68; Fri, 14 Oct 2016 11:14:38 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9EBEdpp015037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 11:14:39 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9EBEdne025379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Oct 2016 11:14:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 07:14:39 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4CAAEaKAP//vaKQALjFi4AAA1nKEA== Date: Fri, 14 Oct 2016 11:14:38 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> In-Reply-To: <20161014084933.GE42729@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 11:14:44 -0000 Juergen, Then suggest a design fix that allows the controller to tell the agent to r= eport one of the options: 1) Agent-ID 2) Group-ID 3) Agent-ID and Group-ID BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 14, 2016 3:50 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] optional leafs due to sensitity concerns On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Because the service provider will want to correlate the results based=20 > on the MA or Group. Cool, the service provider can set things up accordingly. =20 > I am for simplification as well - So long as we ensure at least one or=20 > the other is always reported - that was the intent. This violates the separation of policy from mechanism. You try to encode a = policy into a mechanism. I am against that. Having this flag conditional ad= ds complexity for no real value. Setting report-agent-id to false and then = sending agent-ids breaks the principle of least astonishment. Creating a lo= nger name to express that this flag has a convoluted logic does not solve t= he issue. What if in the future even more IDs are added? Sorry, this is sim= ply bad design. > You can say that the report-agent value cannot be false unless a=20 > group-id is present... Maybe that makes it simpler. Agents will error=20 > otherwise upfront. No, it just shows that there is complexity without any real value. There is= nothing wrong with allowing no agent-id and no group-id - whether this is = useful is up to the controller (and collector) to decide. (There are indeed other ways to identify results, not= reporting the agent-id for example is pointless if I tag all schedules wit= h an agent specific value.) Chairs, can you help resolve this? Document updates are blocked on this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 21 16:26:52 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA61B12996E; Fri, 21 Oct 2016 16:21:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207982.28214.314224880172054299.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:19 -0700 Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: [lmap] lmap - Requested session has been scheduled for IETF 97 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:20 -0000 Dear Dan Romascanu, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lmap Session 1 (1:30:00) Thursday, Afternoon Session I 1330-1500 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Large-Scale Measurement of Broadband Performance Area Name: Operations and Management Area Session Requester: Dan Romascanu Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: opsawg netconf netmod xrblock i2nsf supa ippm Second Priority: homenet dnssd Special Requests: --------------------------------------------------------- From nobody Wed Oct 26 11:51:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA38129739 for ; Wed, 26 Oct 2016 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr5BJiK-V_jy for ; Wed, 26 Oct 2016 11:51:22 -0700 (PDT) Received: from cdpipgw01.twcable.com (unknown [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 25A071296B3 for ; Wed, 26 Oct 2016 11:51:21 -0700 (PDT) X-SENDER-IP: 10.64.163.158 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.31,551,1473134400"; d="scan'208";a="1443877246" Received: from unknown (HELO exchpapp17.corp.twcable.com) ([10.64.163.158]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 26 Oct 2016 14:45:38 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp17.corp.twcable.com (10.64.163.158) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 26 Oct 2016 14:51:18 -0400 Received: from EXCHPAPP11.corp.twcable.com ([10.245.162.16]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1178.000; Wed, 26 Oct 2016 14:51:18 -0400 From: "Weil, Jason" To: "Carey, Timothy (Nokia - US)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIx0av147j0G/a06SEtMBGa7zuaCiUWAAgAAJLwCAAARNAIAABfWAgAABrgCAAAJLAIAAAf+AgAWBz4CAACiJAIATGIKA Date: Wed, 26 Oct 2016 18:51:17 +0000 Message-ID: References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22660.004 x-tm-as-result: No--56.074900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 18:51:23 -0000 We are now a few days out from the Oct 31 cutoff for draft submissions. I have a few questions regarding the Information-model-11 draft. 1. Are we still at a deadlock on the ability for a controller to signal which ID for an MA to use in reporting discussion? 2. If so is there a plan forward or possible new design being contemplated behind the scenes? It would be nice to hear from more than just Time and Juergen in this discussion. It=B9s pretty easy for two parties to reach a deadlock. It is much harder for 5 or 6 people so it would be nice if others want to see this draft progress to completion to weigh in on the discussion. Thanks, Jason On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - US)" wrote: >Juergen, > >Then suggest a design fix that allows the controller to tell the agent to >report one of the options: >1) Agent-ID >2) Group-ID >3) Agent-ID and Group-ID > >BR, >Tim > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: Friday, October 14, 2016 3:50 AM >To: Carey, Timothy (Nokia - US) >Cc: lmap@ietf.org >Subject: Re: [lmap] optional leafs due to sensitity concerns > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) >wrote: >> Juergen, >> >> Because the service provider will want to correlate the results based >> on the MA or Group. > >Cool, the service provider can set things up accordingly. > >> I am for simplification as well - So long as we ensure at least one or >> the other is always reported - that was the intent. > >This violates the separation of policy from mechanism. You try to encode >a policy into a mechanism. I am against that. Having this flag >conditional adds complexity for no real value. Setting report-agent-id to >false and then sending agent-ids breaks the principle of least >astonishment. Creating a longer name to express that this flag has a >convoluted logic does not solve the issue. What if in the future even >more IDs are added? Sorry, this is simply bad design. > >> You can say that the report-agent value cannot be false unless a >> group-id is present... Maybe that makes it simpler. Agents will error >> otherwise upfront. > >No, it just shows that there is complexity without any real value. There >is nothing wrong with allowing no agent-id and no group-id - whether this >is useful is up to the controller (and >collector) to decide. (There are indeed other ways to identify results, >not reporting the agent-id for example is pointless if I tag all >schedules with an agent specific value.) > >Chairs, can you help resolve this? Document updates are blocked on this. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Oct 31 06:40:39 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A3A1295A8 for ; Mon, 31 Oct 2016 06:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjlVJxV-kVZw for ; Mon, 31 Oct 2016 06:40:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9FA129437 for ; Mon, 31 Oct 2016 06:40:36 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9VDZGR1032751; Mon, 31 Oct 2016 09:40:20 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 26e6kvtdg2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Oct 2016 09:40:20 -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 u9VDeJc8018738; Mon, 31 Oct 2016 09:40:20 -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 u9VDeENF018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 09:40:15 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 31 Oct 2016 13:39:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.216]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 09:39:58 -0400 From: "STARK, BARBARA H" To: "Weil, Jason" , "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIx0eKDv73uZMAUCTk/GbgteyzKCiUWAAgAAJLwCAAARNAIAABfWAgAABrgCAAAJLAIAAAf+AgAWBz4CAACiJAIATW5CAgAc/tpA= Date: Mon, 31 Oct 2016 13:39:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DA2BA7F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.212.93] Content-Type: text/plain; charset="iso-8859-1" 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=2016-10-31_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610310248 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 13:40:38 -0000 > We are now a few days out from the Oct 31 cutoff for draft submissions. I > have a few questions regarding the Information-model-11 draft. >=20 > 1. Are we still at a deadlock on the ability for a controller to signal= which ID > for an MA to use in reporting discussion? >=20 > 2. If so is there a plan forward or possible new design being contempla= ted > behind the scenes? >=20 > It would be nice to hear from more than just Tim and Juergen in this > discussion. It=B9s pretty easy for two parties to reach a deadlock. It is= much > harder for 5 or 6 people so it would be nice if others want to see this d= raft > progress to completion to weigh in on the discussion. For me, I would be satisfied with any solution that allows the controller t= o tell the agent=20 to report one of the following: 1) Agent-ID 2) Group-ID 3) Agent-ID and Group-ID Tim did suggest a way to do this, which I had no problem with. But there ar= e definitely other ways to make this happen. If no other way is suggested, = then I would like to stick with the mechanism Tim proposed. If another way = is suggested (in a timely manner), I'm happy to consider it.=20 Barbara From nobody Mon Oct 31 08:12:16 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE3E128B37 for ; Mon, 31 Oct 2016 08:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI7vAL1j7ZAw for ; Mon, 31 Oct 2016 08:12:13 -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 D3CAB1294D0 for ; Mon, 31 Oct 2016 08:12:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 38B778E7; Mon, 31 Oct 2016 16:12:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UK71gGgV8QNs; Mon, 31 Oct 2016 16:12:10 +0100 (CET) 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; Mon, 31 Oct 2016 16:12:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD76420045; Mon, 31 Oct 2016 16:12:10 +0100 (CET) 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 PcFZEHs5Quw5; Mon, 31 Oct 2016 16:12:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3B0820046; Mon, 31 Oct 2016 16:12:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C9CC13D0091C; Mon, 31 Oct 2016 16:12:08 +0100 (CET) Date: Mon, 31 Oct 2016 16:12:07 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161031151207.GA38757@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:12:15 -0000 Tim, the pre-configuration object provides the information necessary to talk to the _LMAP controller_. This information is only redundant in case the LMAP controller is the same entity controlling other aspects of the device, which might be the case within BBF's framework but is not generally assumed to be true. I do not see why an LMAP controller would be in charge of configuring the device id (or any other properties of a device that are not LMAP specific). /js On Fri, Oct 14, 2016 at 11:10:48AM +0000, Carey, Timothy (Nokia - US) wrote: > Well if we go that route - all the pre-config needs to be removed as the intent was that was used to config the MA for communication to the controller. So if you remove the device-id you need to remove the pre-config concept from the IM. Which I do not think was the intent. The IM wasn't simply between a Controller and MA but was used to support the Framework. > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 14, 2016 3:42 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the information model? > > On Mon, Oct 10, 2016 at 08:38:16PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > I wouldn't do that without bringing it to the group - the framework was clear about the need to convey the device-id among other things like the controller URI in the bootstrap (pre-config). > > If it is a bug in the framework then fine - I would remove it if the group agrees. > > > > I can say that in telecom we do allow for device identifiers to be set in bootstrap sequences - think about it in the mobile setting - where you might set the device's external identifier to something that that provider understands... > > I claim that setting a device-id is not the function of an LMAP controller. There are many things that one may want to bootstrap and that are outside LMAP. > > Chairs, can we get this resolved somehow? The document updates are blocked on this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 09:47:10 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33281298C6 for ; Mon, 31 Oct 2016 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSq3PJ6szmbD for ; Mon, 31 Oct 2016 09:47:06 -0700 (PDT) Received: from mail.chartercom.com (mail.chartercom.com [24.176.92.28]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDE9129465 for ; Mon, 31 Oct 2016 09:47:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,575,1473138000"; d="scan'208";a="51880376" Received: from unknown (HELO SC58MEXGP012.CORP.CHARTERCOM.com) ([172.24.253.140]) by mail.chartercom.com with ESMTP; 31 Oct 2016 11:38:00 -0500 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM (172.24.253.136) by SC58MEXGP012.CORP.CHARTERCOM.com (172.24.253.140) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 31 Oct 2016 11:47:04 -0500 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM ([fe80::719f:6d16:1ed5:5b5c]) by SC58MEXGP008.CORP.CHARTERCOM.com ([fe80::719f:6d16:1ed5:5b5c%19]) with mapi id 15.00.1104.000; Mon, 31 Oct 2016 11:47:04 -0500 From: "Weil, Jason A" To: "MORTON, ALFRED C (AL)" , "jason.weil@twcable.com" , "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIx0bqNg/yVf730yiiMb2UPZrwaCiYiMAgAAJLwCAAAROAIAABfSAgAABrwCAAAJKAIAAAgCAgAWBzoCAACiKAIATW5CAgAeObQD//+d3gA== Date: Mon, 31 Oct 2016 16:47:04 +0000 Message-ID: References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.253.243] Content-Type: text/plain; charset="euc-kr" Content-ID: <788A5DC307523E4B972DEB9C9D4B73E0@chartercom.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:47:09 -0000 SSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCB3ZSBhcmUganVzdCB0YWxraW5nIGFib3V0 IHRoZSBjb250cm9sbGVyDQp0ZWxsaW5nIHRoZSBNQSB0byByZXBvcnQgb24gb25lIG9mIHRoZSBv cHRpb25zOiBBZ2VudC1JRCwgR3JvdXAtSUQsIG9yDQpBZ2VudC1JRCBhbmQgR3JvdXAtSUQgYW5k IG5vdCBhYm91dCBob3cgdGhlc2UgSWRlbnRpZmllcnMgZ2V0IGNvbmZpZ3VyZWQNCm9uIHRoZSBh Z2VudC4gSSBiZWxpZXZlIHRoaXMgaXMgdGhlIGVtYWlsIEFsIHdhcyByZWZlcnJpbmcgdG8gYmVs b3cuIEFtIEkNCndyb25nIGhlcmU/IFRoaXMgc2VlbXMgbGlrZSBhIGZhaXJseSBlYXN5IGNoYW5n ZSB0aGF0IHdlIGhhdmUgY29uc2Vuc3VzDQpmb3IgYmFzZWQgb24gdGhlIHJlc3BvbnNlcyBvbiB0 aGUgbGlzdC4NCg0KSmFzb24NCg0KDQoNCk9uIDEwLzMxLzE2LCAxMDoxNCBBTSwgIk1PUlRPTiwg QUxGUkVEIEMgKEFMKSIgPGFjbW9ydG9uQGF0dC5jb20+IHdyb3RlOg0KDQo+SSdkIHByZWZlciB0 byBmb2xsb3cgV0cgYWdyZWVtZW50cyBjYXB0dXJlZCBpbiB0aGUNCj5GcmFtZXdvcmsgUkZDOg0K Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTk0I3NlY3Rpb24tNS40DQo+DQo+d2hl cmUgUmVwb3J0OiAgW01BLUlEICYvb3IgR3JvdXAtSURdLC4uLg0KPm1ha2VzIG9uZSBvciBib3Ro IG9mIHRoZXNlIElEcyBub24tb3B0aW9uYWwsDQo+YW5kIHRoaXMgaXMgY29uc2lzdGVudCB3aXRo IFRpbSdzIDEwLzE0IHJlcXVlc3QgYmVsb3cuDQo+DQo+cmVnYXJkcywNCj5BbA0KPg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXZWlsLCBKYXNvbg0KPj4gU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDI2LCAyMDE2IDI6NTEgUE0NCj4+IFRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEg LSBVUyk7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPj4gQ2M6IGxtYXBAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbbG1hcF0gb3B0aW9uYWwgbGVhZnMgZHVlIHRvIHNlbnNpdGl0eSBjb25jZXJu cw0KPj4gDQo+PiANCj4+IA0KPj4gV2UgYXJlIG5vdyBhIGZldyBkYXlzIG91dCBmcm9tIHRoZSBP Y3QgMzEgY3V0b2ZmIGZvciBkcmFmdCBzdWJtaXNzaW9ucy4NCj4+IEkNCj4+IGhhdmUgYSBmZXcg cXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgSW5mb3JtYXRpb24tbW9kZWwtMTEgZHJhZnQuDQo+PiAN Cj4+ICAgMS4gQXJlIHdlIHN0aWxsIGF0IGEgZGVhZGxvY2sgb24gdGhlIGFiaWxpdHkgZm9yIGEg Y29udHJvbGxlciB0bw0KPj4gc2lnbmFsDQo+PiB3aGljaCBJRCBmb3IgYW4gTUEgdG8gdXNlIGlu IHJlcG9ydGluZyBkaXNjdXNzaW9uPw0KPj4gDQo+PiAgIDIuIElmIHNvIGlzIHRoZXJlIGEgcGxh biBmb3J3YXJkIG9yIHBvc3NpYmxlIG5ldyBkZXNpZ24gYmVpbmcNCj4+IGNvbnRlbXBsYXRlZCBi ZWhpbmQgdGhlIHNjZW5lcz8NCj4+IA0KPj4gSXQgd291bGQgYmUgbmljZSB0byBoZWFyIGZyb20g bW9yZSB0aGFuIGp1c3QgVGltZSBhbmQgSnVlcmdlbiBpbiB0aGlzDQo+PiBkaXNjdXNzaW9uLiBJ dKn2cyBwcmV0dHkgZWFzeSBmb3IgdHdvIHBhcnRpZXMgdG8gcmVhY2ggYSBkZWFkbG9jay4gSXQg aXMNCj4+IG11Y2ggaGFyZGVyIGZvciA1IG9yIDYgcGVvcGxlIHNvIGl0IHdvdWxkIGJlIG5pY2Ug aWYgb3RoZXJzIHdhbnQgdG8gc2VlDQo+PiB0aGlzIGRyYWZ0IHByb2dyZXNzIHRvIGNvbXBsZXRp b24gdG8gd2VpZ2ggaW4gb24gdGhlIGRpc2N1c3Npb24uDQo+PiANCj4+IFRoYW5rcywNCj4+IEph c29uDQo+PiANCj4+IE9uIDEwLzE0LzE2LCA1OjE0IEFNLCAibG1hcCBvbiBiZWhhbGYgb2YgQ2Fy ZXksIFRpbW90aHkgKE5va2lhIC0gVVMpIg0KPj4gPGxtYXAtYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2YgdGltb3RoeS5jYXJleUBub2tpYS5jb20+IHdyb3RlOg0KPj4gDQo+PiA+SnVlcmdl biwNCj4+ID4NCj4+ID5UaGVuIHN1Z2dlc3QgYSBkZXNpZ24gZml4IHRoYXQgYWxsb3dzIHRoZSBj b250cm9sbGVyIHRvIHRlbGwgdGhlIGFnZW50DQo+PiB0bw0KPj4gPnJlcG9ydCBvbmUgb2YgdGhl IG9wdGlvbnM6DQo+PiA+MSkgQWdlbnQtSUQNCj4+ID4yKSBHcm91cC1JRA0KPj4gPjMpIEFnZW50 LUlEIGFuZCBHcm91cC1JRA0KPj4gPg0KPj4gPkJSLA0KPj4gPlRpbQ0KPj4gPg0KPj4gPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFtt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy0NCj4+IHVuaXZlcnNpdHkuZGVdDQo+PiA+U2Vu dDogRnJpZGF5LCBPY3RvYmVyIDE0LCAyMDE2IDM6NTAgQU0NCj4+ID5UbzogQ2FyZXksIFRpbW90 aHkgKE5va2lhIC0gVVMpIDx0aW1vdGh5LmNhcmV5QG5va2lhLmNvbT4NCj4+ID5DYzogbG1hcEBp ZXRmLm9yZw0KPj4gPlN1YmplY3Q6IFJlOiBbbG1hcF0gb3B0aW9uYWwgbGVhZnMgZHVlIHRvIHNl bnNpdGl0eSBjb25jZXJucw0KPj4gPg0KPj4gPk9uIE1vbiwgT2N0IDEwLCAyMDE2IGF0IDA4OjQz OjM5UE0gKzAwMDAsIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKQ0KPj4gPndyb3RlOg0KPj4g Pj4gSnVlcmdlbiwNCj4+ID4+DQo+PiA+PiBCZWNhdXNlIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHdp bGwgd2FudCB0byBjb3JyZWxhdGUgdGhlIHJlc3VsdHMgYmFzZWQNCj4+ID4+IG9uIHRoZSBNQSBv ciBHcm91cC4NCj4+ID4NCj4+ID5Db29sLCB0aGUgc2VydmljZSBwcm92aWRlciBjYW4gc2V0IHRo aW5ncyB1cCBhY2NvcmRpbmdseS4NCj4+ID4NCj4+ID4+IEkgYW0gZm9yIHNpbXBsaWZpY2F0aW9u IGFzIHdlbGwgLSBTbyBsb25nIGFzIHdlIGVuc3VyZSBhdCBsZWFzdCBvbmUNCj4+IG9yDQo+PiA+ PiB0aGUgb3RoZXIgaXMgYWx3YXlzIHJlcG9ydGVkIC0gdGhhdCB3YXMgdGhlIGludGVudC4NCj4+ ID4NCj4+ID5UaGlzIHZpb2xhdGVzIHRoZSBzZXBhcmF0aW9uIG9mIHBvbGljeSBmcm9tIG1lY2hh bmlzbS4gWW91IHRyeSB0bw0KPj4gZW5jb2RlDQo+PiA+YSBwb2xpY3kgaW50byBhIG1lY2hhbmlz bS4gSSBhbSBhZ2FpbnN0IHRoYXQuIEhhdmluZyB0aGlzIGZsYWcNCj4+ID5jb25kaXRpb25hbCBh ZGRzIGNvbXBsZXhpdHkgZm9yIG5vIHJlYWwgdmFsdWUuIFNldHRpbmcgcmVwb3J0LWFnZW50LWlk DQo+PiB0bw0KPj4gPmZhbHNlIGFuZCB0aGVuIHNlbmRpbmcgYWdlbnQtaWRzIGJyZWFrcyB0aGUg cHJpbmNpcGxlIG9mIGxlYXN0DQo+PiA+YXN0b25pc2htZW50LiBDcmVhdGluZyBhIGxvbmdlciBu YW1lIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGZsYWcgaGFzIGENCj4+ID5jb252b2x1dGVkIGxvZ2lj IGRvZXMgbm90IHNvbHZlIHRoZSBpc3N1ZS4gV2hhdCBpZiBpbiB0aGUgZnV0dXJlIGV2ZW4NCj4+ ID5tb3JlIElEcyBhcmUgYWRkZWQ/IFNvcnJ5LCB0aGlzIGlzIHNpbXBseSBiYWQgZGVzaWduLg0K Pj4gPg0KPj4gPj4gWW91IGNhbiBzYXkgdGhhdCB0aGUgcmVwb3J0LWFnZW50IHZhbHVlIGNhbm5v dCBiZSBmYWxzZSB1bmxlc3MgYQ0KPj4gPj4gZ3JvdXAtaWQgaXMgcHJlc2VudC4uLiBNYXliZSB0 aGF0IG1ha2VzIGl0IHNpbXBsZXIuIEFnZW50cyB3aWxsIGVycm9yDQo+PiA+PiBvdGhlcndpc2Ug dXBmcm9udC4NCj4+ID4NCj4+ID5ObywgaXQganVzdCBzaG93cyB0aGF0IHRoZXJlIGlzIGNvbXBs ZXhpdHkgd2l0aG91dCBhbnkgcmVhbCB2YWx1ZS4NCj4+IFRoZXJlDQo+PiA+aXMgbm90aGluZyB3 cm9uZyB3aXRoIGFsbG93aW5nIG5vIGFnZW50LWlkIGFuZCBubyBncm91cC1pZCAtIHdoZXRoZXIN Cj4+IHRoaXMNCj4+ID5pcyB1c2VmdWwgaXMgdXAgdG8gdGhlIGNvbnRyb2xsZXIgKGFuZA0KPj4g PmNvbGxlY3RvcikgdG8gZGVjaWRlLiAoVGhlcmUgYXJlIGluZGVlZCBvdGhlciB3YXlzIHRvIGlk ZW50aWZ5IHJlc3VsdHMsDQo+PiA+bm90IHJlcG9ydGluZyB0aGUgYWdlbnQtaWQgZm9yIGV4YW1w bGUgaXMgcG9pbnRsZXNzIGlmIEkgdGFnIGFsbA0KPj4gPnNjaGVkdWxlcyB3aXRoIGFuIGFnZW50 IHNwZWNpZmljIHZhbHVlLikNCj4+ID4NCj4+ID5DaGFpcnMsIGNhbiB5b3UgaGVscCByZXNvbHZl IHRoaXM/IERvY3VtZW50IHVwZGF0ZXMgYXJlIGJsb2NrZWQgb24NCj4+IHRoaXMuDQo+PiA+DQo+ PiA+L2pzDQo+PiA+DQo+PiA+LS0NCj4+ID5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4gPlBob25lOiArNDkgNDIxIDIwMCAz NTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+ID5G YXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLz4NCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gPmxtYXAgbWFpbGluZyBsaXN0DQo+PiA+bG1hcEBpZXRmLm9yZw0KPj4g Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA0KPj4gDQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiANCj4+IFRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+ PiBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0DQo+PiB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVy IENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4gc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuDQo+PiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug YXJlIGhlcmVieQ0KPj4gbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+IGluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+IHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LQ0KPj4gbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBwZXJtYW5lbnRseQ0KPj4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGxtYXAgbWFpbGluZyBsaXN0DQo+PiBs bWFwQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xt YXANCg0K From nobody Mon Oct 31 09:49:15 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948731298BB for ; Mon, 31 Oct 2016 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM-iMZ84bPpS for ; Mon, 31 Oct 2016 09:49:12 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 BBB7912966E for ; Mon, 31 Oct 2016 09:49:12 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 58D274082888F; Mon, 31 Oct 2016 16:49:09 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9VGnAcm024690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2016 16:49:11 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9VGlNx0022977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2016 16:49:10 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Mon, 31 Oct 2016 12:47:38 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8IAASYOA//+9PoCABcbwAP//5gbgA2fU64AABVi3kA== Date: Mon, 31 Oct 2016 16:47:38 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> In-Reply-To: <20161031151207.GA38757@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:49:14 -0000 Juergen, You are indeed correct - if you are modelling the MA to Controller informat= ion elements you do not need the preconfiguration information elements.=20 That is between the "bootstrap" system and the MA. The information model pr= ovides the information elements of the Framework not just the MA to control= ler information flows... Just as the first sentence in the Abstract says.... This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. All the pre-config does is outline what information is on the device - whic= h of course the device ID is one element. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 31, 2016 10:12 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? Tim, the pre-configuration object provides the information necessary to talk to = the _LMAP controller_. This information is only redundant in case the LMAP = controller is the same entity controlling other aspects of the device, whic= h might be the case within BBF's framework but is not generally assumed to = be true. I do not see why an LMAP controller would be in charge of configuring the d= evice id (or any other properties of a device that are not LMAP specific). /js On Fri, Oct 14, 2016 at 11:10:48AM +0000, Carey, Timothy (Nokia - US) wrote= : > Well if we go that route - all the pre-config needs to be removed as the = intent was that was used to config the MA for communication to the controll= er. So if you remove the device-id you need to remove the pre-config concep= t from the IM. Which I do not think was the intent. The IM wasn't simply be= tween a Controller and MA but was used to support the Framework. >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 14, 2016 3:42 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the inform= ation model? >=20 > On Mon, Oct 10, 2016 at 08:38:16PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > I wouldn't do that without bringing it to the group - the framework was= clear about the need to convey the device-id among other things like the c= ontroller URI in the bootstrap (pre-config). > > If it is a bug in the framework then fine - I would remove it if the gr= oup agrees. > >=20 > > I can say that in telecom we do allow for device identifiers to be set= in bootstrap sequences - think about it in the mobile setting - where you = might set the device's external identifier to something that that provider = understands... >=20 > I claim that setting a device-id is not the function of an LMAP controlle= r. There are many things that one may want to bootstrap and that are outsid= e LMAP. >=20 > Chairs, can we get this resolved somehow? The document updates are blocke= d on this. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 09:52:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E259A12966E for ; Mon, 31 Oct 2016 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTrF8MyEWIUa for ; Mon, 31 Oct 2016 09:52:46 -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 EDB25129465 for ; Mon, 31 Oct 2016 09:52:45 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9VEFoZY040520; Mon, 31 Oct 2016 10:18:48 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 26e6317wsd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Oct 2016 10:18:48 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9VEIl1g011297; Mon, 31 Oct 2016 10:18:47 -0400 Received: from mlpi410.sfdc.sbc.com (mlpi410.sfdc.sbc.com [130.9.128.242]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9VEIhwE011256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 10:18:44 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi410.sfdc.sbc.com (RSA Interceptor); Mon, 31 Oct 2016 14:17:32 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VEF745006173; Mon, 31 Oct 2016 09:15:07 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VEEsMO004856; Mon, 31 Oct 2016 09:14:54 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id C321BF0563; Mon, 31 Oct 2016 10:14:53 -0400 (EDT) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 10:14:53 -0400 From: "MORTON, ALFRED C (AL)" To: "Weil, Jason" , "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4CAAEaKAP//vaKQALjFi4AAA1nKEAJtKV2AAOjdqAA= Date: Mon, 31 Oct 2016 14:14:52 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.219.121] Content-Type: text/plain; charset="iso-8859-1" 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=2016-10-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610310260 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:52:48 -0000 I'd prefer to follow WG agreements captured in the Framework RFC: https://tools.ietf.org/html/rfc7594#section-5.4 where Report: [MA-ID &/or Group-ID],... makes one or both of these IDs non-optional, and this is consistent with Tim's 10/14 request below. regards, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > Sent: Wednesday, October 26, 2016 2:51 PM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns >=20 >=20 >=20 > We are now a few days out from the Oct 31 cutoff for draft submissions. > I > have a few questions regarding the Information-model-11 draft. >=20 > 1. Are we still at a deadlock on the ability for a controller to > signal > which ID for an MA to use in reporting discussion? >=20 > 2. If so is there a plan forward or possible new design being > contemplated behind the scenes? >=20 > It would be nice to hear from more than just Time and Juergen in this > discussion. It=B9s pretty easy for two parties to reach a deadlock. It is > much harder for 5 or 6 people so it would be nice if others want to see > this draft progress to completion to weigh in on the discussion. >=20 > Thanks, > Jason >=20 > On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - US)" > wrote: >=20 > >Juergen, > > > >Then suggest a design fix that allows the controller to tell the agent > to > >report one of the options: > >1) Agent-ID > >2) Group-ID > >3) Agent-ID and Group-ID > > > >BR, > >Tim > > > >-----Original Message----- > >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > >Sent: Friday, October 14, 2016 3:50 AM > >To: Carey, Timothy (Nokia - US) > >Cc: lmap@ietf.org > >Subject: Re: [lmap] optional leafs due to sensitity concerns > > > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) > >wrote: > >> Juergen, > >> > >> Because the service provider will want to correlate the results based > >> on the MA or Group. > > > >Cool, the service provider can set things up accordingly. > > > >> I am for simplification as well - So long as we ensure at least one > or > >> the other is always reported - that was the intent. > > > >This violates the separation of policy from mechanism. You try to > encode > >a policy into a mechanism. I am against that. Having this flag > >conditional adds complexity for no real value. Setting report-agent-id > to > >false and then sending agent-ids breaks the principle of least > >astonishment. Creating a longer name to express that this flag has a > >convoluted logic does not solve the issue. What if in the future even > >more IDs are added? Sorry, this is simply bad design. > > > >> You can say that the report-agent value cannot be false unless a > >> group-id is present... Maybe that makes it simpler. Agents will error > >> otherwise upfront. > > > >No, it just shows that there is complexity without any real value. > There > >is nothing wrong with allowing no agent-id and no group-id - whether > this > >is useful is up to the controller (and > >collector) to decide. (There are indeed other ways to identify results, > >not reporting the agent-id for example is pointless if I tag all > >schedules with an agent specific value.) > > > >Chairs, can you help resolve this? Document updates are blocked on > this. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this E- > mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Oct 31 10:02:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9A129479 for ; Mon, 31 Oct 2016 10:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgDpBXb_eeGY for ; Mon, 31 Oct 2016 10:02:49 -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 D4E82129413 for ; Mon, 31 Oct 2016 10:02:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AAC26DB3; Mon, 31 Oct 2016 18:02:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id h4mWXnCE1WWV; Mon, 31 Oct 2016 18:02:46 +0100 (CET) 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; Mon, 31 Oct 2016 18:02:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1885720045; Mon, 31 Oct 2016 18:02:47 +0100 (CET) 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 OuUiR6nL5Z1i; Mon, 31 Oct 2016 18:02:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 851FC20046; Mon, 31 Oct 2016 18:02:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 63F873D00D00; Mon, 31 Oct 2016 18:02:44 +0100 (CET) Date: Mon, 31 Oct 2016 18:02:44 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161031170242.GA39044@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:02:52 -0000 On Mon, Oct 31, 2016 at 04:47:38PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > You are indeed correct - if you are modelling the MA to Controller information elements you do not need the preconfiguration information elements. > That is between the "bootstrap" system and the MA. The information model provides the information elements of the Framework not just the MA to controller information flows... > Just as the first sentence in the Abstract says.... > This Information Model applies to the Measurement Agent within a > Large-Scale Measurement Platform. As such it outlines the > information that is (pre-)configured on the Measurement Agent or > exists in communications with a Controller or Collector within an > LMAP framework. > > All the pre-config does is outline what information is on the device - which of course the device ID is one element. > I am raising a technical argument, you respond with a formal argument. This does not help to resolve the issue. A device has lots of information that is not in the pre-config, some is listed in capability and status information. Note that I have zero problem to report ma-status-device-id in ma-status-obj. All I question is that the device-id is part of the LMAP ma-preconfig-obj and the LMAP ma-config-obj. Note that this discussion was triggered by a comment Martin made when he was reviewing the YANG data model. The YANG data model has this configurable device-id because the info model has it and the info model has it because of this statement in the framework: As a result of the Bootstrapping process, the MA learns the following information ([LMAP-INFO] defines the consequent list of information elements): o its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses or both. I believe this sentence is wrong or its interpretation is wrong. I do think the LMAP controller is in charge of assigning the MA-ID, I do not consider it in charge to assign a device identifier. The bootstrap process may yield one but the device identifier seems out of scope for the LMAP controller. Note that there is additional text: The details of the Bootstrapping process are device/access specific. For example, the information could be in the firmware, manually configured, or transferred via a protocol like that described in TR-069 [TR-069]. There may be a multi-stage process where the MA contacts a 'hard-coded' address, which replies with the Bootstrapping information. Hence, I think we are not in any way violating the framework by not having the device-id in ma-preconfig-obj or ma-config-obj in the LMAP information model. /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 Mon Oct 31 12:40:15 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEDA129A95 for ; Mon, 31 Oct 2016 12:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghz6RxgzVQp2 for ; Mon, 31 Oct 2016 12:40:11 -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 B61A8129A76 for ; Mon, 31 Oct 2016 12:40:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8E9AF14C5; Mon, 31 Oct 2016 20:40:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id B1BAHpcyY43O; Mon, 31 Oct 2016 20:40:08 +0100 (CET) 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; Mon, 31 Oct 2016 20:40:09 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBE4220046; Mon, 31 Oct 2016 20:40:08 +0100 (CET) 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 daFhmhACG4EG; Mon, 31 Oct 2016 20:40:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DA5120045; Mon, 31 Oct 2016 20:40:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7229A3D014D7; Mon, 31 Oct 2016 20:40:07 +0100 (CET) Date: Mon, 31 Oct 2016 20:40:06 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161031194006.GA39440@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 19:40:13 -0000 Tim, the obvious solution is to add a boolean report-group-id and the two booleans report-agent-id and report-group-id determine whether the agent-id or the group-id (if available) is reported. It is up to the policy of the controller to set them. No side effects or inter-dependencies. /js On Fri, Oct 14, 2016 at 11:14:38AM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Then suggest a design fix that allows the controller to tell the agent to report one of the options: > 1) Agent-ID > 2) Group-ID > 3) Agent-ID and Group-ID > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 14, 2016 3:50 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns > > On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > Because the service provider will want to correlate the results based > > on the MA or Group. > > Cool, the service provider can set things up accordingly. > > > I am for simplification as well - So long as we ensure at least one or > > the other is always reported - that was the intent. > > This violates the separation of policy from mechanism. You try to encode a policy into a mechanism. I am against that. Having this flag conditional adds complexity for no real value. Setting report-agent-id to false and then sending agent-ids breaks the principle of least astonishment. Creating a longer name to express that this flag has a convoluted logic does not solve the issue. What if in the future even more IDs are added? Sorry, this is simply bad design. > > > You can say that the report-agent value cannot be false unless a > > group-id is present... Maybe that makes it simpler. Agents will error > > otherwise upfront. > > No, it just shows that there is complexity without any real value. There is nothing wrong with allowing no agent-id and no group-id - whether this is useful is up to the controller (and > collector) to decide. (There are indeed other ways to identify results, not reporting the agent-id for example is pointless if I tag all schedules with an agent specific value.) > > Chairs, can you help resolve this? Document updates are blocked on this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 12:51:56 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACDF129ACC for ; Mon, 31 Oct 2016 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUGayzegpbjq for ; Mon, 31 Oct 2016 12:51:53 -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 7C6C0129AD2 for ; Mon, 31 Oct 2016 12:51:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 48396F02; Mon, 31 Oct 2016 20:51:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xuCQAy0RYFRX; Mon, 31 Oct 2016 20:51:41 +0100 (CET) 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; Mon, 31 Oct 2016 20:51:42 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 728F220046; Mon, 31 Oct 2016 20:51:42 +0100 (CET) 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 qcrpfMxhI4MA; Mon, 31 Oct 2016 20:51:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 810F020045; Mon, 31 Oct 2016 20:51:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 586A93D0158B; Mon, 31 Oct 2016 20:51:41 +0100 (CET) Date: Mon, 31 Oct 2016 20:51:41 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20161031195141.GB39440@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "Weil, Jason" , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" , "Weil, Jason" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 19:51:55 -0000 Can you explain _why_? Why is it allowed to have all MAs send, lets say, a zero-length string as a Group-ID? Why is sending no Group-ID disallowed? My point is that the controller should define what it likes to see reported to collectors and we should not hardcode a policy here. /js On Mon, Oct 31, 2016 at 02:14:52PM +0000, MORTON, ALFRED C (AL) wrote: > I'd prefer to follow WG agreements captured in the > Framework RFC: > https://tools.ietf.org/html/rfc7594#section-5.4 > > where Report: [MA-ID &/or Group-ID],... > makes one or both of these IDs non-optional, > and this is consistent with Tim's 10/14 request below. > > regards, > Al > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > > Sent: Wednesday, October 26, 2016 2:51 PM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > > > > We are now a few days out from the Oct 31 cutoff for draft submissions. > > I > > have a few questions regarding the Information-model-11 draft. > > > > 1. Are we still at a deadlock on the ability for a controller to > > signal > > which ID for an MA to use in reporting discussion? > > > > 2. If so is there a plan forward or possible new design being > > contemplated behind the scenes? > > > > It would be nice to hear from more than just Time and Juergen in this > > discussion. Itıs pretty easy for two parties to reach a deadlock. It is > > much harder for 5 or 6 people so it would be nice if others want to see > > this draft progress to completion to weigh in on the discussion. > > > > Thanks, > > Jason > > > > On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - US)" > > wrote: > > > > >Juergen, > > > > > >Then suggest a design fix that allows the controller to tell the agent > > to > > >report one of the options: > > >1) Agent-ID > > >2) Group-ID > > >3) Agent-ID and Group-ID > > > > > >BR, > > >Tim > > > > > >-----Original Message----- > > >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > >Sent: Friday, October 14, 2016 3:50 AM > > >To: Carey, Timothy (Nokia - US) > > >Cc: lmap@ietf.org > > >Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) > > >wrote: > > >> Juergen, > > >> > > >> Because the service provider will want to correlate the results based > > >> on the MA or Group. > > > > > >Cool, the service provider can set things up accordingly. > > > > > >> I am for simplification as well - So long as we ensure at least one > > or > > >> the other is always reported - that was the intent. > > > > > >This violates the separation of policy from mechanism. You try to > > encode > > >a policy into a mechanism. I am against that. Having this flag > > >conditional adds complexity for no real value. Setting report-agent-id > > to > > >false and then sending agent-ids breaks the principle of least > > >astonishment. Creating a longer name to express that this flag has a > > >convoluted logic does not solve the issue. What if in the future even > > >more IDs are added? Sorry, this is simply bad design. > > > > > >> You can say that the report-agent value cannot be false unless a > > >> group-id is present... Maybe that makes it simpler. Agents will error > > >> otherwise upfront. > > > > > >No, it just shows that there is complexity without any real value. > > There > > >is nothing wrong with allowing no agent-id and no group-id - whether > > this > > >is useful is up to the controller (and > > >collector) to decide. (There are indeed other ways to identify results, > > >not reporting the agent-id for example is pointless if I tag all > > >schedules with an agent specific value.) > > > > > >Chairs, can you help resolve this? Document updates are blocked on > > this. > > > > > >/js > > > > > >-- > > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >Fax: +49 421 200 3103 > > > > > >_______________________________________________ > > >lmap mailing list > > >lmap@ietf.org > > >https://www.ietf.org/mailman/listinfo/lmap > > > > > > ________________________________ > > > > This E-mail and any of its attachments may contain Time Warner Cable > > proprietary information, which is privileged, confidential, or subject > > to copyright belonging to Time Warner Cable. This E-mail is intended > > solely for the use of the individual or entity to which it is addressed. > > If you are not the intended recipient of this E-mail, you are hereby > > notified that any dissemination, distribution, copying, or action taken > > in relation to the contents of and attachments to this E-mail is > > strictly prohibited and may be unlawful. If you have received this E- > > mail in error, please notify the sender immediately and permanently > > delete the original and any copy of this E-mail and any printout. > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 12:53:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0092129A94 for ; Mon, 31 Oct 2016 12:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ksds7mQf3hR for ; Mon, 31 Oct 2016 12:53:17 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D4129AA2 for ; Mon, 31 Oct 2016 12:53:16 -0700 (PDT) X-SENDER-IP: 10.64.163.159 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.31,428,1473134400"; d="scan'208";a="790965488" Received: from unknown (HELO exchpapp18.corp.twcable.com) ([10.64.163.159]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 31 Oct 2016 15:46:11 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp18.corp.twcable.com (10.64.163.159) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 31 Oct 2016 15:53:14 -0400 Received: from EXCHPAPP11.corp.twcable.com ([10.245.162.16]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1178.000; Mon, 31 Oct 2016 15:53:14 -0400 From: "Weil, Jason" To: Juergen Schoenwaelder , "Carey, Timothy (Nokia - US)" Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIx0av147j0G/a06SEtMBGa7zuaCiUWAAgAAJLwCAAARNAIAABfWAgAABrgCAAAJLAIAAAf+AgAWBz4CAACiJAIAbRNwA///AnQA= Date: Mon, 31 Oct 2016 19:53:14 +0000 Message-ID: References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031194006.GA39440@elstar.local> In-Reply-To: <20161031194006.GA39440@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22670.005 x-tm-as-result: No--52.376800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 19:53:26 -0000 Juergen, If Tim agrees, could we get this into -12 of the Info Model draft today before the cutoff? Tim, does this work for you? Others members of course should weigh in if you disagree. Jason On 10/31/16, 3:40 PM, "lmap on behalf of Juergen Schoenwaelder" wrote: >Tim, > >the obvious solution is to add a boolean report-group-id and the two >booleans report-agent-id and report-group-id determine whether the >agent-id or the group-id (if available) is reported. It is up to the >policy of the controller to set them. No side effects or >inter-dependencies. > >/js > >On Fri, Oct 14, 2016 at 11:14:38AM +0000, Carey, Timothy (Nokia - US) >wrote: >> Juergen, >> >> Then suggest a design fix that allows the controller to tell the agent >>to report one of the options: >> 1) Agent-ID >> 2) Group-ID >> 3) Agent-ID and Group-ID >> >> BR, >> Tim >> >> -----Original Message----- >> From: Juergen Schoenwaelder >>[mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, October 14, 2016 3:50 AM >> To: Carey, Timothy (Nokia - US) >> Cc: lmap@ietf.org >> Subject: Re: [lmap] optional leafs due to sensitity concerns >> >> On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) >>wrote: >> > Juergen, >> > >> > Because the service provider will want to correlate the results based >> > on the MA or Group. >> >> Cool, the service provider can set things up accordingly. >> >> > I am for simplification as well - So long as we ensure at least one >>or >> > the other is always reported - that was the intent. >> >> This violates the separation of policy from mechanism. You try to >>encode a policy into a mechanism. I am against that. Having this flag >>conditional adds complexity for no real value. Setting report-agent-id >>to false and then sending agent-ids breaks the principle of least >>astonishment. Creating a longer name to express that this flag has a >>convoluted logic does not solve the issue. What if in the future even >>more IDs are added? Sorry, this is simply bad design. >> >> > You can say that the report-agent value cannot be false unless a >> > group-id is present... Maybe that makes it simpler. Agents will error >> > otherwise upfront. >> >> No, it just shows that there is complexity without any real value. >>There is nothing wrong with allowing no agent-id and no group-id - >>whether this is useful is up to the controller (and >> collector) to decide. (There are indeed other ways to identify results, >>not reporting the agent-id for example is pointless if I tag all >>schedules with an agent specific value.) >> >> Chairs, can you help resolve this? Document updates are blocked on this. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Oct 31 13:03:43 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD1129AD2 for ; Mon, 31 Oct 2016 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95H4QUdTFvIk for ; Mon, 31 Oct 2016 13:03:38 -0700 (PDT) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 08AF4129AB0 for ; Mon, 31 Oct 2016 13:03:37 -0700 (PDT) X-SENDER-IP: 10.64.163.160 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.31,428,1473134400"; d="scan'208,217";a="1222639267" Received: from unknown (HELO exchpapp19.corp.twcable.com) ([10.64.163.160]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 31 Oct 2016 15:52:49 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp19.corp.twcable.com (10.64.163.160) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 31 Oct 2016 16:03:36 -0400 Received: from EXCHPAPP11.corp.twcable.com ([10.245.162.16]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1178.000; Mon, 31 Oct 2016 16:03:36 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Thread-Topic: IETF 97 Draft Agenda Posted Thread-Index: AQHSM7HcrBlgYjnZ3kiu1mYGi2LTTw== Date: Mon, 31 Oct 2016 20:03:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22670.005 x-tm-as-result: No--41.982900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D43D1BD6642E2jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF 97 Draft Agenda Posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:03:39 -0000 --_000_D43D1BD6642E2jasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed agenda for IETF 97 in Seoul taking place on Thursday, November= 17 at 13:30 KST has been uploaded to datatracker. Please let me know if yo= u would like to request an additional slot on the agenda or would like to s= uggest changes (time or presenter) to the currently proposed agenda. Link to the Draft Agenda: https://www.ietf.org/proceedings/97/agenda/agenda-97-lmap-00 Thanks, Jason & Dan ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D43D1BD6642E2jasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The proposed agenda for IETF 97 in Seoul taking place on Thursday, Nov= ember 17 at 13:30 KST has been uploaded to datatracker. Please let me know = if you would like to request an additional slot on the agenda or would like= to suggest changes (time or presenter) to the currently proposed agenda. 

Link to the Draft Agenda:

Thanks,
Jason & Dan


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
 --_000_D43D1BD6642E2jasonweiltwcablecom_-- From nobody Mon Oct 31 13:35:09 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA588129483 for ; Mon, 31 Oct 2016 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSYvHTAKEf7V for ; Mon, 31 Oct 2016 13:35:06 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 78552129AC3 for ; Mon, 31 Oct 2016 13:35:05 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 7987D46C01881; Mon, 31 Oct 2016 20:35:01 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u9VKZ3MJ024288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2016 20:35:03 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u9VKX7NV003276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2016 20:35:03 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Mon, 31 Oct 2016 16:33:30 -0400 From: "Carey, Timothy (Nokia - US)" To: "Weil, Jason" , Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4CAAEaKAP//vaKQALjFi4AAA1nKEANqUtYAAAB1bAAABwNYoA== Date: Mon, 31 Oct 2016 20:33:29 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7B7AD6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173816.GD29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79151B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031194006.GA39440@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:35:08 -0000 With the caveat that at least that either one of the Booleans is True so th= at at least one of the values is reported. BR, Tim -----Original Message----- From: Weil, Jason [mailto:jason.weil@twcable.com]=20 Sent: Monday, October 31, 2016 2:53 PM To: Juergen Schoenwaelder ; Carey, Ti= mothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] optional leafs due to sensitity concerns Juergen, If Tim agrees, could we get this into -12 of the Info Model draft today bef= ore the cutoff? Tim, does this work for you? Others members of course should weigh in if you disagree. Jason On 10/31/16, 3:40 PM, "lmap on behalf of Juergen Schoenwaelder" wrote: >Tim, > >the obvious solution is to add a boolean report-group-id and the two=20 >booleans report-agent-id and report-group-id determine whether the=20 >agent-id or the group-id (if available) is reported. It is up to the=20 >policy of the controller to set them. No side effects or=20 >inter-dependencies. > >/js > >On Fri, Oct 14, 2016 at 11:14:38AM +0000, Carey, Timothy (Nokia - US) >wrote: >> Juergen, >> >> Then suggest a design fix that allows the controller to tell the=20 >>agent to report one of the options: >> 1) Agent-ID >> 2) Group-ID >> 3) Agent-ID and Group-ID >> >> BR, >> Tim >> >> -----Original Message----- >> From: Juergen Schoenwaelder >>[mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, October 14, 2016 3:50 AM >> To: Carey, Timothy (Nokia - US) >> Cc: lmap@ietf.org >> Subject: Re: [lmap] optional leafs due to sensitity concerns >> >> On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) >>wrote: >> > Juergen, >> > >> > Because the service provider will want to correlate the results=20 >> > based on the MA or Group. >> >> Cool, the service provider can set things up accordingly. >> >> > I am for simplification as well - So long as we ensure at least one >>or >> > the other is always reported - that was the intent. >> >> This violates the separation of policy from mechanism. You try to=20 >>encode a policy into a mechanism. I am against that. Having this flag=20 >>conditional adds complexity for no real value. Setting report-agent-id=20 >>to false and then sending agent-ids breaks the principle of least=20 >>astonishment. Creating a longer name to express that this flag has a=20 >>convoluted logic does not solve the issue. What if in the future even=20 >>more IDs are added? Sorry, this is simply bad design. >> >> > You can say that the report-agent value cannot be false unless a=20 >> > group-id is present... Maybe that makes it simpler. Agents will=20 >> > error otherwise upfront. >> >> No, it just shows that there is complexity without any real value. >>There is nothing wrong with allowing no agent-id and no group-id -=20 >>whether this is useful is up to the controller (and >> collector) to decide. (There are indeed other ways to identify=20 >>results, not reporting the agent-id for example is pointless if I tag=20 >>all schedules with an agent specific value.) >> >> Chairs, can you help resolve this? Document updates are blocked on this. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Oct 31 13:54:42 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC2129ADD for ; Mon, 31 Oct 2016 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUevpvgLf-OY for ; Mon, 31 Oct 2016 13:54:38 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 AC0BF129AA9 for ; Mon, 31 Oct 2016 13:54:38 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 24B5283017B69; Mon, 31 Oct 2016 20:54:35 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u9VKsb09009670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2016 20:54:37 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u9VKqfIR029959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2016 20:54:37 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 31 Oct 2016 16:53:03 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8IAASYOA//+9PoCABcbwAP//5gbgA2fU64AABVi3kP//9CIAgAAIFrA= Date: Mon, 31 Oct 2016 20:53:01 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7B7B2C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010173320.GB29411@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791372@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031170242.GA39044@elstar.local> In-Reply-To: <20161031170242.GA39044@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:54:41 -0000 Juergen, As I understand it some SPs want to modify the device identifier to an iden= tifier that they understand. This is done in certain domains - for example = the devices serial number may not be what the SP uses to identify the devic= e so they designate one. So it does need to be part of the pre-config. It does not have to be part o= f the ma-config as the ma-config is between the controller and MA. The Framework RFC does talk about the fact that what you discussed in secti= on 5.1 As a result of the Bootstrapping process, the MA learns the following information ([LMAP-INFO] defines the consequent list of information elements): o its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses or both. This is followed up in the IM RFC in section 3.1 The MA may be pre-configured with an MA ID, or may use a Device ID in the first Controller contact before it is assigned an MA ID. The Device ID may be a MAC address or some other device identifier expressed as a URI. If the MA ID is not provided at this stage then it must be provided by the Controller during Configuration. So it looks like a bootstrap server may not configure the MA agent identifi= er but leave that to the controller. The only way it can then know the MA on first contact is through the device= ID which again the SP might need to configure. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 31, 2016 12:03 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? On Mon, Oct 31, 2016 at 04:47:38PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > You are indeed correct - if you are modelling the MA to Controller inform= ation elements you do not need the preconfiguration information elements.=20 > That is between the "bootstrap" system and the MA. The information model = provides the information elements of the Framework not just the MA to contr= oller information flows... > Just as the first sentence in the Abstract says.... > This Information Model applies to the Measurement Agent within a=20 > Large-Scale Measurement Platform. As such it outlines the information=20 > that is (pre-)configured on the Measurement Agent or exists in=20 > communications with a Controller or Collector within an LMAP=20 > framework. >=20 > All the pre-config does is outline what information is on the device - wh= ich of course the device ID is one element. > I am raising a technical argument, you respond with a formal argument. This= does not help to resolve the issue. A device has lots of information that = is not in the pre-config, some is listed in capability and status informati= on. Note that I have zero problem to report ma-status-device-id in ma-stat= us-obj. All I question is that the device-id is part of the LMAP ma-precon= fig-obj and the LMAP ma-config-obj. Note that this discussion was triggered by a comment Martin made when he wa= s reviewing the YANG data model. The YANG data model has this configurable = device-id because the info model has it and the info model has it because o= f this statement in the framework: As a result of the Bootstrapping process, the MA learns the following information ([LMAP-INFO] defines the consequent list of information elements): o its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses or both. I believe this sentence is wrong or its interpretation is wrong. I do think= the LMAP controller is in charge of assigning the MA-ID, I do not consider= it in charge to assign a device identifier. The bootstrap process may yiel= d one but the device identifier seems out of scope for the LMAP controller.= Note that there is additional text: The details of the Bootstrapping process are device/access specific. For example, the information could be in the firmware, manually configured, or transferred via a protocol like that described in TR-069 [TR-069]. There may be a multi-stage process where the MA contacts a 'hard-coded' address, which replies with the Bootstrapping information. Hence, I think we are not in any way violating the framework by not having = the device-id in ma-preconfig-obj or ma-config-obj in the LMAP information = model. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 14:16:08 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418D2129AFB for ; Mon, 31 Oct 2016 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqlj-621Ne_e for ; Mon, 31 Oct 2016 14:16:03 -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 16C5C129A33 for ; Mon, 31 Oct 2016 14:15:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6C6241582; Mon, 31 Oct 2016 22:15:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gkQH544FK1kg; Mon, 31 Oct 2016 22:15:54 +0100 (CET) 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; Mon, 31 Oct 2016 22:15:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90F3520046; Mon, 31 Oct 2016 22:15:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oo09nrwMbkeh; Mon, 31 Oct 2016 22:15:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4839520045; Mon, 31 Oct 2016 22:15:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FAD83D02338; Mon, 31 Oct 2016 22:15:52 +0100 (CET) Date: Mon, 31 Oct 2016 22:15:51 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161031211551.GA41685@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031170242.GA39044@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B7B2C@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7B7B2C@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:16:06 -0000 Tim, so you agree to remvoe the device-id from the ma-preconfig-obj and the ma-config-obj since the LMAP controller does not configure the device-id? Note that the device-id remains in ma-status-obj. The various status and capability objects enable the controller to learn what an MA can do, what kind of interfaces it has, etc. and all of this is not part of ma-preconfig-obj. In other words, if an MA contacts an LMAP controller for the first time, the controller likely will request the capability and status information (and with it get the device-id). /js On Mon, Oct 31, 2016 at 08:53:01PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > As I understand it some SPs want to modify the device identifier to an identifier that they understand. This is done in certain domains - for example the devices serial number may not be what the SP uses to identify the device so they designate one. > So it does need to be part of the pre-config. It does not have to be part of the ma-config as the ma-config is between the controller and MA. > > The Framework RFC does talk about the fact that what you discussed in section 5.1 > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): > > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. > > This is followed up in the IM RFC in section 3.1 > The MA may be pre-configured with an MA ID, or may use a Device ID in > the first Controller contact before it is assigned an MA ID. The > Device ID may be a MAC address or some other device identifier > expressed as a URI. If the MA ID is not provided at this stage then > it must be provided by the Controller during Configuration. > > So it looks like a bootstrap server may not configure the MA agent identifier but leave that to the controller. > The only way it can then know the MA on first contact is through the device ID which again the SP might need to configure. > > BR, > Tim > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 31, 2016 12:03 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the information model? > > On Mon, Oct 31, 2016 at 04:47:38PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > You are indeed correct - if you are modelling the MA to Controller information elements you do not need the preconfiguration information elements. > > That is between the "bootstrap" system and the MA. The information model provides the information elements of the Framework not just the MA to controller information flows... > > Just as the first sentence in the Abstract says.... > > This Information Model applies to the Measurement Agent within a > > Large-Scale Measurement Platform. As such it outlines the information > > that is (pre-)configured on the Measurement Agent or exists in > > communications with a Controller or Collector within an LMAP > > framework. > > > > All the pre-config does is outline what information is on the device - which of course the device ID is one element. > > > > I am raising a technical argument, you respond with a formal argument. This does not help to resolve the issue. A device has lots of information that is not in the pre-config, some is listed in capability and status information. Note that I have zero problem to report ma-status-device-id in ma-status-obj. All I question is that the device-id is part of the LMAP ma-preconfig-obj and the LMAP ma-config-obj. > > Note that this discussion was triggered by a comment Martin made when he was reviewing the YANG data model. The YANG data model has this configurable device-id because the info model has it and the info model has it because of this statement in the framework: > > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): > > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. > > I believe this sentence is wrong or its interpretation is wrong. I do think the LMAP controller is in charge of assigning the MA-ID, I do not consider it in charge to assign a device identifier. The bootstrap process may yield one but the device identifier seems out of scope for the LMAP controller. Note that there is additional text: > > The details of the Bootstrapping process are device/access specific. > For example, the information could be in the firmware, manually > configured, or transferred via a protocol like that described in > TR-069 [TR-069]. There may be a multi-stage process where the MA > contacts a 'hard-coded' address, which replies with the Bootstrapping > information. > > Hence, I think we are not in any way violating the framework by not having the device-id in ma-preconfig-obj or ma-config-obj in the LMAP information model. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 14:32:52 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCED129B41 for ; Mon, 31 Oct 2016 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDk7_Q8D7vjA for ; Mon, 31 Oct 2016 14:32:40 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 A7D98129B47 for ; Mon, 31 Oct 2016 14:32:40 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 9ACAF7B84A6EA; Mon, 31 Oct 2016 21:32:36 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9VLWdq1024380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2016 21:32:39 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9VLUifL007111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2016 21:32:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 31 Oct 2016 17:31:01 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] why do we have a configurable device-id in the information model? Thread-Index: AQHSIxzOcsZw56Vb/USTFtXs1WiteKCh9vTAgABmxgD//78G8IAASYOA//+9PoCABcbwAP//5gbgA2fU64AABVi3kP//9CIAgAAIFrCAAD6igIAAQhSQ Date: Mon, 31 Oct 2016 21:31:00 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7B7B85@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20161010195654.GB31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791698@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031170242.GA39044@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B7B2C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031211551.GA41685@elstar.local> In-Reply-To: <20161031211551.GA41685@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:32:47 -0000 Not the preconfig; just the ma-config. Again the pre-config doesn't come into play between the MA and controller i= nteraction. Why do you want to remove it from the pre-config - that's betwe= en the bootstrap server and the ma. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 31, 2016 4:16 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] why do we have a configurable device-id in the informat= ion model? Tim, so you agree to remvoe the device-id from the ma-preconfig-obj and the ma-c= onfig-obj since the LMAP controller does not configure the device-id? Note that the device-id remains in ma-status-obj. The various status and ca= pability objects enable the controller to learn what an MA can do, what kin= d of interfaces it has, etc. and all of this is not part of ma-preconfig-ob= j. In other words, if an MA contacts an LMAP controller for the first time,= the controller likely will request the capability and status information (= and with it get the device-id). /js On Mon, Oct 31, 2016 at 08:53:01PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > As I understand it some SPs want to modify the device identifier to an id= entifier that they understand. This is done in certain domains - for exampl= e the devices serial number may not be what the SP uses to identify the dev= ice so they designate one. > So it does need to be part of the pre-config. It does not have to be part= of the ma-config as the ma-config is between the controller and MA. >=20 > The Framework RFC does talk about the fact that what you discussed in sec= tion 5.1 > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): >=20 > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. >=20 > This is followed up in the IM RFC in section 3.1 The MA may be=20 > pre-configured with an MA ID, or may use a Device ID in the first=20 > Controller contact before it is assigned an MA ID. The Device ID may=20 > be a MAC address or some other device identifier expressed as a URI.=20 > If the MA ID is not provided at this stage then it must be provided by=20 > the Controller during Configuration. >=20 > So it looks like a bootstrap server may not configure the MA agent identi= fier but leave that to the controller. > The only way it can then know the MA on first contact is through the devi= ce ID which again the SP might need to configure. >=20 > BR, > Tim >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 31, 2016 12:03 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the inform= ation model? >=20 > On Mon, Oct 31, 2016 at 04:47:38PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > You are indeed correct - if you are modelling the MA to Controller info= rmation elements you do not need the preconfiguration information elements.= =20 > > That is between the "bootstrap" system and the MA. The information mode= l provides the information elements of the Framework not just the MA to con= troller information flows... > > Just as the first sentence in the Abstract says.... > > This Information Model applies to the Measurement Agent within a=20 > > Large-Scale Measurement Platform. As such it outlines the=20 > > information that is (pre-)configured on the Measurement Agent or=20 > > exists in communications with a Controller or Collector within an=20 > > LMAP framework. > >=20 > > All the pre-config does is outline what information is on the device - = which of course the device ID is one element. > > >=20 > I am raising a technical argument, you respond with a formal argument. Th= is does not help to resolve the issue. A device has lots of information tha= t is not in the pre-config, some is listed in capability and status informa= tion. Note that I have zero problem to report ma-status-device-id in ma-st= atus-obj. All I question is that the device-id is part of the LMAP ma-prec= onfig-obj and the LMAP ma-config-obj. >=20 > Note that this discussion was triggered by a comment Martin made when he = was reviewing the YANG data model. The YANG data model has this configurabl= e device-id because the info model has it and the info model has it because= of this statement in the framework: >=20 > As a result of the Bootstrapping process, the MA learns the following > information ([LMAP-INFO] defines the consequent list of information > elements): >=20 > o its identifier, either its MA-ID or a device identifier such as > one of its Media Access Control (MAC) addresses or both. >=20 > I believe this sentence is wrong or its interpretation is wrong. I do thi= nk the LMAP controller is in charge of assigning the MA-ID, I do not consid= er it in charge to assign a device identifier. The bootstrap process may yi= eld one but the device identifier seems out of scope for the LMAP controlle= r. Note that there is additional text: >=20 > The details of the Bootstrapping process are device/access specific. > For example, the information could be in the firmware, manually > configured, or transferred via a protocol like that described in > TR-069 [TR-069]. There may be a multi-stage process where the MA > contacts a 'hard-coded' address, which replies with the Bootstrapping > information. >=20 > Hence, I think we are not in any way violating the framework by not havin= g the device-id in ma-preconfig-obj or ma-config-obj in the LMAP informatio= n model. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 15:15:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4054E129B7F for ; Mon, 31 Oct 2016 15:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTLU5UFkFtIO for ; Mon, 31 Oct 2016 15:14:56 -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 9BB58129B83 for ; Mon, 31 Oct 2016 15:14:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 66DD01535; Mon, 31 Oct 2016 23:14:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U5-uNfg0rqYF; Mon, 31 Oct 2016 23:14:52 +0100 (CET) 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; Mon, 31 Oct 2016 23:14:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B1FE20046; Mon, 31 Oct 2016 23:14:53 +0100 (CET) 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 RHq9k0QRE6XR; Mon, 31 Oct 2016 23:14:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69C7B20045; Mon, 31 Oct 2016 23:14:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 498A03D02686; Mon, 31 Oct 2016 23:14:50 +0100 (CET) Date: Mon, 31 Oct 2016 23:14:49 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20161031221449.GA41899@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010202727.GB31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79178B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084150.GD42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AB6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031151207.GA38757@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B77E3@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031170242.GA39044@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B7B2C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031211551.GA41685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7B7B85@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7B7B85@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] why do we have a configurable device-id in the information model? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:14:58 -0000 Tim, there are many things to bootstrap which we do not talk about. I always looked at the ma-preconfig-obj as the subset of the ma-config-obj that needs to be present in order to connect to the LMAP controller. The ma-preconfig-obj is essentially a subset of the ma-config-obj described below. /js On Mon, Oct 31, 2016 at 09:31:00PM +0000, Carey, Timothy (Nokia - US) wrote: > Not the preconfig; just the ma-config. > > Again the pre-config doesn't come into play between the MA and controller interaction. Why do you want to remove it from the pre-config - that's between the bootstrap server and the ma. > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 31, 2016 4:16 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] why do we have a configurable device-id in the information model? > > Tim, > > so you agree to remvoe the device-id from the ma-preconfig-obj and the ma-config-obj since the LMAP controller does not configure the device-id? > > Note that the device-id remains in ma-status-obj. The various status and capability objects enable the controller to learn what an MA can do, what kind of interfaces it has, etc. and all of this is not part of ma-preconfig-obj. In other words, if an MA contacts an LMAP controller for the first time, the controller likely will request the capability and status information (and with it get the device-id). > > /js > > On Mon, Oct 31, 2016 at 08:53:01PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > As I understand it some SPs want to modify the device identifier to an identifier that they understand. This is done in certain domains - for example the devices serial number may not be what the SP uses to identify the device so they designate one. > > So it does need to be part of the pre-config. It does not have to be part of the ma-config as the ma-config is between the controller and MA. > > > > The Framework RFC does talk about the fact that what you discussed in section 5.1 > > As a result of the Bootstrapping process, the MA learns the following > > information ([LMAP-INFO] defines the consequent list of information > > elements): > > > > o its identifier, either its MA-ID or a device identifier such as > > one of its Media Access Control (MAC) addresses or both. > > > > This is followed up in the IM RFC in section 3.1 The MA may be > > pre-configured with an MA ID, or may use a Device ID in the first > > Controller contact before it is assigned an MA ID. The Device ID may > > be a MAC address or some other device identifier expressed as a URI. > > If the MA ID is not provided at this stage then it must be provided by > > the Controller during Configuration. > > > > So it looks like a bootstrap server may not configure the MA agent identifier but leave that to the controller. > > The only way it can then know the MA on first contact is through the device ID which again the SP might need to configure. > > > > BR, > > Tim > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 31, 2016 12:03 PM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] why do we have a configurable device-id in the information model? > > > > On Mon, Oct 31, 2016 at 04:47:38PM +0000, Carey, Timothy (Nokia - US) wrote: > > > Juergen, > > > > > > You are indeed correct - if you are modelling the MA to Controller information elements you do not need the preconfiguration information elements. > > > That is between the "bootstrap" system and the MA. The information model provides the information elements of the Framework not just the MA to controller information flows... > > > Just as the first sentence in the Abstract says.... > > > This Information Model applies to the Measurement Agent within a > > > Large-Scale Measurement Platform. As such it outlines the > > > information that is (pre-)configured on the Measurement Agent or > > > exists in communications with a Controller or Collector within an > > > LMAP framework. > > > > > > All the pre-config does is outline what information is on the device - which of course the device ID is one element. > > > > > > > I am raising a technical argument, you respond with a formal argument. This does not help to resolve the issue. A device has lots of information that is not in the pre-config, some is listed in capability and status information. Note that I have zero problem to report ma-status-device-id in ma-status-obj. All I question is that the device-id is part of the LMAP ma-preconfig-obj and the LMAP ma-config-obj. > > > > Note that this discussion was triggered by a comment Martin made when he was reviewing the YANG data model. The YANG data model has this configurable device-id because the info model has it and the info model has it because of this statement in the framework: > > > > As a result of the Bootstrapping process, the MA learns the following > > information ([LMAP-INFO] defines the consequent list of information > > elements): > > > > o its identifier, either its MA-ID or a device identifier such as > > one of its Media Access Control (MAC) addresses or both. > > > > I believe this sentence is wrong or its interpretation is wrong. I do think the LMAP controller is in charge of assigning the MA-ID, I do not consider it in charge to assign a device identifier. The bootstrap process may yield one but the device identifier seems out of scope for the LMAP controller. Note that there is additional text: > > > > The details of the Bootstrapping process are device/access specific. > > For example, the information could be in the firmware, manually > > configured, or transferred via a protocol like that described in > > TR-069 [TR-069]. There may be a multi-stage process where the MA > > contacts a 'hard-coded' address, which replies with the Bootstrapping > > information. > > > > Hence, I think we are not in any way violating the framework by not having the device-id in ma-preconfig-obj or ma-config-obj in the LMAP information model. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 15:24:41 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9071129B85 for ; Mon, 31 Oct 2016 15:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVS41XgqlX1q for ; Mon, 31 Oct 2016 15:24:38 -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 76C08129B4D for ; Mon, 31 Oct 2016 15:24:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C146CD1; Mon, 31 Oct 2016 23:24:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rDXkK5QqpCiH; Mon, 31 Oct 2016 23:24:35 +0100 (CET) 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; Mon, 31 Oct 2016 23:24:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4696820046; Mon, 31 Oct 2016 23:24:36 +0100 (CET) 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 Sbs5NRDDma_j; Mon, 31 Oct 2016 23:24:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB48820045; Mon, 31 Oct 2016 23:24:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D3AA83D027E1; Mon, 31 Oct 2016 23:24:34 +0100 (CET) Date: Mon, 31 Oct 2016 23:24:34 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20161031222434.GA41956@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "Weil, Jason" , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> <20161031195141.GB39440@elstar.local> <4D7F4AD313D3FC43A053B309F97543CF63165C@njmtexg4.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF63165C@njmtexg4.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" , "Weil, Jason" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:24:40 -0000 Al, why hardcore a requirement to send one of them? Which problem does this solve? I already pointed out before that tags, for example, may be used as a means to identify where a measurement is coming from. (There are in fact many ways to leak the identity of the agent.) /js On Mon, Oct 31, 2016 at 08:14:37PM +0000, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Monday, October 31, 2016 3:52 PM > > To: MORTON, ALFRED C (AL) > > Cc: Weil, Jason; Carey, Timothy (Nokia - US); lmap@ietf.org > > Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > Can you explain _why_? > > > > Why is it allowed to have all MAs send, lets say, a zero-length > > string as a Group-ID? > [ACM] > Although this is allowed, _why_ would any logical system behave this way? > > > Why is sending no Group-ID disallowed? > [ACM] > Sending no Group-ID _is_ allowed, when sending MA-ID alone. > That's what &/or allows. The report needs to contain one > of the forms of identity. > > Al > > > > > My point is that the controller should define what it likes to see > > reported to collectors and we should not hardcode a policy here. > > > > /js > > > > On Mon, Oct 31, 2016 at 02:14:52PM +0000, MORTON, ALFRED C (AL) wrote: > > > I'd prefer to follow WG agreements captured in the > > > Framework RFC: > > > https://tools.ietf.org/html/rfc7594#section-5.4 > > > > > > where Report: [MA-ID &/or Group-ID],... > > > makes one or both of these IDs non-optional, > > > and this is consistent with Tim's 10/14 request below. > > > > > > regards, > > > Al > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > > > > Sent: Wednesday, October 26, 2016 2:51 PM > > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > > > > > > > > > > > > We are now a few days out from the Oct 31 cutoff for draft > > submissions. > > > > I > > > > have a few questions regarding the Information-model-11 draft. > > > > > > > > 1. Are we still at a deadlock on the ability for a controller to > > > > signal > > > > which ID for an MA to use in reporting discussion? > > > > > > > > 2. If so is there a plan forward or possible new design being > > > > contemplated behind the scenes? > > > > > > > > It would be nice to hear from more than just Time and Juergen in > > this > > > > discussion. Itıs pretty easy for two parties to reach a deadlock. It > > is > > > > much harder for 5 or 6 people so it would be nice if others want to > > see > > > > this draft progress to completion to weigh in on the discussion. > > > > > > > > Thanks, > > > > Jason > > > > > > > > On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - > > US)" > > > > wrote: > > > > > > > > >Juergen, > > > > > > > > > >Then suggest a design fix that allows the controller to tell the > > agent > > > > to > > > > >report one of the options: > > > > >1) Agent-ID > > > > >2) Group-ID > > > > >3) Agent-ID and Group-ID > > > > > > > > > >BR, > > > > >Tim > > > > > > > > > >-----Original Message----- > > > > >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > >Sent: Friday, October 14, 2016 3:50 AM > > > > >To: Carey, Timothy (Nokia - US) > > > > >Cc: lmap@ietf.org > > > > >Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > > > > > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - > > US) > > > > >wrote: > > > > >> Juergen, > > > > >> > > > > >> Because the service provider will want to correlate the results > > based > > > > >> on the MA or Group. > > > > > > > > > >Cool, the service provider can set things up accordingly. > > > > > > > > > >> I am for simplification as well - So long as we ensure at least > > one > > > > or > > > > >> the other is always reported - that was the intent. > > > > > > > > > >This violates the separation of policy from mechanism. You try to > > > > encode > > > > >a policy into a mechanism. I am against that. Having this flag > > > > >conditional adds complexity for no real value. Setting report- > > agent-id > > > > to > > > > >false and then sending agent-ids breaks the principle of least > > > > >astonishment. Creating a longer name to express that this flag has > > a > > > > >convoluted logic does not solve the issue. What if in the future > > even > > > > >more IDs are added? Sorry, this is simply bad design. > > > > > > > > > >> You can say that the report-agent value cannot be false unless a > > > > >> group-id is present... Maybe that makes it simpler. Agents will > > error > > > > >> otherwise upfront. > > > > > > > > > >No, it just shows that there is complexity without any real value. > > > > There > > > > >is nothing wrong with allowing no agent-id and no group-id - > > whether > > > > this > > > > >is useful is up to the controller (and > > > > >collector) to decide. (There are indeed other ways to identify > > results, > > > > >not reporting the agent-id for example is pointless if I tag all > > > > >schedules with an agent specific value.) > > > > > > > > > >Chairs, can you help resolve this? Document updates are blocked on > > > > this. > > > > > > > > > >/js > > > > > > > > > >-- > > > > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > >Fax: +49 421 200 3103 > > > > > > > > > >_______________________________________________ > > > > >lmap mailing list > > > > >lmap@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > ________________________________ > > > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > > > proprietary information, which is privileged, confidential, or > > subject > > > > to copyright belonging to Time Warner Cable. This E-mail is intended > > > > solely for the use of the individual or entity to which it is > > addressed. > > > > If you are not the intended recipient of this E-mail, you are hereby > > > > notified that any dissemination, distribution, copying, or action > > taken > > > > in relation to the contents of and attachments to this E-mail is > > > > strictly prohibited and may be unlawful. If you have received this > > E- > > > > mail in error, please notify the sender immediately and permanently > > > > delete the original and any copy of this E-mail and any printout. > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 15:27:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C75129B87 for ; Mon, 31 Oct 2016 15:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qmJdfAWjIAY for ; Mon, 31 Oct 2016 15:27:23 -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 A8730129B4D for ; Mon, 31 Oct 2016 15:27: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 7230B1214; Mon, 31 Oct 2016 23:27:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G78Coff3KZvt; Mon, 31 Oct 2016 23:27:20 +0100 (CET) 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; Mon, 31 Oct 2016 23:27:20 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AADC320046; Mon, 31 Oct 2016 23:27:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yWSh2SjHeBhj; Mon, 31 Oct 2016 23:27:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDBCF20045; Mon, 31 Oct 2016 23:27:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BDAEF3D028BF; Mon, 31 Oct 2016 23:27:18 +0100 (CET) Date: Mon, 31 Oct 2016 23:27:18 +0100 From: Juergen Schoenwaelder To: "Weil, Jason" Message-ID: <20161031222718.GB41956@elstar.local> Mail-Followup-To: "Weil, Jason" , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161031194006.GA39440@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:27:24 -0000 Jason, I think we are running out of time to resolve this before the cutoff. So I will post what I have and we spin another version once we got things settled. /js On Mon, Oct 31, 2016 at 07:53:14PM +0000, Weil, Jason wrote: > Juergen, > > If Tim agrees, could we get this into -12 of the Info Model draft today > before the cutoff? > > Tim, does this work for you? > > Others members of course should weigh in if you disagree. > > Jason > > On 10/31/16, 3:40 PM, "lmap on behalf of Juergen Schoenwaelder" > > wrote: > > >Tim, > > > >the obvious solution is to add a boolean report-group-id and the two > >booleans report-agent-id and report-group-id determine whether the > >agent-id or the group-id (if available) is reported. It is up to the > >policy of the controller to set them. No side effects or > >inter-dependencies. > > > >/js > > > >On Fri, Oct 14, 2016 at 11:14:38AM +0000, Carey, Timothy (Nokia - US) > >wrote: > >> Juergen, > >> > >> Then suggest a design fix that allows the controller to tell the agent > >>to report one of the options: > >> 1) Agent-ID > >> 2) Group-ID > >> 3) Agent-ID and Group-ID > >> > >> BR, > >> Tim > >> > >> -----Original Message----- > >> From: Juergen Schoenwaelder > >>[mailto:j.schoenwaelder@jacobs-university.de] > >> Sent: Friday, October 14, 2016 3:50 AM > >> To: Carey, Timothy (Nokia - US) > >> Cc: lmap@ietf.org > >> Subject: Re: [lmap] optional leafs due to sensitity concerns > >> > >> On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - US) > >>wrote: > >> > Juergen, > >> > > >> > Because the service provider will want to correlate the results based > >> > on the MA or Group. > >> > >> Cool, the service provider can set things up accordingly. > >> > >> > I am for simplification as well - So long as we ensure at least one > >>or > >> > the other is always reported - that was the intent. > >> > >> This violates the separation of policy from mechanism. You try to > >>encode a policy into a mechanism. I am against that. Having this flag > >>conditional adds complexity for no real value. Setting report-agent-id > >>to false and then sending agent-ids breaks the principle of least > >>astonishment. Creating a longer name to express that this flag has a > >>convoluted logic does not solve the issue. What if in the future even > >>more IDs are added? Sorry, this is simply bad design. > >> > >> > You can say that the report-agent value cannot be false unless a > >> > group-id is present... Maybe that makes it simpler. Agents will error > >> > otherwise upfront. > >> > >> No, it just shows that there is complexity without any real value. > >>There is nothing wrong with allowing no agent-id and no group-id - > >>whether this is useful is up to the controller (and > >> collector) to decide. (There are indeed other ways to identify results, > >>not reporting the agent-id for example is pointless if I tag all > >>schedules with an agent specific value.) > >> > >> Chairs, can you help resolve this? Document updates are blocked on this. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 31 15:32:19 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E810A129992; Mon, 31 Oct 2016 15:32:17 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795313794.23217.15358328180744934565.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 15:32:17 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-12.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:32:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-12.txt Pages : 53 Date : 2016-10-31 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-12 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 Oct 31 15:33:32 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FCD1297C4; Mon, 31 Oct 2016 15:33:27 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795320749.23217.16283833591039301649.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 15:33:27 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:33:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-06.txt Pages : 63 Date : 2016-10-31 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-06 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 Oct 31 15:59:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128CB129992 for ; Mon, 31 Oct 2016 15:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReexITlSZG2T for ; Mon, 31 Oct 2016 15:59:47 -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 F021C129BA2 for ; Mon, 31 Oct 2016 15:59:46 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9VKF8I8033119; Mon, 31 Oct 2016 16:16:26 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 26ebafej3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Oct 2016 16:16:25 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VKGNvY080979; Mon, 31 Oct 2016 15:16:23 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VKGHjb080871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 15:16:19 -0500 Received: from tlpd252.dadc.sbc.com (tlpd252.dadc.sbc.com [135.31.184.157]) by dalint02.pst.cso.att.com (RSA Interceptor); Mon, 31 Oct 2016 20:16:04 GMT Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VKFnkf086355; Mon, 31 Oct 2016 15:15:49 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id u9VKEilg084182; Mon, 31 Oct 2016 15:14:49 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 2118CE0521; Mon, 31 Oct 2016 16:14:38 -0400 (EDT) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 16:14:38 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Thread-Topic: [lmap] optional leafs due to sensitity concerns Thread-Index: AQHSIyiiPEf+Q4Zhfki7Gxua8iY3V6CiC3fQgABPAQD//74zsIAATA+A//+9b4CAAEaKAP//vaKQALjFi4AAA1nKEAJtKV2AAOjdqAAAFLNhgAAH8mPA Date: Mon, 31 Oct 2016 20:14:37 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF63165C@njmtexg4.research.att.com> References: <20161010194533.GA31698@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A79161F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010202217.GA31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A791735@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161010203630.GC31876@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7917BE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20161014084933.GE42729@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A796AEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4D7F4AD313D3FC43A053B309F97543CF630D2D@njmtexg4.research.att.com> <20161031195141.GB39440@elstar.local> In-Reply-To: <20161031195141.GB39440@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.219.121] Content-Type: text/plain; charset="iso-8859-1" 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=2016-10-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610310357 Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" , "Weil, Jason" Subject: Re: [lmap] optional leafs due to sensitity concerns X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:59:49 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, October 31, 2016 3:52 PM > To: MORTON, ALFRED C (AL) > Cc: Weil, Jason; Carey, Timothy (Nokia - US); lmap@ietf.org > Subject: Re: [lmap] optional leafs due to sensitity concerns >=20 > Can you explain _why_? >=20 > Why is it allowed to have all MAs send, lets say, a zero-length > string as a Group-ID?=20 [ACM]=20 Although this is allowed, _why_ would any logical system behave this way? > Why is sending no Group-ID disallowed? [ACM]=20 Sending no Group-ID _is_ allowed, when sending MA-ID alone. That's what &/or allows. The report needs to contain one of the forms of identity. Al >=20 > My point is that the controller should define what it likes to see > reported to collectors and we should not hardcode a policy here. >=20 > /js >=20 > On Mon, Oct 31, 2016 at 02:14:52PM +0000, MORTON, ALFRED C (AL) wrote: > > I'd prefer to follow WG agreements captured in the > > Framework RFC: > > https://tools.ietf.org/html/rfc7594#section-5.4 > > > > where Report: [MA-ID &/or Group-ID],... > > makes one or both of these IDs non-optional, > > and this is consistent with Tim's 10/14 request below. > > > > regards, > > Al > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > > > Sent: Wednesday, October 26, 2016 2:51 PM > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > > > > > > > > We are now a few days out from the Oct 31 cutoff for draft > submissions. > > > I > > > have a few questions regarding the Information-model-11 draft. > > > > > > 1. Are we still at a deadlock on the ability for a controller to > > > signal > > > which ID for an MA to use in reporting discussion? > > > > > > 2. If so is there a plan forward or possible new design being > > > contemplated behind the scenes? > > > > > > It would be nice to hear from more than just Time and Juergen in > this > > > discussion. It=B9s pretty easy for two parties to reach a deadlock. I= t > is > > > much harder for 5 or 6 people so it would be nice if others want to > see > > > this draft progress to completion to weigh in on the discussion. > > > > > > Thanks, > > > Jason > > > > > > On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - > US)" > > > wrote: > > > > > > >Juergen, > > > > > > > >Then suggest a design fix that allows the controller to tell the > agent > > > to > > > >report one of the options: > > > >1) Agent-ID > > > >2) Group-ID > > > >3) Agent-ID and Group-ID > > > > > > > >BR, > > > >Tim > > > > > > > >-----Original Message----- > > > >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > >Sent: Friday, October 14, 2016 3:50 AM > > > >To: Carey, Timothy (Nokia - US) > > > >Cc: lmap@ietf.org > > > >Subject: Re: [lmap] optional leafs due to sensitity concerns > > > > > > > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia - > US) > > > >wrote: > > > >> Juergen, > > > >> > > > >> Because the service provider will want to correlate the results > based > > > >> on the MA or Group. > > > > > > > >Cool, the service provider can set things up accordingly. > > > > > > > >> I am for simplification as well - So long as we ensure at least > one > > > or > > > >> the other is always reported - that was the intent. > > > > > > > >This violates the separation of policy from mechanism. You try to > > > encode > > > >a policy into a mechanism. I am against that. Having this flag > > > >conditional adds complexity for no real value. Setting report- > agent-id > > > to > > > >false and then sending agent-ids breaks the principle of least > > > >astonishment. Creating a longer name to express that this flag has > a > > > >convoluted logic does not solve the issue. What if in the future > even > > > >more IDs are added? Sorry, this is simply bad design. > > > > > > > >> You can say that the report-agent value cannot be false unless a > > > >> group-id is present... Maybe that makes it simpler. Agents will > error > > > >> otherwise upfront. > > > > > > > >No, it just shows that there is complexity without any real value. > > > There > > > >is nothing wrong with allowing no agent-id and no group-id - > whether > > > this > > > >is useful is up to the controller (and > > > >collector) to decide. (There are indeed other ways to identify > results, > > > >not reporting the agent-id for example is pointless if I tag all > > > >schedules with an agent specific value.) > > > > > > > >Chairs, can you help resolve this? Document updates are blocked on > > > this. > > > > > > > >/js > > > > > > > >-- > > > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > >Fax: +49 421 200 3103 > > > > > > > >_______________________________________________ > > > >lmap mailing list > > > >lmap@ietf.org > > > >https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > ________________________________ > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > > proprietary information, which is privileged, confidential, or > subject > > > to copyright belonging to Time Warner Cable. This E-mail is intended > > > solely for the use of the individual or entity to which it is > addressed. > > > If you are not the intended recipient of this E-mail, you are hereby > > > notified that any dissemination, distribution, copying, or action > taken > > > in relation to the contents of and attachments to this E-mail is > > > strictly prohibited and may be unlawful. If you have received this > E- > > > mail in error, please notify the sender immediately and permanently > > > delete the original and any copy of this E-mail and any printout. > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103