From nobody Tue Feb 3 02:08:57 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5831A8741 for ; Tue, 3 Feb 2015 02:08:56 -0800 (PST) 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 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 qGo1dYHyE2mh for ; Tue, 3 Feb 2015 02:08:54 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A30A1A008C for ; Tue, 3 Feb 2015 02:08:53 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 3 Feb 2015 10:08:58 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.190]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 3 Feb 2015 10:08:22 +0000 From: To: , Date: Tue, 3 Feb 2015 10:08:22 +0000 Thread-Topic: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQMMmRHuSVv7mMnEmea+HAnj8NKZzBRO0QgB1+9kg= Message-ID: References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com>, <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2015 10:08:57 -0000 Barbara, Tim, thank-you for the draft! here are a few comments, plus some follow-ups on t= he thread discussing Joan's comments. << Following is a list of criteria that a Control Protocol is required to support. Protocols that do not support these criteria will not be considered appropriate for selection as a Control Protocol. Note that although the protocol may support the criterion, it is not necessarily the case that the criterion is mandatory to implement according to the protocol specification. >> [phil] I found the last sentence quite hard to parse. I think the para mean= s that the protocol must fulfil the criteria, but it is not mandatory-to-im= plement. I admit to preferring MTI. If not, the protocol must define what happens if= (say) the controller has implemented and the MA hasn't. Perhaps this is si= mple to do, as we assume a managed environment where the measuremnt system = has deployed the controller and MAs? << CP-MUST-1 There must be a mechanism that allows a Controller to cause a session to be established with a MA. CP-MUST-2 There must be a mechanism that allows a MA to cause a session to be established with a Controller. >> [phil] I think "cause a session to be established" is a bit ambiguous. If I= remember our discusisons in Dublin, I think this is not referring to Boots= trapping. we assume that the MA is integrated into the measuremnt system.=20 this requirement means that the Controller must be able to send an Instruct= ion to the MA, and the MA must be able to inform the Controller about its F= ailure and Logging Information (and Capabilities) (without an explicit requ= est from the Controller) I would think versioning is a requirement; extensibility is comparati= ve. [phil] I agree - a protocol must have versioning.=20 << CP-MUST-3 The protocol session must be capable of being secured using certificates, as described in [I-D.ietf-lmap-framework]. >> [phil] The framework gives certificates as an example mechanism. I'd be hap= py for certificates to be a MUST. << CP-DIFF-7 How widely used is the protocol and/or its protocol elements in mass market devices? (widely is better) >> I agree with the sentiment of this criteria (and the similar RP-DIFF-6). It= seems important that we either re-use a protocol that's widely used, or th= at we build on an underlying, widely used protocol in some simple fashion. = We certainly don't want to invent something from scratch. There seem quite = important assessment around what's being added to an existing protocol (or = protocol elements) and whether they're widely used or about to be.=20 << CP-DIFF-8 What mechanisms exist to ensure interoperability of MA and Controller implementations? (existence of something is better) >> I think interoperability is critical. To me it is the key reason for specif= ying the protocol.=20 > RP-DIFF-4 Personally, would like to see compression mandatory=20 > depending on the amount of data. What do others think? I have no strong opinion. Again this is more of a requirement that would need to be placed on a= protocol; like versioning. We aren't creating requirements for a protocol = but for comparing and selecting protocols. So again if we are saying we wil= l not select a protocol that doesn't provide a compression capability then = it should be a requirement not a comparative criteria. I don't think compre= ssion elevates to that "status". It is important though. [phil] I don't think compression of reports is mandatory. For example, ther= e may be very simple MAs that don't do this. Not sure that current systems = do compression. Also, if a measurement system wants to compress reports, su= rely it can just compress the content completely independently of the lmap = protocol, eg just zip it.=20 so in fact I wonder whether this requirement is needed. thanks phil ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H [bs7652@at= t.com] Sent: 15 January 2015 14:57 To: lmap@ietf.org Subject: [lmap] FW: New Version Notification for draft-starkcarey-lmap-prot= ocol-criteria-00.txt This is the draft that Tim Carey and I put together for LMAP protocol selec= tion criteria. It is taken from the slides we presented on the December tel= econference, with a few changes based on the discussion during that call. Barbara -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Thursday, January 15, 2015 8:46 AM To: STARK, BARBARA H; STARK, BARBARA H Subject: New Version Notification for draft-starkcarey-lmap-protocol-criter= ia-00.txt A new version of I-D, draft-starkcarey-lmap-protocol-criteria-00.txt has been successfully submitted by Barbara Stark and posted to the IETF rep= ository. Name: draft-starkcarey-lmap-protocol-criteria Revision: 00 Title: LMAP Protocol Selection Criteria Document date: 2015-01-15 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-starkcarey-lmap-p= rotocol-criteria-00.txt Status: https://datatracker.ietf.org/doc/draft-starkcarey-lmap-prot= ocol-criteria/ Htmlized: http://tools.ietf.org/html/draft-starkcarey-lmap-protocol-c= riteria-00 Abstract: This draft identifies criteria to be used in evaluating and selecting Control and Reporting Protocols described by [I-D.ietf-lmap-framework]. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From nobody Tue Feb 3 06:34:30 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C21A0469 for ; Tue, 3 Feb 2015 06:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbpeAZwQoJBh for ; Tue, 3 Feb 2015 06:34:24 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEAA1A040C for ; Tue, 3 Feb 2015 06:34:23 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id f6cd0d45.2b1d0c813940.356162.00-2407.992503.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 03 Feb 2015 14:34:23 +0000 (UTC) X-MXL-Hash: 54d0dc6f78154be9-43fb8167f22b771904f4197f5de7a8beb751488c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 06cd0d45.0.356009.00-2080.992057.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 03 Feb 2015 14:34:09 +0000 (UTC) X-MXL-Hash: 54d0dc613f5f51be-3a6c1330cd6508acea182bab67eb1340aa8a4ee0 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 t13EY7NB010940; Tue, 3 Feb 2015 09:34:07 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t13EY4FX010916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Feb 2015 09:34:04 -0500 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 3 Feb 2015 14:33:45 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 09:33:44 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQMMmRHuSVv7mMnEmea+HAnj8NKZzBRO0QgB1+9kiAAEu5kA== Date: Tue, 3 Feb 2015 14:33:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F1130F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com>, <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.244.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IaswrxWa c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5ig7IJPYKDAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=A9CBlGWkp] X-AnalysisOut: [Fa3BxTYc7UA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2015 14:34:28 -0000 Hi Phil, Thanks. In-line. Barbara > << Following is a list of criteria that a Control Protocol is required > to support. Protocols that do not support these criteria will not be > considered appropriate for selection as a Control Protocol. Note > that although the protocol may support the criterion, it is not > necessarily the case that the criterion is mandatory to implement > according to the protocol specification. > >> > [phil] I found the last sentence quite hard to parse. I think the para me= ans > that the protocol must fulfil the criteria, but it is not mandatory-to- > implement. > I admit to preferring MTI. If not, the protocol must define what happens = if > (say) the controller has implemented and the MA hasn't. Perhaps this is > simple to do, as we assume a managed environment where the measuremnt > system has deployed the controller and MAs? I would absolutely envision LMAP making these criteria mandatory to i= mplement (MTI) in any protocol LMAP selects (if using protocol X for LMAP, = then criterion is MTI). But I don't think it's necessary for non-LMAP imple= mentations or usages of a protocol to meet the LMAP criteria. As long as th= e protocol says how to do it in the context of the protocol, I'm satisfied = that LMAP can easily mandate it. If it is MTI in the protocol itself, that'= s fine, too. Then LMAP doesn't have to mandate it. > << CP-MUST-1 There must be a mechanism that allows a Controller to > cause a session to be established with a MA. > CP-MUST-2 There must be a mechanism that allows a MA to cause a > session to be established with a Controller. > >> > [phil] I think "cause a session to be established" is a bit ambiguous. If= I > remember our discusisons in Dublin, I think this is not referring to > Bootstrapping. we assume that the MA is integrated into the measuremnt > system. > this requirement means that the Controller must be able to send an > Instruction to the MA, and the MA must be able to inform the Controller > about its Failure and Logging Information (and Capabilities) (without an > explicit request from the Controller) This is not referring to bootstrapping. If a Controller needs to send= a new Instruction to an MA *now*, then there has to be some way for the Co= ntroller to initiate that. We don't want the Controller to have to wait unt= il the next scheduled time the MA contacts the Controller, before this Inst= ruction can be sent. Likewise, if the MA needs to send something to the Con= troller *now*, the MA needs to be able to initiate that. When I look at som= e SNMP implementations, there's no ability for the SNMP Client to initiate = communication with the SNMP server ("hey, server, I need to talk to you *no= w*"). Some other protocols may rely completely on the managed endpoint alwa= ys initiating communication, with no mechanism for the server to initiate a= nything. Such protocols would fail these criteria. As a more concrete examp= le, TR-069 requires the HTTPS/TCP sessions to be initiated by the managed e= ndpoint. This would meet the 2nd criterion, but does nothing for the first.= TR-069 also has a management server message that allows the server to send= a message of "initiate a session with your management server *now*". This = message doesn't actually establish the session (i.e., the client doesn't re= ply directly to this message), but the client does try to initiate a sessio= n when it gets this message. Independent of whether a protocol is "pull" or= "push", either endpoint has to be able to cause communications to start. =20 > I would think versioning is a requirement; extensibility is compara= tive. > [phil] I agree - a protocol must have versioning. OK. I'll move the versioning criteria to the mandatory set. =20 > << CP-MUST-3 The protocol session must be capable of being secured > using certificates, as described in > [I-D.ietf-lmap-framework]. > >> > [phil] The framework gives certificates as an example mechanism. I'd be > happy for certificates to be a MUST. OK. I agree. And if we need to word this differently, I'm happy to do= so. This came out of some of the discussion we had on the call where we we= re talking about what references to use that would describe what was being = required here. =20 > << CP-DIFF-7 How widely used is the protocol and/or its protocol > elements in mass market devices? (widely is better) > >> > I agree with the sentiment of this criteria (and the similar RP-DIFF-6). = It > seems important that we either re-use a protocol that's widely used, or t= hat > we build on an underlying, widely used protocol in some simple fashion. W= e > certainly don't want to invent something from scratch. There seem quite > important assessment around what's being added to an existing protocol (o= r > protocol elements) and whether they're widely used or about to be. >=20 > << CP-DIFF-8 What mechanisms exist to ensure interoperability of MA > and Controller implementations? (existence of something > is better) > >> > I think interoperability is critical. To me it is the key reason for spec= ifying the > protocol. >=20 > > RP-DIFF-4 Personally, would like to see compression mandatory > > depending on the amount of data. > What do others think? I have no strong opinion. > Again this is more of a requirement that would need to be placed on= a > protocol; like versioning. We aren't creating requirements for a protocol= but > for comparing and selecting protocols. So again if we are saying we will = not > select a protocol that doesn't provide a compression capability then it s= hould > be a requirement not a comparative criteria. I don't think compression > elevates to that "status". It is important though. > [phil] I don't think compression of reports is mandatory. For example, th= ere > may be very simple MAs that don't do this. Not sure that current systems = do > compression. Also, if a measurement system wants to compress reports, > surely it can just compress the content completely independently of the > lmap protocol, eg just zip it. > so in fact I wonder whether this requirement is needed. I'm fine with not making it mandatory. But I definitely want it as a = comparative criterion. How much weight it gets remains to be seen. From nobody Tue Feb 3 06:44:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB81A0439 for ; Tue, 3 Feb 2015 06:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coYeLgl9J8PF for ; Tue, 3 Feb 2015 06:43:57 -0800 (PST) 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 3EC7C1A0636 for ; Tue, 3 Feb 2015 06:43:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E08981AB4; Tue, 3 Feb 2015 15:43:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vaulEkfRmbsJ; Tue, 3 Feb 2015 15:43:47 +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; Tue, 3 Feb 2015 15:43:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3350A20038; Tue, 3 Feb 2015 15:43: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 oy6N4i3oDSsP; Tue, 3 Feb 2015 15:43:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB26C20035; Tue, 3 Feb 2015 15:43:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D985D315F1DF; Tue, 3 Feb 2015 15:43:52 +0100 (CET) Date: Tue, 3 Feb 2015 15:43:52 +0100 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20150203144352.GA77854@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130F1130F@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F1130F@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 03 Feb 2015 14:44:00 -0000 On Tue, Feb 03, 2015 at 02:33:44PM +0000, STARK, BARBARA H wrote: > > This is not referring to bootstrapping. If a Controller needs to send a new Instruction to an MA *now*, then there has to be some way for the Controller to initiate that. We don't want the Controller to have to wait until the next scheduled time the MA contacts the Controller, before this Instruction can be sent. Likewise, if the MA needs to send something to the Controller *now*, the MA needs to be able to initiate that. When I look at some SNMP implementations, there's no ability for the SNMP Client to initiate communication with the SNMP server ("hey, server, I need to talk to you *now*"). SNMP had notifications from day one. And implementation of SNMP that does not support notifications is broken. That said, the real issue here are NATs. Yes, it would be great if both parties could initiate communication at any point in time. But in reality, middleboxes may prevent that from happening. So is this requirement to addressed without middleboxes in the way or does address this requirement requires a solution that works around middleboxes? /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 Tue Feb 3 06:58:23 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366611A03A7 for ; Tue, 3 Feb 2015 06:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QekETQZ4RfJ for ; Tue, 3 Feb 2015 06:58:19 -0800 (PST) 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 048361A0065 for ; Tue, 3 Feb 2015 06:58:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F750122D for ; Tue, 3 Feb 2015 15:58:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aMWTHsCAkcgn for ; Tue, 3 Feb 2015 15:58: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 for ; Tue, 3 Feb 2015 15:58:16 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C93CC20035 for ; Tue, 3 Feb 2015 15:58:16 +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 KdlZ6stZEbZH; Tue, 3 Feb 2015 15:58:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB34B20037; Tue, 3 Feb 2015 15:58:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0CDED315F42C; Tue, 3 Feb 2015 15:58:16 +0100 (CET) Date: Tue, 3 Feb 2015 15:58:15 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150203145815.GB77854@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.4.2.3i Archived-At: Subject: [lmap] protocol selection criteria questions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 03 Feb 2015 14:58:21 -0000 Hi, a couple of questions that may be needed to answer before it is possible to answer some of the questions: - How is 'complete instruction set' defined? - How is 'status update' defined? - How do you define overhead? If protocol X encodes instructions in say JSON but protocol Y encodes instructions in say XML, is the different encoding considered in the overhead calculation or is the overhead strictly the protocol message overhead without the instruction / report encoding? - How is a 'report' defined? - Do we assume certain MTU sizes when we are asked to calculate # of messages? - Do we have to enable security for the calculation? - Do we care about the session establishment overhead? - Is it correct to assume that session establishment is not counted into things like CP-DIFF-1, CP-DIFF-2, CP-DIFF-5, CP-DIFF-6 etc. - How are we going to measure 'widely used'? - How about security layers that may do transparent compression before encryption - is it allow to enable such mechanisms or not? If we go down this path of protocol selection, we may end up having to sort out many little details... /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 Tue Feb 10 05:44:41 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A696D1A019B for ; Tue, 10 Feb 2015 05:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP4Q9JsHbTea for ; Tue, 10 Feb 2015 05:44:38 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2B41A011B for ; Tue, 10 Feb 2015 05:44:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAFEK2lSHCzIm/2dsb2JhbABCFwOCQyEiIjBaBIUDqzYBAQEBAQEGBZIeHQEIhXICgR5DAQEBAQEBfIQOAQEBAhIbOSUBFRUKBAw8JAIBBBsBGYgLAQw3qAqEf492kVMBAQgBAQEBAR2GBIkvEyEMHAeCFQxAHYEUBY8gg1GCEYRkNoJNgjyIYYM+IoMgTm8BAQGBQX4BAQE X-IronPort-AV: E=Sophos;i="5.09,550,1418101200"; d="scan'208,217";a="106210495" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Feb 2015 08:44:36 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Feb 2015 08:44:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 10 Feb 2015 14:44:34 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft agenda for the LMAP WG virtual interim on 2-12 Thread-Index: AdBFN7JtI/xgwU/eTR6yyf7TA3d48Q== Date: Tue, 10 Feb 2015 13:44:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9907CA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9907CAAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft agenda for the LMAP WG virtual interim on 2-12 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2015 13:44:40 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9907CAAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I uploaded the preliminary agenda of the WG interim scheduled for Thursday = 2/12 at http://www.ietf.org/proceedings/interim/2015/02/12/lmap/agenda/agen= da-interim-2015-lmap-1. The agenda includes updates and discussions about t= he use cases, information model (moved from the previous interim meeting), = selection criteria and YANG data model for LMAP measurement agents. We also= need to discuss the process we will use for the control and reporting prot= ocols selection. Comments and proposals for the agenda are welcome. As always we need two volunteers to take notes in order to start and conduc= t the meeting. Volunteering before the meeting is highly appreciated. If you plan to use any slides at the virtual interim please send these to m= e and Jason before the meeting, so that we can upload and make them availab= le for all. The logistics information about the meeting follows: LMAP Virtual Interim Meeting Thursday, February 12, 2015 12:00 pm | Eastern Standard Time (New York, GMT-05:00) | 2 hr Join WebEx meeting: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= ietf.webex.com_ietf_j.php-3FMTID-3Dm7f02a060d018e8c17780318de9084c6b&d=3DAw= ICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphp= BsFA&m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3D01FwIKl2v8eB3sQaE1= EVs-D0tbHSjJ7CDn8h3iX1xeY&e=3D Meeting number: 645 771 127 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 771 127 Tol= l-free calling restrictions: https://urldefense.proofpoint.com/v2/url?u=3Dh= ttp-3A__www.webex.com_pdf_tollfree-5Frestrictions.pdf&d=3DAwICaQ&c=3DBFpWQw= 8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D9KQf_s= ZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dd85E67WS8MdXR2TH3qmE7csbytLxN-3_I= OjHMTK3jus&e=3D Add this meeting to your calendar: https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__ietf.webex.com_ietf_j.php-3FMTID-3Dma1a9b1ecdacf17cbc99dff93= a9040d6a&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQ= fucBXRucPvdrphpBsFA&m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dg1J= 8KGa0g-StCdVExiM6FgnckXZejSMQ-gTGb4n4CcQ&e Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9907CAAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I uploaded the preliminary agenda of the WG interim = scheduled for Thursday 2/12 at http://www.ietf.org/proceedings/interim/2015= /02/12/lmap/agenda/agenda-interim-2015-lmap-1. The agenda includes updates = and discussions about the use cases, information model (moved from the previous interim meeting), selection cri= teria and YANG data model for LMAP measurement agents. We also need to disc= uss the process we will use for the control and reporting protocols selecti= on. Comments and proposals for the agenda are welcome.

 

As always we need two volunteers to take notes in or= der to start and conduct the meeting. Volunteering before the meeting is hi= ghly appreciated.

 

If you plan to use any slides at the virtual interim= please send these to me and Jason before the meeting, so that we can uploa= d and make them available for all.

 

The logistics information about the meeting follows:=

 

LMAP Virtual Interim Meeting

Thursday, February 12, 2015

12:00 pm  |  Eastern Standard Time (New= York, GMT-05:00)  |  2 hr

Join WebEx meeting: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ietf.webex.com_ietf_= j.php-3FMTID-3Dm7f02a060d018e8c17780318de9084c6b&d=3DAwICaQ&c=3DBFp= WQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&= ;m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3D01FwIKl2v8eB3sQaE1= EVs-D0tbHSjJ7CDn8h3iX1xeY&e=3D

Meeting number:     &nbs= p;      645 771 127

Meeting password:     &n= bsp;   1234

Join by phone

1-877-668-4493 Call-in toll free number (US/Canad= a)

1-650-479-3208 Call-in toll number (US/Canada) Ac= cess code: 645 771 127 Toll-free calling restrictions: https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.webex.com_pdf_tol= lfree-5Frestrictions.pdf&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&= r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D9KQf_sZbfpkkKPVid3H= myTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dd85E67WS8MdXR2TH3qmE7csbytLxN-3_IOjHMTK3ju= s&e=3D

 

Add this meeting to your calendar: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ietf.webex.com_ietf_= j.php-3FMTID-3Dma1a9b1ecdacf17cbc99dff93a9040d6a&d=3DAwICaQ&c=3DBFp= WQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&= ;m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dg1J8KGa0g-StCdVExi= M6FgnckXZejSMQ-gTGb4n4CcQ&e

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9907CAAZFFEXMB04globa_-- From nobody Tue Feb 10 17:49:43 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F1B1A1B17; Tue, 10 Feb 2015 17:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0_BqtSMXeYx; Tue, 10 Feb 2015 17:49:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7146D1A1B5C; Tue, 10 Feb 2015 17:49:32 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211014932.29081.2481.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 17:49:32 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:49:40 -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 Working Group of the IETF. Title : Large-Scale Broadband Measurement Use Cases Authors : Marc Linsner Philip Eardley Trevor Burbridge Frode Sorensen Filename : draft-ietf-lmap-use-cases-06.txt Pages : 17 Date : 2015-02-10 Abstract: Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model and protocol. This document details two use cases that can assist to developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-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 Tue Feb 10 17:49:48 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC52A1A1B17; Tue, 10 Feb 2015 17:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpVjNxJkGQr5; Tue, 10 Feb 2015 17:49:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A31EA1A1B5E; Tue, 10 Feb 2015 17:49:32 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211014932.29081.6491.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 17:49:32 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-use-cases-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:49:42 -0000 A new version (-06) has been submitted for draft-ietf-lmap-use-cases: http://www.ietf.org/internet-drafts/draft-ietf-lmap-use-cases-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-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. IETF Secretariat. From nobody Tue Feb 10 17:49:50 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2930B1A1B17; Tue, 10 Feb 2015 17:49:42 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC52A1A1B17; Tue, 10 Feb 2015 17:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpVjNxJkGQr5; Tue, 10 Feb 2015 17:49:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A31EA1A1B5E; Tue, 10 Feb 2015 17:49:32 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211014932.29081.6491.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 17:49:32 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-use-cases-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:49:42 -0000 A new version (-06) has been submitted for draft-ietf-lmap-use-cases: http://www.ietf.org/internet-drafts/draft-ietf-lmap-use-cases-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-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. IETF Secretariat. From nobody Tue Feb 10 17:52:27 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125EC1A066B for ; Tue, 10 Feb 2015 17:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVWzmT1_ySLI for ; Tue, 10 Feb 2015 17:52:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEB11A1B42 for ; Tue, 10 Feb 2015 17:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1071; q=dns/txt; s=iport; t=1423619542; x=1424829142; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=ZxA+O6CZWl3gcOLHjWGXTIioYaekMQb0FC99ZuF/2co=; b=OnjdANY0AxMb5JCHkj176rvBCvWmM7VfonoKa2j+e8GIQi81Eh6rH3j6 Mr6Mh9KXkMZX/I2K6qGhznY+jEHz0bh/H6Qt/wKxXAeoFfQU6NX17MyLS 5obESFUevKAf0HuTGNoWkH5/vyi2TNKdxE3wtNvS73rciZ4TjJjDRxRbO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFANu02lStJA2K/2dsb2JhbABbgwZSVQUEwxaFcQKBI0MBAQEBAQF8hAwBAQEDATo9BwsCARkDAQIfECERGwIIAgQTCYgQAwkICAXKbg2FQwEBAQEBAQQBAQEBAQEBAQEZjU2BfziDEIEUBY8gg1GEF4FGgRg2gk2IWIYDIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,554,1418083200"; d="scan'208";a="395180897" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 11 Feb 2015 01:52:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1B1qL9V025908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Feb 2015 01:52:21 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 19:52:21 -0600 From: "Marc Linsner (mlinsner)" To: "lmap@ietf.org" Thread-Topic: New Version Notification - draft-ietf-lmap-use-cases-06.txt Thread-Index: AQHQRZ0BJBE0SnIHkUuubkKyUFqgyw== Date: Wed, 11 Feb 2015 01:52:20 +0000 Message-ID: <5C043E8D-DC81-4C0C-88F1-035027EC81B6@cisco.com> References: <20150211014932.29081.6491.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.25.235] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] Fwd: New Version Notification - draft-ietf-lmap-use-cases-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2015 01:52:26 -0000 All, New version submitted to clear IESG comments/discusses. Marc, Phil, Frode, Trevor Begin forwarded message: > From: > Subject: New Version Notification - draft-ietf-lmap-use-cases-06.txt > Date: February 10, 2015 at 5:49:32 PM PST > To: , , , , , , >=20 >=20 > A new version (-06) has been submitted for draft-ietf-lmap-use-cases: > http://www.ietf.org/internet-drafts/draft-ietf-lmap-use-cases-06.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-use-cases-06 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. >=20 From nobody Tue Feb 10 21:19:51 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEA1A702F; Tue, 10 Feb 2015 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGtuzm_-x90Z; Tue, 10 Feb 2015 21:19:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2EC1A7015; Tue, 10 Feb 2015 21:19:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211051943.28956.51127.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 21:19:43 -0800 Archived-At: Cc: dromasca@avaya.com, draft-ietf-lmap-use-cases.all@ietf.org, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Pete Resnick's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 05:19:45 -0000 Pete Resnick has entered the following ballot position for draft-ietf-lmap-use-cases-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for an excellent set of edits. This addresses my earlier concerns about the regulator use case text being too politically charged and focuses the document on the real engineering concerns that regulators need addressed. Well done. From nobody Tue Feb 10 21:19:53 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 035DE1A6FEE; Tue, 10 Feb 2015 21:19:45 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEA1A702F; Tue, 10 Feb 2015 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGtuzm_-x90Z; Tue, 10 Feb 2015 21:19:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2EC1A7015; Tue, 10 Feb 2015 21:19:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211051943.28956.51127.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 21:19:43 -0800 Archived-At: Cc: dromasca@avaya.com, draft-ietf-lmap-use-cases.all@ietf.org, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Pete Resnick's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 05:19:46 -0000 Pete Resnick has entered the following ballot position for draft-ietf-lmap-use-cases-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for an excellent set of edits. This addresses my earlier concerns about the regulator use case text being too politically charged and focuses the document on the real engineering concerns that regulators need addressed. Well done. From nobody Wed Feb 11 03:05:30 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3D1E71A87F2; Wed, 11 Feb 2015 03:04:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D101A871B; Wed, 11 Feb 2015 03:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_ggS49EQh_d; Wed, 11 Feb 2015 03:04:07 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F7E1A87F2; Wed, 11 Feb 2015 03:04:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGAH0221TGmAcV/2dsb2JhbABbgmQiUloEgn2tQgEBAQEBAQaSSoVxAhyBC0MBAQEBAQF8hAwBAQEBAxIREUUMBAIBCA0BAwQBAQMCBh0DAgICMBQBCAgCBA4FCBqICwEMr1qKSZZsAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYRjiRERAR8xBwaCYi6BFAWFVIlOg1KGdYMEgj2MICKDbm+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418101200"; d="scan'208";a="103602219" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Feb 2015 06:03:59 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 11 Feb 2015 06:03:59 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 11 Feb 2015 12:03:57 +0100 From: "Romascanu, Dan (Dan)" To: Pete Resnick Thread-Topic: Pete Resnick's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) Thread-Index: AQHQRbpb/c/5S9m0y0G4EJGkA4vHb5zrSSIA Date: Wed, 11 Feb 2015 11:03:58 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9919A7@AZ-FFEXMB04.global.avaya.com> References: <20150211051943.28956.51127.idtracker@ietfa.amsl.com> In-Reply-To: <20150211051943.28956.51127.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Feb 2015 03:05:28 -0800 Cc: "draft-ietf-lmap-use-cases.all@ietf.org" , "lmap-chairs@ietf.org" Subject: Re: [lmap] Pete Resnick's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2015 11:04:10 -0000 VGhhbmtzIHRvIHlvdSwgUGV0ZSwgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhlIHN1cHBvcnQgaW4g YnJpbmdpbmcgdGhlIERJU0NVU1MgdG8gYSBjb25zdHJ1Y3RpdmUgY2xvc3VyZS4gDQoNClJlZ2Fy ZHMsDQoNCkRhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0 ZSBSZXNuaWNrIFttYWlsdG86cHJlc25pY2tAcXRpLnF1YWxjb21tLmNvbV0NCj4gU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSA3OjIwIEFNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzog ZHJhZnQtaWV0Zi1sbWFwLXVzZS1jYXNlcy5hbGxAaWV0Zi5vcmc7IFJvbWFzY2FudSwgRGFuIChE YW4pOyBsbWFwLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGxtYXBAaWV0Zi5vcmcNCj4gU3ViamVjdDog UGV0ZSBSZXNuaWNrJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbG1hcC11c2UtY2FzZXMt MDY6ICh3aXRoDQo+IENPTU1FTlQpDQo+IA0KPiBQZXRlIFJlc25pY2sgaGFzIGVudGVyZWQgdGhl IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbG1hcC11c2UtY2Fz ZXMtMDY6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz IGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSBy ZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0N Cj4gM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLQ0KPiAyRGNyaXRlcmlh Lmh0bWwmZD1Bd0lDYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2MNCj4g TlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT02VGlQTUlYcTNqZVVJUUVYcW5pWmYy M0xKS3VEbC0NCj4gS2hKQjdUaUJYQ0hnNCZzPUlzZk0wZy1QLUxwaUN3UUxMcFpiTlRXcGlqdlhm WHhTajlpbndSQUxnbTAmZT0NCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLQ0KPiAzQV9fZGF0YXRy YWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGxtYXAtMkR1c2UtDQo+IDJEY2FzZXNf JmQ9QXdJQ2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmYNCj4g UXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09NlRpUE1JWHEzamVVSVFFWHFuaVpmMjNMSkt1 RGwtDQo+IEtoSkI3VGlCWENIZzQmcz1uaEdXcEZoOEpMQkdIcEhNVURXRERDVVBlX2RTWXFGUC0N Cj4gRjYzSWE2ajlKdyZlPQ0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6 DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rIHlvdSBmb3IgYW4gZXhjZWxsZW50IHNldCBv ZiBlZGl0cy4gVGhpcyBhZGRyZXNzZXMgbXkgZWFybGllcg0KPiBjb25jZXJucyBhYm91dCB0aGUg cmVndWxhdG9yIHVzZSBjYXNlIHRleHQgYmVpbmcgdG9vIHBvbGl0aWNhbGx5IGNoYXJnZWQNCj4g YW5kIGZvY3VzZXMgdGhlIGRvY3VtZW50IG9uIHRoZSByZWFsIGVuZ2luZWVyaW5nIGNvbmNlcm5z IHRoYXQgcmVndWxhdG9ycw0KPiBuZWVkIGFkZHJlc3NlZC4gV2VsbCBkb25lLg0KPiANCg0K From nobody Wed Feb 11 05:29:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E911A88A8 for ; Wed, 11 Feb 2015 05:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iavs_ddEzMl for ; Wed, 11 Feb 2015 05:28:53 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3501A88BE for ; Wed, 11 Feb 2015 05:28:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAHJY21TGmAcV/2dsb2JhbABbgkMhIiIwXrAsAQEBAQEBBgWSHh0BhXoCgSVDAQEBAQEBfIQOAQEDEhteARUVViYBBBsaiAsBqz+Ef6FADCCGBIlCgmUMQB2BFAWJfoUkikeDBII9jCAigX8fgVCCM38BAQE X-IronPort-AV: E=Sophos;i="5.09,558,1418101200"; d="scan'208,217";a="106397763" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Feb 2015 08:28:48 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 11 Feb 2015 08:28:48 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 11 Feb 2015 14:28:46 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: comments on draft-starkcarey-lmap-protocol-criteria-00 Thread-Index: AdBF/qVP+I1zvHL/R1qUKKbaUsALkw== Date: Wed, 11 Feb 2015 13:28:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C991C18@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C991C18AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] comments on draft-starkcarey-lmap-protocol-criteria-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2015 13:28:57 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C991C18AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks to the two editors for putting together the criteria and documenting= them in this useful I-D. Please find below my comments - please address them before or during the LM= AP WG interim meeting tomorrow: 1. I do not believe that there is a need to mention 2119 and refer to= keywords. The document does not use 2119 keywords, which is good. 2. The Mandatory Criteria sections 2.1 and 3.1 include the following = sentence whose intent is lost to me: =D8 . Note that although the protocol may support the criterion, it is not necessarily the case that the criterion is mandatory to implement What does this mean? A mandatory criterion MUST be implemented. Maybe the i= ntent is to say that the criterion (function) may be optional in the respec= tive protocol, but MUST be implemented for LMPA purposes? In this case clar= ification text would be useful. 3. CP-MUST-3 and RP-MUST-2 describe the need for the respective proto= cols 'of being secured using certificates'. I believe that it is necessary = to be explicit what 'being secured means for each of the protocols (authent= ication, encryption for privacy, protection against replay attacks, etc.). = Also certificates are being mentioned only with a title of example in draft= -ietf-lmap-framework. Why are they turned here in a requirement? 4. CP-DIFF-3: 'It is possible to provide partial updates' - of what? = Instruction set? Or status? Or both? 5. CP-DIFF-4: 'asking out of curiosity' is not a good thing in a crit= eria document. If having an associated NAT/firewall traversal mechanism as = part of the protocol is considered an advantage, then let us leave is as a = criterion, and make clear that 'yes is better' 6. CP-DIFF-5, CP-DIFF-6, RP-DIFF-6 use number of bytes as a function = of the overhead. Absolute numbers do not say the whole story when it comes = to overhead. I would add overhead bytes per message and overhead bytes divi= ded to the total number of bytes (overhead percentage) 7. I do not understand CP-DIFF-8 and RP-DIFF-7. What are 'mechanism = to ensure interoperability'? The protocols themselves need to ensure intero= perability. I must be missing something. 8. CP-DIFF-11/12, and RP-DIFF-10/11 respectively: I believe that maki= ng (both) protocols versionable is a mandatory requirement. The second requ= irement in each set seems to be more a clarification question providing add= itional information to the first. 9. CP-DIFF-13 and RP-DIFF-12 - I believe that we should say in both c= ases that multiple encodings is an advantage. Otherwise, drop the question. 10. I believe that for both control and reporting protocols we should add= a (maybe even mandatory!) requirement about separation of protocol and inf= ormation (data model ) and ask what DMLs are supported. 11. I believe that the framework (section 5.5) defines a mandatory requir= ement for the reporting protocol to support a 'push' mode - this is missing Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C991C18AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks to the two editors for putting together the c= riteria and documenting them in this useful I-D.

 

Please find below my comments – please address= them before or during the LMAP WG interim meeting tomorrow:

 

1.     &= nbsp; I do not believe that ther= e is a need to mention 2119 and refer to keywords. The document does not us= e 2119 keywords, which is good.

 

2.     &= nbsp; The Mandatory Criteria sec= tions 2.1 and 3.1 include the following sentence whose intent is lost to me= :

 

=D8&= nbsp; .  Note
   that although the protocol may support the criterion, it is no= t
   necessarily the case that the criterion is mandatory to implem= ent

 

What does this m= ean? A mandatory criterion MUST be implemented. Maybe the intent is to say = that the criterion (function) may be optional in the respective protocol, b= ut MUST be implemented for LMPA purposes? In this case clarification text would be useful.

 

3.     &= nbsp; CP-MUST-3 and RP-MUST-2 de= scribe the need for the respective protocols ‘of being secured using = certificates’. I believe that it is necessary to be explicit what = 216;being secured means for each of the protocols (authentication, encryption for privacy, protection against replay attacks, etc.). Also cer= tificates are being mentioned only with a title of example in draft-ietf-lm= ap-framework. Why are they turned here in a requirement?

 

4.     &= nbsp; CP-DIFF-3: ‘It is po= ssible to provide partial updates’ – of what? Instruction set? = Or status? Or both?

 

5.     &= nbsp; CP-DIFF-4: ‘asking o= ut of curiosity’ is not a good thing in a criteria document. If havin= g an associated NAT/firewall traversal mechanism as part of the protocol is= considered an advantage, then let us leave is as a criterion, and make clear that ‘yes is better’=

 

6.     &= nbsp; CP-DIFF-5, CP-DIFF-6, RP-D= IFF-6 use number of bytes as a function of the overhead. Absolute numbers d= o not say the whole story when it comes to overhead. I would add overhead b= ytes per message and overhead bytes divided to the total number of bytes (overhead percentage)

 

7.     &= nbsp;  I do not understand = CP-DIFF-8 and RP-DIFF-7. What are ‘mechanism to ensure interoperabili= ty’? The protocols themselves need to ensure interoperability. I must= be missing something.

 

8.     &= nbsp; CP-DIFF-11/12, and RP-DIFF= -10/11 respectively: I believe that making (both) protocols versionable is = a mandatory requirement. The second requirement in each set seems to be mor= e a clarification question providing additional information to the first.

 

9.     &= nbsp; CP-DIFF-13 and RP-DIFF-12 = – I believe that we should say in both cases that multiple encodings = is an advantage. Otherwise, drop the question.

 

10.   I believe that for both co= ntrol and reporting protocols we should add a (maybe even mandatory!) requi= rement about separation of protocol and information (data model ) and ask w= hat DMLs are supported.

 

11.   I believe that the framewo= rk (section 5.5) defines a mandatory requirement for the reporting protocol= to support a ‘push’ mode – this is missing

 

 

Thanks and Regards,

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C991C18AZFFEXMB04globa_-- From nobody Thu Feb 12 03:45:16 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839DD1A1B27 for ; Thu, 12 Feb 2015 03:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNR8mge5iHKT for ; Thu, 12 Feb 2015 03:45:01 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884EA1A1B46 for ; Thu, 12 Feb 2015 03:44:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFALeR3FTGmAcV/2dsb2JhbABbgkMhIlJaBLBEDQEBAQEBBpJNhW8CgShDAQEBAQEBfIQOAQEDEhteAQwJFVYmAQQbARmICwEMrRyEf6IKhgSJRINOgRQFjyeKSYMGgj2MJCKBUYIdbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,565,1418101200"; d="scan'208,217";a="103789684" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Feb 2015 06:44:49 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2015 06:44:49 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 12 Feb 2015 12:44:48 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG interim today Thread-Index: AdBGuUztc2djFKuoRC2UROAQs0q75w== Date: Thu, 12 Feb 2015 11:44:47 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9942BB@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9942BBAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG interim today X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 11:45:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9942BBAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I uploaded the chairs slides for the WG interim at http://www.ietf.org/proc= eedings/interim/2015/02/12/lmap/slides/slides-interim-2015-lmap-1-0.pptx. We still seek volunteers to help with taking notes. If you plan to use any slides in the meeting please send those to Jason and= me for early uploading. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9942BBAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I uploaded the chairs slides for the WG interim at <= a href=3D"http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/sl= ides-interim-2015-lmap-1-0.pptx"> http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/slides-inter= im-2015-lmap-1-0.pptx.

 

We still seek volunteers to help with taking notes. =

 

If you plan to use any slides in the meeting please = send those to Jason and me for early uploading.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9942BBAZFFEXMB04globa_-- From nobody Thu Feb 12 05:29:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E531A87CA; Thu, 12 Feb 2015 04:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B2Jw3Eu6GRf; Thu, 12 Feb 2015 04:58:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3F1A6EE1; Thu, 12 Feb 2015 04:58:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212125802.20720.14749.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 04:58:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 05:29:15 -0800 Cc: dromasca@avaya.com, draft-ietf-lmap-use-cases.all@ietf.org, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:58:03 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-use-cases-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my prior discuss concerns with security and privacy considerations. From nobody Thu Feb 12 05:29:22 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E83B01A87CC; Thu, 12 Feb 2015 04:58:03 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E531A87CA; Thu, 12 Feb 2015 04:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B2Jw3Eu6GRf; Thu, 12 Feb 2015 04:58:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3F1A6EE1; Thu, 12 Feb 2015 04:58:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212125802.20720.14749.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 04:58:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 05:29:15 -0800 Cc: dromasca@avaya.com, draft-ietf-lmap-use-cases.all@ietf.org, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-use-cases-06: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:58:04 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-use-cases-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my prior discuss concerns with security and privacy considerations. From nobody Thu Feb 12 07:29:46 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D421A8AAB for ; Thu, 12 Feb 2015 07:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0l52rIn23qn for ; Thu, 12 Feb 2015 07:29:41 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC77A1A8F4F for ; Thu, 12 Feb 2015 07:29:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFABPG3FTGmAcV/2dsb2JhbABYA4JkIiIwWgSCfq1SAQEBAQEHkiAfB4V0AhyBDUMBAQEBAQF8hA0BAQEDEhERMiECAgEIDQ0CBgoEDAYCAgIZFxUGAQYCAQIBAxsaiAsBDLNQikmFLZFuAQEBAQEBBAEBAQEBAQEBAQEBFwSBHYRjhQiBPYJsEwsLCxcRB4IVDC8RHYEUBYVWiVODVoNkgxEQKIJOgj6IZoM+IoMgTm8BAYFCfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,565,1418101200"; d="scan'208";a="106618800" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Feb 2015 10:29:18 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2015 10:29:17 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 12 Feb 2015 10:29:16 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG Virtual Interim Meeting, February 12, 2015 Thread-Index: AQHQKgijn+/eEej/ckSDDDR4d/VliJztXP4g Date: Thu, 12 Feb 2015 15:29:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C99461E@AZ-FFEXMB04.global.avaya.com> References: <20150106232914.4753.57378.idtracker@ietfa.amsl.com> In-Reply-To: <20150106232914.4753.57378.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: LMAP WG Virtual Interim Meeting, February 12, 2015 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 15:29:43 -0000 QSByZW1pbmRlciBvZiB0aGUgbG9naXN0aWNzIG9mIHRoZSBWaXJ0dWFsIEludGVyaW0gbWVldGlu ZyBkdWUgdG8gc3RhcnQgaW4gYWJvdXQgOTAgbWluLiANCg0KUmVnYXJkcywNCg0KRGFuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNClRoZSBMTUFQIFdHIHdpbGwgaG9sZCBhIHZpcnR1YWwgaW50 ZXJpbSBtZWV0aW5nIG9uIFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSwgYmV0d2VlbiBub29u IGFuZCAyOjAwUE0gRVNUICgxNzAwLTE5MDAgVVRDKS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpMTUFQIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQpUaHVyc2RheSwgRmVicnVhcnkg MTIsIDIwMTUNCjEyOjAwIHBtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBH TVQtMDU6MDApICB8ICAyIGhyDQogDQpKb2luIFdlYkV4IG1lZXRpbmc6IGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0 Zl9qLnBocC0zRk1USUQtM0RtN2YwMmEwNjBkMDE4ZThjMTc3ODAzMThkZTkwODRjNmImZD1Bd0lD YVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVj QlhSdWNQdmRycGhwQnNGQSZtPTlLUWZfc1piZnBra0tQVmlkM0hteVRtS0REa0oxTkxNc1RGclo2 TEE3b28mcz0wMUZ3SUtsMnY4ZUIzc1FhRTFFVnMtRDB0YkhTako3Q0RuOGgzaVgxeGVZJmU9IA0K TWVldGluZyBudW1iZXI6CTY0NSA3NzEgMTI3DQpNZWV0aW5nIHBhc3N3b3JkOgkxMjM0DQogDQpK b2luIGJ5IHBob25lDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSkNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkg QWNjZXNzIGNvZGU6IDY0NSA3NzEgMTI3IFRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczog aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy53 ZWJleC5jb21fcGRmX3RvbGxmcmVlLTVGcmVzdHJpY3Rpb25zLnBkZiZkPUF3SUNhUSZjPUJGcFdR dzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJw aHBCc0ZBJm09OUtRZl9zWmJmcGtrS1BWaWQzSG15VG1LRERrSjFOTE1zVEZyWjZMQTdvbyZzPWQ4 NUU2N1dTOE1kWFIyVEgzcW1FN2NzYnl0THhOLTNfSU9qSE1USzNqdXMmZT0gDQogDQpBZGQgdGhp cyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXI6IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0Zl9qLnBocC0zRk1USUQt M0RtYTFhOWIxZWNkYWNmMTdjYmM5OWRmZjkzYTkwNDBkNmEmZD1Bd0lDYVEmYz1CRnBXUXc4YnN1 S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNG QSZtPTlLUWZfc1piZnBra0tQVmlkM0hteVRtS0REa0oxTkxNc1RGclo2TEE3b28mcz1nMUo4S0dh MGctU3RDZFZFeGlNNkZnbmNrWFplalNNUS1nVEdiNG40Q2NRJmU9IA0KIA0KQ2FuJ3Qgam9pbiB0 aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0OiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2lldGYud2ViZXguY29tX2lldGZfbWMmZD1Bd0lDYVEm Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhS dWNQdmRycGhwQnNGQSZtPTlLUWZfc1piZnBra0tQVmlkM0hteVRtS0REa0oxTkxNc1RGclo2TEE3 b28mcz0wNWRSNUo2SDNWMVlQS0hLWnVsMU5tUjgxa0NzYng5VEJ1bUpmZHlHb2c4JmU9IA0KIA0K SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLg0KDQo= From nobody Thu Feb 12 08:39:39 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE091A00E5 for ; Thu, 12 Feb 2015 08:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_jqEwn8R_hm for ; Thu, 12 Feb 2015 08:39:25 -0800 (PST) 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 778FF1A0115 for ; Thu, 12 Feb 2015 08:39:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4B39617EB for ; Thu, 12 Feb 2015 17:39:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dcNImV5gTu2H for ; Thu, 12 Feb 2015 17:39:03 +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 for ; Thu, 12 Feb 2015 17:39:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 428C120038 for ; Thu, 12 Feb 2015 17:39:23 +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 tJLf-VDLElcw; Thu, 12 Feb 2015 17:39:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46A3B20036; Thu, 12 Feb 2015 17:39:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 51BF2320864E; Thu, 12 Feb 2015 17:39:21 +0100 (CET) Date: Thu, 12 Feb 2015 17:39:21 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150212163921.GB13099@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.4.2.3i Archived-At: Subject: [lmap] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 16:39:35 -0000 Hi, I am wondering whether we over-engineer the control protocol selection process. So far, there are four proposals on the table and the number did not change for a year or so I think. Lets summarize the main differences: - All proposals support to run the protocol exchanges over HTTP. Two proposals in principle also allow the usage of NETCONF. - Two proposals are YANG data model driven, two proposals come with a handmade resource and object model. - The proposals differ in the approach used to establish connections and whether the interactions are more push or pull. - The proposals may (or may) not differ in the data encoding used, e.g., XML or JSON. Did I forget any other major difference? If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I have the feeling that we are over-engineering the protocol selection process. Do we really have to define precisely how to measure say "the overhead to send a complete instruction set" given that the protocols on the table are so close to each other? Would it perhaps be faster to simply try to look at the differences mentioned above and to decide what the WG prefers? I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I think it is actually a very good document to have if there would be substantially different proposals on the table. But frankly, I have not yet heard about any proposals that I feel require this level of detail, given that all protocols are some form of REST over HTTP. /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 Thu Feb 12 08:42:37 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409C91A0141 for ; Thu, 12 Feb 2015 08:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdzh2DA4fSaT for ; Thu, 12 Feb 2015 08:42:30 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9AB1A00E5 for ; Thu, 12 Feb 2015 08:42:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAPLW3FSHCzIm/2dsb2JhbABYA4JkIlJaBLBQAQEBAQEBBpJJhXECgSlDAQEBAQEBfIQMAQEBAQMSKDQXAgICAQgNAQIBBAEBCxQJBxsXFAkIAgQBEggaiAsBDLNvoWoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASGAIUIhDwhFwYLgwWBFAWPKYNWhnWDBoI+jCQiggIcgVBvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,565,1418101200"; d="scan'208";a="103840747" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Feb 2015 11:42:29 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2015 11:42:29 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 12 Feb 2015 17:42:27 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] control protocol selection process Thread-Index: AQHQRuKBPY2jNKF5L02ozUcJfhisLZztN5qA Date: Thu, 12 Feb 2015 16:42:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> References: <20150212163921.GB13099@elstar.local> In-Reply-To: <20150212163921.GB13099@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 16:42:36 -0000 Hi Juergen, Please feel free to comment this during the virtual interim.=20 It's basically about dropping some of the criteria. There are not that many= .=20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, February 12, 2015 6:39 PM > To: lmap@ietf.org > Subject: [lmap] control protocol selection process >=20 > Hi, >=20 > I am wondering whether we over-engineer the control protocol selection > process. So far, there are four proposals on the table and the number did= not > change for a year or so I think. Lets summarize the main > differences: >=20 > - All proposals support to run the protocol exchanges over HTTP. Two > proposals in principle also allow the usage of NETCONF. >=20 > - Two proposals are YANG data model driven, two proposals come with a > handmade resource and object model. >=20 > - The proposals differ in the approach used to establish connections > and whether the interactions are more push or pull. >=20 > - The proposals may (or may) not differ in the data encoding used, > e.g., XML or JSON. >=20 > Did I forget any other major difference? >=20 > If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I have = the > feeling that we are over-engineering the protocol selection process. Do w= e > really have to define precisely how to measure say "the overhead to send = a > complete instruction set" given that the protocols on the table are so cl= ose to > each other? Would it perhaps be faster to simply try to look at the > differences mentioned above and to decide what the WG prefers? >=20 > I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I think= it is > actually a very good document to have if there would be substantially > different proposals on the table. But frankly, I have not yet heard about= any > proposals that I feel require this level of detail, given that all protoc= ols are > some form of REST over HTTP. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyiqvSnQW6dMCsAA9wTr8c > xDG4S6zpZR8sYjNXU&s=3D62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0 > __w&e=3D > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyi > qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=3D4uDKIqWNqOkIbH06VKL > W76wFk19JaWkjmaUSZYw1cw0&e=3D From nobody Thu Feb 12 08:54:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11571A017E for ; Thu, 12 Feb 2015 08:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ0xiwnTeMCH for ; Thu, 12 Feb 2015 08:54:24 -0800 (PST) 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 27CC81A017A for ; Thu, 12 Feb 2015 08:54:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EA99D1A64; Thu, 12 Feb 2015 17:54:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KLEXWQ0dcFGn; Thu, 12 Feb 2015 17:53:44 +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; Thu, 12 Feb 2015 17:54:05 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCC9D20039; Thu, 12 Feb 2015 17:54:04 +0100 (CET) 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 c-xAzS9wGdeC; Thu, 12 Feb 2015 17:54:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C7E020037; Thu, 12 Feb 2015 17:54:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5DDB532088E2; Thu, 12 Feb 2015 17:54:03 +0100 (CET) Date: Thu, 12 Feb 2015 17:54:03 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150212165403.GA14114@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <20150212163921.GB13099@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 16:54:28 -0000 Well, my point is to look at the protocol differences instead of spending energy to define criterias that allow us to calculate overheads and such things if at the end all protocols on the table send similarly structured JSON over HTTP. I am not scared by the number of criterias but by the effort it will take to define them tightly and then we find that the difference is only in the length of the member names (and that might not even be counted as overhead). If anything matters, than it is the granularity / flexibility of the resource model but even here it is a judgement call whether a more flexible model is better. (It is better when it comes to scalability but not when it comes to complexity and implementation costs.) So at the end, we produce data but still have to make judgement calls on what I believe a rather small number of issues, given the characteristics of the proposals we have. /js On Thu, Feb 12, 2015 at 04:42:27PM +0000, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > Please feel free to comment this during the virtual interim. > > It's basically about dropping some of the criteria. There are not that many. > > Regards, > > Dan > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Thursday, February 12, 2015 6:39 PM > > To: lmap@ietf.org > > Subject: [lmap] control protocol selection process > > > > Hi, > > > > I am wondering whether we over-engineer the control protocol selection > > process. So far, there are four proposals on the table and the number did not > > change for a year or so I think. Lets summarize the main > > differences: > > > > - All proposals support to run the protocol exchanges over HTTP. Two > > proposals in principle also allow the usage of NETCONF. > > > > - Two proposals are YANG data model driven, two proposals come with a > > handmade resource and object model. > > > > - The proposals differ in the approach used to establish connections > > and whether the interactions are more push or pull. > > > > - The proposals may (or may) not differ in the data encoding used, > > e.g., XML or JSON. > > > > Did I forget any other major difference? > > > > If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I have the > > feeling that we are over-engineering the protocol selection process. Do we > > really have to define precisely how to measure say "the overhead to send a > > complete instruction set" given that the protocols on the table are so close to > > each other? Would it perhaps be faster to simply try to look at the > > differences mentioned above and to decide what the WG prefers? > > > > I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I think it is > > actually a very good document to have if there would be substantially > > different proposals on the table. But frankly, I have not yet heard about any > > proposals that I feel require this level of detail, given that all protocols are > > some form of REST over HTTP. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyiqvSnQW6dMCsAA9wTr8c > > xDG4S6zpZR8sYjNXU&s=62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0 > > __w&e= > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_lmap&d=AwICAg&c=BFpWQw8bsuKpl > > 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyi > > qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=4uDKIqWNqOkIbH06VKL > > W76wFk19JaWkjmaUSZYw1cw0&e= > > _______________________________________________ > 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 Thu Feb 12 09:01:08 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099021A0146 for ; Thu, 12 Feb 2015 09:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPMZw0EN1ude for ; Thu, 12 Feb 2015 09:01:01 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279D01A0187 for ; Thu, 12 Feb 2015 09:00:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFACjb3FSHCzIm/2dsb2JhbABYA4JkIlJaBLBQAQEBAQEBBpJJhXECgSlDAQEBAQEBfIQMAQEBAQMSCx00CwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgaiAsBDLQIoWcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIYAhQiEPCEQBwYLgwWBFAWPKYNWhnU4gk6CPowkIoICHIFQbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,565,1418101200"; d="scan'208";a="91187732" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Feb 2015 12:00:51 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2015 12:00:50 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 12 Feb 2015 18:00:48 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] control protocol selection process Thread-Index: AQHQRuKBPY2jNKF5L02ozUcJfhisLZztN5qA///y4ICAABJDMA== Date: Thu, 12 Feb 2015 17:00:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C99476D@AZ-FFEXMB04.global.avaya.com> References: <20150212163921.GB13099@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> <20150212165403.GA14114@elstar.local> In-Reply-To: <20150212165403.GA14114@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] 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] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 17:01:05 -0000 Well, we need some documenting of the process that was used for the selecti= on of the protocols. We do not plan to make it too long, maybe one more it= eration of the I-D. The call now starts and we can talk. > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, February 12, 2015 6:54 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] control protocol selection process >=20 > Well, my point is to look at the protocol differences instead of spending > energy to define criterias that allow us to calculate overheads and such = things > if at the end all protocols on the table send similarly structured JSON o= ver > HTTP. I am not scared by the number of criterias but by the effort it wil= l take > to define them tightly and then we find that the difference is only in th= e > length of the member names (and that might not even be counted as > overhead). >=20 > If anything matters, than it is the granularity / flexibility of the reso= urce > model but even here it is a judgement call whether a more flexible model = is > better. (It is better when it comes to scalability but not when it comes = to > complexity and implementation costs.) So at the end, we produce data but > still have to make judgement calls on what I believe a rather small numbe= r of > issues, given the characteristics of the proposals we have. >=20 > /js >=20 > On Thu, Feb 12, 2015 at 04:42:27PM +0000, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > > > Please feel free to comment this during the virtual interim. > > > > It's basically about dropping some of the criteria. There are not that = many. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Thursday, February 12, 2015 6:39 PM > > > To: lmap@ietf.org > > > Subject: [lmap] control protocol selection process > > > > > > Hi, > > > > > > I am wondering whether we over-engineer the control protocol > > > selection process. So far, there are four proposals on the table and > > > the number did not change for a year or so I think. Lets summarize > > > the main > > > differences: > > > > > > - All proposals support to run the protocol exchanges over HTTP. Two > > > proposals in principle also allow the usage of NETCONF. > > > > > > - Two proposals are YANG data model driven, two proposals come with a > > > handmade resource and object model. > > > > > > - The proposals differ in the approach used to establish connections > > > and whether the interactions are more push or pull. > > > > > > - The proposals may (or may) not differ in the data encoding used, > > > e.g., XML or JSON. > > > > > > Did I forget any other major difference? > > > > > > If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I > > > have the feeling that we are over-engineering the protocol selection > > > process. Do we really have to define precisely how to measure say > > > "the overhead to send a complete instruction set" given that the > > > protocols on the table are so close to each other? Would it perhaps > > > be faster to simply try to look at the differences mentioned above an= d to > decide what the WG prefers? > > > > > > I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I > > > think it is actually a very good document to have if there would be > > > substantially different proposals on the table. But frankly, I have > > > not yet heard about any proposals that I feel require this level of > > > detail, given that all protocols are some form of REST over HTTP. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > 2Duniversity.de_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > > > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyiqvSnQW6dMCsAA9wTr8c > > > > xDG4S6zpZR8sYjNXU&s=3D62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0 > > > __w&e=3D > > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAwICAg&c=3DBFpWQw8bsuKpl > > > > 1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyi > > > > qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=3D4uDKIqWNqOkIbH06VKL > > > W76wFk19JaWkjmaUSZYw1cw0&e=3D > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > > man_listinfo_lmap&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31 > OcNXCJf > > QzvlsiLQfucBXRucPvdrphpBsFA&m=3DcQyLlMGTmIuBRoc33cPzGG- > zjmPToTi2ni5_dMVA > > Q_Q&s=3D-tGE5J_fupa3HRzpKAt_G5JUPIt5uT1cDXBo2J5Ig4c&e=3D >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DcQyLlMGTmIuBRoc33cPzGG- > zjmPToTi2ni5_dMVAQ_Q&s=3DpEA9P1BdqP2S7tPTsEMa7i9_pky7Jr3DIu5V0AB > onMU&e=3D > From nobody Thu Feb 12 09:06:53 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A141A0266 for ; Thu, 12 Feb 2015 09:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqpNnrtBoXJb for ; Thu, 12 Feb 2015 09:06:28 -0800 (PST) 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 CEA2A1A01A9 for ; Thu, 12 Feb 2015 09:04:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 81BA51A7C; Thu, 12 Feb 2015 18:04:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X6psKZBHN_QY; Thu, 12 Feb 2015 18:04:18 +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; Thu, 12 Feb 2015 18:04:39 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A0CA20038; Thu, 12 Feb 2015 18:04:39 +0100 (CET) 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 M_6JdROIZnJh; Thu, 12 Feb 2015 18:04:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE4E820036; Thu, 12 Feb 2015 18:04:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE8A73208B17; Thu, 12 Feb 2015 18:04:36 +0100 (CET) Date: Thu, 12 Feb 2015 18:04:36 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150212170436.GA14594@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <20150212163921.GB13099@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> <20150212165403.GA14114@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99476D@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C99476D@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 17:06:36 -0000 Hi, I do not think the IETF requires that every protocol selection needs a formal approach like the one we are heading to. The chairs could simply narrow the search space. You could say: The chairs believe the WG has consensus that the control protocol will allow to run over HTTP. If nobody opposes this, we made a step forward by narrowing the search space. /js On Thu, Feb 12, 2015 at 05:00:49PM +0000, Romascanu, Dan (Dan) wrote: > Well, we need some documenting of the process that was used for the selection of the protocols. We do not plan to make it too long, maybe one more iteration of the I-D. The call now starts and we can talk. > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Thursday, February 12, 2015 6:54 PM > > To: Romascanu, Dan (Dan) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] control protocol selection process > > > > Well, my point is to look at the protocol differences instead of spending > > energy to define criterias that allow us to calculate overheads and such things > > if at the end all protocols on the table send similarly structured JSON over > > HTTP. I am not scared by the number of criterias but by the effort it will take > > to define them tightly and then we find that the difference is only in the > > length of the member names (and that might not even be counted as > > overhead). > > > > If anything matters, than it is the granularity / flexibility of the resource > > model but even here it is a judgement call whether a more flexible model is > > better. (It is better when it comes to scalability but not when it comes to > > complexity and implementation costs.) So at the end, we produce data but > > still have to make judgement calls on what I believe a rather small number of > > issues, given the characteristics of the proposals we have. > > > > /js > > > > On Thu, Feb 12, 2015 at 04:42:27PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi Juergen, > > > > > > Please feel free to comment this during the virtual interim. > > > > > > It's basically about dropping some of the criteria. There are not that many. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Thursday, February 12, 2015 6:39 PM > > > > To: lmap@ietf.org > > > > Subject: [lmap] control protocol selection process > > > > > > > > Hi, > > > > > > > > I am wondering whether we over-engineer the control protocol > > > > selection process. So far, there are four proposals on the table and > > > > the number did not change for a year or so I think. Lets summarize > > > > the main > > > > differences: > > > > > > > > - All proposals support to run the protocol exchanges over HTTP. Two > > > > proposals in principle also allow the usage of NETCONF. > > > > > > > > - Two proposals are YANG data model driven, two proposals come with a > > > > handmade resource and object model. > > > > > > > > - The proposals differ in the approach used to establish connections > > > > and whether the interactions are more push or pull. > > > > > > > > - The proposals may (or may) not differ in the data encoding used, > > > > e.g., XML or JSON. > > > > > > > > Did I forget any other major difference? > > > > > > > > If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I > > > > have the feeling that we are over-engineering the protocol selection > > > > process. Do we really have to define precisely how to measure say > > > > "the overhead to send a complete instruction set" given that the > > > > protocols on the table are so close to each other? Would it perhaps > > > > be faster to simply try to look at the differences mentioned above and to > > decide what the WG prefers? > > > > > > > > I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I > > > > think it is actually a very good document to have if there would be > > > > substantially different proposals on the table. But frankly, I have > > > > not yet heard about any proposals that I feel require this level of > > > > detail, given that all protocols are some form of REST over HTTP. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 > > > > > > > > > 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > > > > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyiqvSnQW6dMCsAA9wTr8c > > > > > > xDG4S6zpZR8sYjNXU&s=62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0 > > > > __w&e= > > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > > > > > 3A__www.ietf.org_mailman_listinfo_lmap&d=AwICAg&c=BFpWQw8bsuKpl > > > > > > 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyi > > > > > > qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=4uDKIqWNqOkIbH06VKL > > > > W76wFk19JaWkjmaUSZYw1cw0&e= > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mail > > > > > man_listinfo_lmap&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31 > > OcNXCJf > > > QzvlsiLQfucBXRucPvdrphpBsFA&m=cQyLlMGTmIuBRoc33cPzGG- > > zjmPToTi2ni5_dMVA > > > Q_Q&s=-tGE5J_fupa3HRzpKAt_G5JUPIt5uT1cDXBo2J5Ig4c&e= > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=cQyLlMGTmIuBRoc33cPzGG- > > zjmPToTi2ni5_dMVAQ_Q&s=pEA9P1BdqP2S7tPTsEMa7i9_pky7Jr3DIu5V0AB > > onMU&e= > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 12 09:51:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD721A0266 for ; Thu, 12 Feb 2015 09:51:30 -0800 (PST) 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 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 0jyN2rbYS6tL for ; Thu, 12 Feb 2015 09:51:18 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798091A0233 for ; Thu, 12 Feb 2015 09:51:18 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Feb 2015 17:51:21 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.190]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 12 Feb 2015 17:51:16 +0000 From: To: , Date: Thu, 12 Feb 2015 17:49:45 +0000 Thread-Topic: [lmap] control protocol selection process Thread-Index: AdBG5lH9dQfXl40DQN6QqALyQpCcGQABffFA Message-ID: References: <20150212163921.GB13099@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99472C@AZ-FFEXMB04.global.avaya.com> <20150212165403.GA14114@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C99476D@AZ-FFEXMB04.global.avaya.com>, <20150212170436.GA14594@elstar.local> In-Reply-To: <20150212170436.GA14594@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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] control protocol selection process X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 17:51:30 -0000 I agree that this sort of narrowing would be a good idea (and that the -pro= tocol-criteria draft is probably not the right place to discover / record s= uch agreements) phil ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: 12 February 2015 17:04 To: Romascanu, Dan (Dan) Cc: lmap@ietf.org Subject: Re: [lmap] control protocol selection process Hi, I do not think the IETF requires that every protocol selection needs a formal approach like the one we are heading to. The chairs could simply narrow the search space. You could say: The chairs believe the WG has consensus that the control protocol will allow to run over HTTP. If nobody opposes this, we made a step forward by narrowing the search space. /js On Thu, Feb 12, 2015 at 05:00:49PM +0000, Romascanu, Dan (Dan) wrote: > Well, we need some documenting of the process that was used for the selec= tion of the protocols. We do not plan to make it too long, maybe one more = iteration of the I-D. The call now starts and we can talk. > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Thursday, February 12, 2015 6:54 PM > > To: Romascanu, Dan (Dan) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] control protocol selection process > > > > Well, my point is to look at the protocol differences instead of spendi= ng > > energy to define criterias that allow us to calculate overheads and suc= h things > > if at the end all protocols on the table send similarly structured JSON= over > > HTTP. I am not scared by the number of criterias but by the effort it w= ill take > > to define them tightly and then we find that the difference is only in = the > > length of the member names (and that might not even be counted as > > overhead). > > > > If anything matters, than it is the granularity / flexibility of the re= source > > model but even here it is a judgement call whether a more flexible mode= l is > > better. (It is better when it comes to scalability but not when it come= s to > > complexity and implementation costs.) So at the end, we produce data bu= t > > still have to make judgement calls on what I believe a rather small num= ber of > > issues, given the characteristics of the proposals we have. > > > > /js > > > > On Thu, Feb 12, 2015 at 04:42:27PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi Juergen, > > > > > > Please feel free to comment this during the virtual interim. > > > > > > It's basically about dropping some of the criteria. There are not tha= t many. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Thursday, February 12, 2015 6:39 PM > > > > To: lmap@ietf.org > > > > Subject: [lmap] control protocol selection process > > > > > > > > Hi, > > > > > > > > I am wondering whether we over-engineer the control protocol > > > > selection process. So far, there are four proposals on the table an= d > > > > the number did not change for a year or so I think. Lets summarize > > > > the main > > > > differences: > > > > > > > > - All proposals support to run the protocol exchanges over HTTP. Tw= o > > > > proposals in principle also allow the usage of NETCONF. > > > > > > > > - Two proposals are YANG data model driven, two proposals come with= a > > > > handmade resource and object model. > > > > > > > > - The proposals differ in the approach used to establish connection= s > > > > and whether the interactions are more push or pull. > > > > > > > > - The proposals may (or may) not differ in the data encoding used, > > > > e.g., XML or JSON. > > > > > > > > Did I forget any other major difference? > > > > > > > > If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I > > > > have the feeling that we are over-engineering the protocol selectio= n > > > > process. Do we really have to define precisely how to measure say > > > > "the overhead to send a complete instruction set" given that the > > > > protocols on the table are so close to each other? Would it perhaps > > > > be faster to simply try to look at the differences mentioned above = and to > > decide what the WG prefers? > > > > > > > > I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I > > > > think it is actually a very good document to have if there would be > > > > substantially different proposals on the table. But frankly, I have > > > > not yet heard about any proposals that I feel require this level of > > > > detail, given that all protocols are some form of REST over HTTP. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > > > Fax: +49 421 200 3103 > > > > > > > > > 2Duniversity.de_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > > > > > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyiqvSnQW6dMCsAA9wTr8c > > > > > > xDG4S6zpZR8sYjNXU&s=3D62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0 > > > > __w&e=3D > > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAwICAg&c=3DBFpWQw8bsuKpl > > > > > > 1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DSEk8pyi > > > > > > qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=3D4uDKIqWNqOkIbH06VKL > > > > W76wFk19JaWkjmaUSZYw1cw0&e=3D > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mail > > > > > man_listinfo_lmap&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31 > > OcNXCJf > > > QzvlsiLQfucBXRucPvdrphpBsFA&m=3DcQyLlMGTmIuBRoc33cPzGG- > > zjmPToTi2ni5_dMVA > > > Q_Q&s=3D-tGE5J_fupa3HRzpKAt_G5JUPIt5uT1cDXBo2J5Ig4c&e=3D > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DcQyLlMGTmIuBRoc33cPzGG- > > zjmPToTi2ni5_dMVAQ_Q&s=3DpEA9P1BdqP2S7tPTsEMa7i9_pky7Jr3DIu5V0AB > > onMU&e=3D > -- 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= From nobody Thu Feb 12 10:53:14 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0509E1A1AB3 for ; Thu, 12 Feb 2015 10:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIn9X_iIWaiG for ; Thu, 12 Feb 2015 10:53:10 -0800 (PST) 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 D5F811A1AF8 for ; Thu, 12 Feb 2015 10:53:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9F63B1A91 for ; Thu, 12 Feb 2015 19:53:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jP48RFv8A3wV for ; Thu, 12 Feb 2015 19:52: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 for ; Thu, 12 Feb 2015 19:53:08 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0632D20038 for ; Thu, 12 Feb 2015 19:53:08 +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 h0u0HH71lyzV; Thu, 12 Feb 2015 19:53:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9E7B20036; Thu, 12 Feb 2015 19:53:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3603F320A1F9; Thu, 12 Feb 2015 19:53:05 +0100 (CET) Date: Thu, 12 Feb 2015 19:53:04 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150212185304.GA16990@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.4.2.3i Archived-At: Subject: [lmap] status codes aka condition codes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 12 Feb 2015 18:53:12 -0000 Hi, to achieve interoperability, I think we need to define concrete status codes (aka condition codes), e.g. for runtime errors such as "measurement task could not be started", "measurement task aborted abnormally", etc. There are two options: a) We define a set of status codes as part of the information model. + Different LMAP implementations that comply to the same information model will use the same status codes. - The downside is that we have to nail them down now. b) We define a set of status codes as part of the data models. - Different protocols complying to the information model will use different status codes. + We can postpone the work needed to work out the essential status codes. If we decide for option b), I like to request that note is added to the information model that data models are expected to define a set of well-known status codes (aka condition codes) and that they may be encoded in something different than a string (that is the type used in the data model is more acting like a placeholder). /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 Feb 13 06:40:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3E1A8707; Fri, 13 Feb 2015 06:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO-gBSsS9ZCS; Fri, 13 Feb 2015 06:39:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4261A870B; Fri, 13 Feb 2015 06:39:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213143957.9156.18938.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 06:39:57 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:40:00 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Fri Feb 13 06:40:04 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 686931A8712; Fri, 13 Feb 2015 06:40:00 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3E1A8707; Fri, 13 Feb 2015 06:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO-gBSsS9ZCS; Fri, 13 Feb 2015 06:39:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4261A870B; Fri, 13 Feb 2015 06:39:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213143957.9156.18938.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 06:39:57 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:40:00 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Fri Feb 13 06:40:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2401A8713; Fri, 13 Feb 2015 06:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGWYwFpzgGZl; Fri, 13 Feb 2015 06:40:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E07C51A8715; Fri, 13 Feb 2015 06:40:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213144036.573.35174.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 06:40:36 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:40:43 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Fri Feb 13 06:40:48 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 182AF1A8715; Fri, 13 Feb 2015 06:40:43 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2401A8713; Fri, 13 Feb 2015 06:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGWYwFpzgGZl; Fri, 13 Feb 2015 06:40:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E07C51A8715; Fri, 13 Feb 2015 06:40:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213144036.573.35174.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 06:40:36 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:40:43 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Fri Feb 13 06:40:54 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843F01A8725; Fri, 13 Feb 2015 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyHSlkclR8J5; Fri, 13 Feb 2015 06:40:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 038BC1A871C; Fri, 13 Feb 2015 06:40:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213144037.573.3242.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 06:40:37 -0800 Archived-At: Cc: lmap mailing list , lmap chair , RFC Editor Subject: [lmap] Document Action: 'Large-Scale Broadband Measurement Use Cases' to Informational RFC (draft-ietf-lmap-use-cases-06.txt) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:40:46 -0000 The IESG has approved the following document: - 'Large-Scale Broadband Measurement Use Cases' (draft-ietf-lmap-use-cases-06.txt) as Informational RFC This document is the product of the Large-Scale Measurement of Broadband Performance Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ Technical Summary Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the framework, information model and protocol. This document details two use cases that can assist to developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. Working Group Summary The Working Group debated the scope of the work and decided to limit the scope of work in the first phase of LMAP to the ISP and Regulator use cases. There was strong consensus in the favor of this approach. Document Quality This is a use case document. There are various approaches implemented by vendors and providers for functions similar to these performed but LMAP, but no full solutions. Personnel Dan Romascanu is the Document Shepherd. Benoit Claise is the Responsible Area Director. From nobody Fri Feb 13 14:07:19 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E71A1AA9; Fri, 13 Feb 2015 14:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyx2AItV0_XV; Fri, 13 Feb 2015 14:06:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCBC1A1A57; Fri, 13 Feb 2015 14:06:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213220657.18773.65423.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 14:06:57 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:07:01 -0000 X-List-Received-Date: Fri, 13 Feb 2015 22:07:01 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Fri Feb 13 14:07:31 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D37501A1AC1; Fri, 13 Feb 2015 14:07:01 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E71A1AA9; Fri, 13 Feb 2015 14:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyx2AItV0_XV; Fri, 13 Feb 2015 14:06:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCBC1A1A57; Fri, 13 Feb 2015 14:06:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213220657.18773.65423.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 14:06:57 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:07:02 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Mon Feb 16 05:48:45 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824FB1A1B54 for ; Mon, 16 Feb 2015 05:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqEQcUEpaQml for ; Mon, 16 Feb 2015 05:48:38 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9089B1A8879 for ; Mon, 16 Feb 2015 05:48:36 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 16 Feb 2015 13:48:36 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 16 Feb 2015 13:47:42 +0000 From: To: Date: Mon, 16 Feb 2015 13:47:41 +0000 Thread-Topic: Information Model - Proposed changes to 04 Thread-Index: AdBJ7yFNDjRVBIndTWOPxB15/+s7Eg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model - Proposed changes to 04 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2015 13:48:43 -0000 For anyone who didn't manage to attend the interim, here are the slides and= proposals for the Information Model: http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/slides-inter= im-2015-lmap-1-1.pptx In summary the main proposals are: - To keep the JSON example data model (with corrections) and to also add to= the references the YANG data model (draft-schoenw-lmap-yang) - To standardise the well-known objects for Channel and Role, even though t= hey are optional task parameters to aid interworking across different tasks - To evolve the current general MA status information into MA and task spec= ific status information - To evolve the current general MA condition codes into MA and task specifi= c condition codes - Clarify that options for a scheduled task are appended to the options spe= cified for the general task configuration Any additional comments and suggestions are welcome until 23rd February, af= ter which I will go ahead and make the changes. Please don't bother sending= spelling corrections as I have already spellchecked it (and made the other= minor corrections already suggested) ready for the more substantive 04 cha= nges. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Research & Innovation Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 From nobody Mon Feb 16 07:17:43 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42A1A88C1 for ; Mon, 16 Feb 2015 07:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 X8fQOtHpUHjd for ; Mon, 16 Feb 2015 07:17:37 -0800 (PST) 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 9D7711A88B9 for ; Mon, 16 Feb 2015 07:17:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1672F781; Mon, 16 Feb 2015 16:17:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iEpfZOcDz8nY; Mon, 16 Feb 2015 16:17:16 +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, 16 Feb 2015 16:17:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD38520036; Mon, 16 Feb 2015 16:17:18 +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 vZkmkyEDhQTq; Mon, 16 Feb 2015 16:17: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 0B9E62002B; Mon, 16 Feb 2015 16:17:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0EB953230F3B; Mon, 16 Feb 2015 16:17:16 +0100 (CET) Date: Mon, 16 Feb 2015 16:17:16 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20150216151715.GB11458@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Information Model - Proposed changes to 04 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2015 15:17:40 -0000 Hi, there were a few more things mentioned on the list: - introducing a configuration version number to avoid having to send the complete config back with reports; do we really want to assume that config is echoed with each report? - clarify the semantics of feeding data between tasks following different schedules, buffering and blocking issues - status (condition) codes - do we want to have common ones or is every data model / protocol free to invent their own codes? /js On Mon, Feb 16, 2015 at 01:47:41PM +0000, trevor.burbridge@bt.com wrote: > For anyone who didn't manage to attend the interim, here are the slides and proposals for the Information Model: > http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/slides-interim-2015-lmap-1-1.pptx > > In summary the main proposals are: > - To keep the JSON example data model (with corrections) and to also add to the references the YANG data model (draft-schoenw-lmap-yang) > - To standardise the well-known objects for Channel and Role, even though they are optional task parameters to aid interworking across different tasks > - To evolve the current general MA status information into MA and task specific status information > - To evolve the current general MA condition codes into MA and task specific condition codes > - Clarify that options for a scheduled task are appended to the options specified for the general task configuration > > Any additional comments and suggestions are welcome until 23rd February, after which I will go ahead and make the changes. Please don't bother sending spelling corrections as I have already spellchecked it (and made the other minor corrections already suggested) ready for the more substantive 04 changes. > > Trevor. > > Trevor Burbridge > Network Infrastructure & Innovation | BT Research & Innovation > Tel: 01473 645115 > Fax: 01473 640929 > > This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > _______________________________________________ > 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 Feb 16 12:05:51 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252201A889B; Mon, 16 Feb 2015 12:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5IIKHPjZh3D; Mon, 16 Feb 2015 12:05:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDAC1A8890; Mon, 16 Feb 2015 12:05:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216200547.8899.38616.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 12:05:47 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:05:49 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Mon Feb 16 12:05:54 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 722871A88A7; Mon, 16 Feb 2015 12:05:49 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252201A889B; Mon, 16 Feb 2015 12:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5IIKHPjZh3D; Mon, 16 Feb 2015 12:05:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDAC1A8890; Mon, 16 Feb 2015 12:05:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216200547.8899.38616.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 12:05:47 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:05:49 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Mon Feb 16 14:05:56 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0776F1A88FD; Mon, 16 Feb 2015 14:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObJ3EuerBEWt; Mon, 16 Feb 2015 14:05:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDBE1A88EB; Mon, 16 Feb 2015 14:05:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216220552.23489.73234.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 14:05:52 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 22:05:54 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Mon Feb 16 14:05:58 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-use-cases.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1DE771A8902; Mon, 16 Feb 2015 14:05:54 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0776F1A88FD; Mon, 16 Feb 2015 14:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObJ3EuerBEWt; Mon, 16 Feb 2015 14:05:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDBE1A88EB; Mon, 16 Feb 2015 14:05:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216220552.23489.73234.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 14:05:52 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 22:05:54 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ From nobody Tue Feb 17 02:04:38 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214241A86EA for ; Tue, 17 Feb 2015 02:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 elqW_6nkIvV6 for ; Tue, 17 Feb 2015 02:04:35 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88EE1A86E5 for ; Tue, 17 Feb 2015 02:04:34 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Feb 2015 10:03:41 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 17 Feb 2015 10:03:04 +0000 From: To: Date: Tue, 17 Feb 2015 10:03:02 +0000 Thread-Topic: [lmap] Information Model - Proposed changes to 04 Thread-Index: AdBJ+6vnlCiTc/InQFez0K//Vi9XhwAm9RWA Message-ID: References: <20150216151715.GB11458@elstar.local> In-Reply-To: <20150216151715.GB11458@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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] Information Model - Proposed changes to 04 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 10:04:37 -0000 See inline... >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: 16 February 2015 15:17 >To: Burbridge,T,Trevor,TUB8 R >Cc: lmap@ietf.org >Subject: Re: [lmap] Information Model - Proposed changes to 04 > >Hi, > >there were a few more things mentioned on the list: > >- introducing a configuration version number to avoid having to send > the complete config back with reports; do we really want to assume > that config is echoed with each report? We've said that the flexibility of what to report is under the control of t= he reporting task implementation and configuration options. At the moment t= he task options are optional to be reported, but the task configuration has= a text string name which is always reported. I thought this was sufficient= but if we want a name AND version number we could add another field. Having said that I do think we do need to make a change since it is only th= e task configuration name (and options) that are reported. I need to add in= the schedule name and scheduled task options. >- clarify the semantics of feeding data between tasks following > different schedules, buffering and blocking issues I'll do this in a separate example. I don't think there is a problem with t= he Information Model, but we'll see. >- status (condition) codes - do we want to have common ones or is every > data model / protocol free to invent their own codes? Yes, this has been a question for a while, but I don't have any proposals t= o put into the next iteration of the Information Model. >/js > >On Mon, Feb 16, 2015 at 01:47:41PM +0000, trevor.burbridge@bt.com wrote: >> For anyone who didn't manage to attend the interim, here are the slides = and >proposals for the Information Model: >> http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/slides- >> interim-2015-lmap-1-1.pptx >> >> In summary the main proposals are: >> - To keep the JSON example data model (with corrections) and to also >> add to the references the YANG data model (draft-schoenw-lmap-yang) >> - To standardise the well-known objects for Channel and Role, even >> though they are optional task parameters to aid interworking across >> different tasks >> - To evolve the current general MA status information into MA and task >> specific status information >> - To evolve the current general MA condition codes into MA and task >> specific condition codes >> - Clarify that options for a scheduled task are appended to the >> options specified for the general task configuration >> >> Any additional comments and suggestions are welcome until 23rd February, >after which I will go ahead and make the changes. Please don't bother send= ing >spelling corrections as I have already spellchecked it (and made the other= minor >corrections already suggested) ready for the more substantive 04 changes. >> >> Trevor. >> >> Trevor Burbridge >> Network Infrastructure & Innovation | BT Research & Innovation >> Tel: 01473 645115 >> Fax: 01473 640929 >> >> This email contains BT information, which may be privileged or confident= ial. It's >meant only for the individual(s) or entity named above. If you're not the = intended >recipient, note that disclosing, copying, distributing or using this infor= mation is >prohibited. If you've received this email in error, please let me know imm= ediately >on the email address above. Thank you. >> We monitor our email system, and may record your emails. >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ Registered in >> England no: 1800000 >> >> >> _______________________________________________ >> 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 Tue Feb 17 10:25:24 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97F1A1B85 for ; Tue, 17 Feb 2015 10:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9ai5HgkBjLV for ; Tue, 17 Feb 2015 10:25:17 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24651A8F33 for ; Tue, 17 Feb 2015 10:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15156; q=dns/txt; s=iport; t=1424197515; x=1425407115; h=message-id:date:from:mime-version:to:cc:subject; bh=Y0zoEU8t2TADfgegPbvN+OLJkNyUV479QXE6UP058z0=; b=ai0rN9nkZggrvEf3xFPWAryXWrWAccG6VlKghMdPWvyUo3IRZI11cvwK WQ0p4qNbAc1hmgGz635I7XrDvjko3hfIEF8azZhGkZy8++H8yrEwBf8bP 1ES2E5Bo8rXIuESlPJqLxh7h5gv4msaREOZQFv+5BQJVPATI95R1LseY6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BoBgAkhuNU/xbLJq1bg1haAYMCthCHUoFwhW+BWwEBAQEBAXyENgRRARkjFgsCCwMCAQIBSwoDAQcBAYgrDZxunGyXdwEBAQEBAQEDAQEBAQEBAQEBGY99gm+BQgWFWo01hWCBGDiCVYIqIYhfgz4ig289MQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208,217";a="348393510" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Feb 2015 18:25:12 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1HIPBCt012767; Tue, 17 Feb 2015 18:25:12 GMT Message-ID: <54E38787.2090009@cisco.com> Date: Tue, 17 Feb 2015 19:25:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "lmap@ietf.org" Content-Type: multipart/alternative; boundary="------------070404070103000106070809" Archived-At: Cc: Radia Perlman , "draft-ietf-lmap-framework@tools.ietf.org" Subject: [lmap] AD review of draft-ietf-lmap-framework-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 18:25:21 -0000 This is a multi-part message in MIME format. --------------070404070103000106070809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, First of all, very sorry for the delay in getting back to you. Thank you for this new draft version. The document really improved between version 8 and 10. Here is my feedback on version 10. Nothing major. I propose to start the IETF LC as soon a new version is posted - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP stands for Large-scale Measurement of Broadband Performance. Here, in the abstract, it stands for large-scale measurement platforms. Please change it. - Some repetitions in section 1 It is expected that such a system could easily comprise 100,000 devices. It is expected that a Measurement System could easily encompass a few hundred thousand or even millions of Measurement Agents. - Section 2 OLD: Another possibility is for the MA may generate (or receive) traffic specially created for the purpose and measure some metric associated with its transfer. NEW: Another possibility is for the MA_to_generate (or receive) traffic specially created for the purpose and measure some metric associated with its transfer. - Section 2 OLD: Messages are transferred over a secure Channel. NEW: Both control and report messages are transferred over a secure Channel. - results repository or Results repository? Please check all instances. - Figure 1 The Report goes over the Report Channel, not Control Channel - Figure 1 The traffic between "End user or Measurement Peer" represents the MA passive monitoring. If you would add an arrow from the MA to End User or Measurement Peer on the right (to show that some MAs can generate active traffic), you would have a complete picture. Something like this: +-----------+ +-----------+ ^ |End user or| |End user or| | |Measurement| |Measurement| Non-LMAP | Peer | | Peer | Scope +-----------+ +-----------+ v ^ ^ ^ \ Observed +---------------+ / / ^ \.........|...............|........../ / | Traffic Flow | Measurement ..|.........../ | +----------->| Agent |Measurement Traffic | | +---------------+ | Note that I have reused your terminology: Measurement Traffic and Observed Traffic Flow - Section 5.2.2 Instruction: -> [(Measurement Task configuration URI of Metric( [Input Parameter], (interface), (Cycle-ID))), (Report Channel), (Schedule), (Suppression information)] Should we expect a 1:1 mapping between the parameters above and the list that follows? For example, I see in the list * the Measurement Method role. For some Measurement Methods, different parties play different roles; for example (figure A3 in the Appendix) an iperf sender and receiver. Each Metric and its associated Measurement Method will describe all measurement roles involved in the process. * optionally, the measurement point designation [I-D.ietf-ippm-lmap-path ] of the MA and, if applicable, of the MP or other MA. This can be useful for reporting. - Section 5.2.2 I guess that most MAs will have one Report Channel, as the default option. Right? OLD: o configuration of the Report Channels, each of which needs: NEW: o configuration of the Report Channel(s), each of which needs: - Section 5.2.3 OLD: the MA failed record the Measurement Results because it (unexpectedly) is out of spare memory NEW: the MA failed_to_record the Measurement Results because it (unexpectedly) is out of spare memory - Section 5.4.1 To match the charter: OLD: It may also be possible to transfer the information via the MA. NEW: If the subscriber's service parameters are available to the MAs, they could be reported with the Measurement Results in the Report Protocol. - section 6 Deployment considerations The Appendix has some examples of possible deployment arrangements of Measurement Agents and Peers. What does this text tell me? Should I read the appendix before proceeding? If yes (btw, I think this is the natural reading flow), why is this an appendix, and not in the core of the document? Note: this appendix contains some nice examples that really glue all the concepts into practical examples. - Appendix A OLD: Next, we consider Measurement Methods that measure user traffic. NEW: Next, we consider Measurement Methods that meter the Observed Traffic Flow. NEW figure A4 +--------+ +----------------+ +--------+ ^ |End user| | MA: Monitor | Observed |End user| | | or MP |<--|----------------|--Traffic ->| or MP | non-LMAP | | | | Flow | | Scope +--------+ | | +--------+ | ...|................|............................v.. | LMAP interface | ^ +----------------+ | ^ | | Instruction | | Report | | +-----------------+ | | | | | v LMAP +------------+ +------------+ Scope | Controller | | Collector | | +------------+ +------------+ v Figure A4: Schematic of LMAP-based Measurement System, with a Measurement Agent monitoring traffic - Security Considerations There is a privacy aspects for Observed Traffic Flow (typically the figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe some others). FYI. This has been addressed in IPFIX: see https://tools.ietf.org/html/rfc7011#section-11.8 - Question: Have you discussed the ability for LMAP to use sampling for Observed Traffic Flows? Is this necessary? See http://datatracker.ietf.org/wg/psamp/documents/ Regards, Benoit --------------070404070103000106070809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

First of all, very sorry for the delay in getting back to you.
Thank you for this new draft version. The document really improved between version 8 and 10.
Here is my feedback on version 10. Nothing major. I propose to start the IETF LC as soon a new version is posted

- In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP stands for Large-scale Measurement of Broadband Performance.
Here, in the abstract, it stands for large-scale measurement platforms. Please change it.

- Some repetitions in section 1
   It is expected
   that such a system could easily comprise 100,000 devices.

      It is expected that a Measurement
      System could easily encompass a few hundred thousand or even
      millions of Measurement Agents.
- Section 2
OLD:
   Another possibility is for the
   MA may generate (or receive) traffic specially created for the
   purpose and measure some metric associated with its transfer.  

NEW:
   Another possibility is for the
   MA to generate (or receive) traffic specially created for the
   purpose and measure some metric associated with its transfer.
- Section 2
OLD:
	Messages are transferred over a secure Channel. 

NEW:
	Both control and report messages are transferred over a secure Channel. 

-
results repository or Results repository?
Please check all instances.

- Figure 1
The Report goes over the Report Channel, not Control Channel

- Figure 1
The traffic between "End user or Measurement Peer" represents the MA passive monitoring.
If you would add an arrow from the MA to End User or Measurement Peer on the right (to show that some MAs can generate active traffic), you would have a complete picture.
Something like this:

   +-----------+                         +-----------+     ^
   |End user or|                         |End user or|     |
   |Measurement|                         |Measurement| Non-LMAP
   |  Peer     |                         |   Peer    |   Scope
   +-----------+                         +-----------+     v
       ^                                        ^ ^ 
        \ Observed +---------------+           / /         ^
         \.........|...............|........../ /          |
      Traffic Flow | Measurement ..|.........../           |
      +----------->|   Agent       |Measurement Traffic    |
      |            +---------------+                       |
 
Note that I have reused your terminology: Measurement Traffic and Observed Traffic Flow

- Section 5.2.2
Instruction:                            ->
   [(Measurement Task configuration
       URI of Metric(
      [Input Parameter],
      (interface),
      (Cycle-ID))),
    (Report Channel),
    (Schedule),
    (Suppression information)]
Should we expect a 1:1 mapping between the parameters above and the list that follows?
For example, I see in the list 
         * the Measurement Method role.  For some Measurement Methods,
         different parties play different roles; for example (figure A3
         in the Appendix) an iperf sender and receiver.  Each Metric and
         its associated Measurement Method will describe all measurement
         roles involved in the process.

         * optionally, the measurement point designation
         [I-D.ietf-ippm-lmap-path] of the MA and, if applicable, of the
         MP or other MA.  This can be useful for reporting.
- Section 5.2.2
I guess that most MAs will have one Report Channel, as the default option. Right?
OLD:
 o  configuration of the Report Channels, each of which needs:

NEW:
 o  configuration of the Report Channel(s), each of which needs:
- Section 5.2.3

OLD:
      the MA failed record the Measurement Results because it
      (unexpectedly) is out of spare memory

NEW:
      the MA failed to record the Measurement Results because it
      (unexpectedly) is out of spare memory
- Section 5.4.1
To match the charter:
OLD:
    It may also be possible to transfer the information via the MA.

NEW:   
    If the subscriber's service parameters are available to the MAs, they could be reported
    with the Measurement Results in the Report Protocol.

- section 6 Deployment considerations 
   The Appendix has some examples of possible deployment arrangements of
   Measurement Agents and Peers.
What does this text tell me? Should I read the appendix before proceeding?
If yes (btw, I think this is the natural reading flow), why is this an appendix, and not in the core of the document?
Note: this appendix contains some nice examples that really glue all the concepts into practical examples.

- Appendix A
OLD:
   Next, we consider Measurement Methods that measure user traffic.
NEW:
   Next, we consider Measurement Methods that meter the Observed Traffic Flow.
NEW figure A4
   +--------+   +----------------+            +--------+      ^
   |End user|   |  MA: Monitor   |  Observed  |End user|      |
   | or MP  |<--|----------------|--Traffic ->| or MP  |  non-LMAP
   |        |   |                |  Flow      |        |    Scope
   +--------+   |                |            +--------+      |
             ...|................|............................v..
                | LMAP interface |                            ^
                +----------------+                            |
                        ^     |                               |
            Instruction |     |  Report                       |
                        |     +-----------------+             |
                        |                       |             |
                        |                       v            LMAP
                  +------------+             +------------+  Scope
                  | Controller |             |  Collector |   |
                  +------------+             +------------+   v


   Figure A4: Schematic of LMAP-based Measurement System,
   with a Measurement Agent monitoring traffic

- Security Considerations
There is a privacy aspects for Observed Traffic Flow (typically the figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe some others). FYI. This has been addressed in IPFIX: see https://tools.ietf.org/html/rfc7011#section-11.8

- Question: Have you discussed the ability for LMAP to use sampling for Observed Traffic Flows? Is this necessary?
See http://datatracker.ietf.org/wg/psamp/documents/

Regards, Benoit
--------------070404070103000106070809-- From nobody Wed Feb 18 06:42:31 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722DD1A893E for ; Wed, 18 Feb 2015 06:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq1d6yQbN0mt for ; Wed, 18 Feb 2015 06:42:26 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7681A8932 for ; Wed, 18 Feb 2015 06:42:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikGACak5FTGmAcV/2dsb2JhbABbgkMhIiIwWgSvfQEBAQEBB5ImHwEIhXICgRxDAQEBAQEBfIQOAQEDEgsQXgEVFVYmAQQbGogNAQyqUoR/ongBAQgCAR+GBIYuGgGCfy2COAxAHYEUBY9Dg1mHNIUXg36ILCKBW4ITbwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.09,602,1418101200"; d="scan'208,217";a="104513625" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Feb 2015 09:42:24 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 18 Feb 2015 09:42:23 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 18 Feb 2015 15:42:21 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Call for Submissions for the LMAP Control and LMAP Report Protocols Thread-Index: AdBLiRmBfmBBj1JFTuiHw3QkbjldvQ== Date: Wed, 18 Feb 2015 14:42:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C99B0CA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C99B0CAAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Call for Submissions for the LMAP Control and LMAP Report Protocols X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 14:42:30 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C99B0CAAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a Call for Submissions for protocols that would meet the requiremen= ts for the Large Scale Measurement of Broadband Performance (LMAP) Control = and Report protocols. The protocol proposals need to be submitted as indivi= dual submission Internet-Drafts before the submission cutoff date for IETF = 92 which is March 9, 2015. The LMAP WG plans to discuss the candidate propo= sals at IETF 92 and make a consensus decision of protocols selection soon a= fter. The LMAP WG charter can be found at https://datatracker.ietf.org/wg/lmap/ch= arter/, The Protocol Selection Criteria are documented in https://datatracker.ietf.= org/doc/draft-starkcarey-lmap-protocol-criteria/. Thanks and Regards, Dan Romascanu Jason Weil (LMAP WG co-chairs) --_000_9904FB1B0159DA42B0B887B7FA8119CA5C99B0CAAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is a Call for Submissions for prot= ocols that would meet the requirements for the Large Scale Measurement of B= roadband Performance (LMAP) Control and Report protocols. The protocol proposals need to be submitted as individual submission Inter= net-Drafts before the submission cutoff date for IETF 92 which is March 9, = 2015. The LMAP WG plans to discuss the candidate proposals at IETF 92 and m= ake a consensus decision of protocols selection soon after.

 

The LMAP WG charter can be found at https://datatracker.ietf.org/wg/lma= p/charter/,

 

The Protocol Selection Criteria are doc= umented in https://datatracker.ietf.org/doc/draft-starkcarey-lmap-proto= col-criteria/.

 

Thanks and Regards,

 

Dan Romascanu

Jason Weil

(LMAP WG co-chairs)

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C99B0CAAZFFEXMB04globa_-- From nobody Sun Feb 22 03:04:42 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9891A1BAE for ; Sun, 22 Feb 2015 03:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[SPF_SOFTFAIL=0.972] autolearn=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 fiPO9rngxXl6 for ; Sun, 22 Feb 2015 03:03:25 -0800 (PST) Received: from s1.neomailbox.net (s1.neomailbox.net [5.148.176.57]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B396E1A1BAC for ; Sun, 22 Feb 2015 03:03:25 -0800 (PST) Message-ID: <54E9B772.101@neomailbox.ch> Date: Sun, 22 Feb 2015 12:03:14 +0100 From: marcelo bagnulo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benoit Claise , "lmap@ietf.org" References: <54E38787.2090009@cisco.com> In-Reply-To: <54E38787.2090009@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 03:04:41 -0800 Cc: Radia Perlman , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] AD review of draft-ietf-lmap-framework-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Feb 2015 11:03:27 -0000 Hi, Thanks for the review. I think we addressed all your points. We will submit an updated version of the document now and if there are more changes needed, we submit another one. El 17/02/15 a las 19:25, Benoit Claise escribió: > Dear all, > > First of all, very sorry for the delay in getting back to you. > Thank you for this new draft version. The document really improved > between version 8 and 10. > Here is my feedback on version 10. Nothing major. I propose to start > the IETF LC as soon a new version is posted > > - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP > stands for Large-scale Measurement of Broadband Performance. > Here, in the abstract, it stands for large-scale measurement > platforms. Please change it. > done > - Some repetitions in section 1 > It is expected > that such a system could easily comprise 100,000 devices. > > It is expected that a Measurement > System could easily encompass a few hundred thousand or even > millions of Measurement Agents. agree, rephrased as: There is a desire to be able to coordinate the execution of broadband measurements and the collection of measurement results across a large scale set of Measurement Agents (MAs). These MAs could be software based agents on PCs, embedded agents in consumer devices (such as TVs or gaming consoles), embedded in service provider controlled devices such as set-top boxes and home gateways, or simply dedicated probes. MAs may also be embedded on a device that is part of an ISP's network, such as a DSLAM (Digital Subscriber Line Access Multiplexer), router, Carrier Grade NAT (Network Address Translator) or ISP Gateway. It is expected that a measurement system could easily encompass a few hundred thousand or even millions of such MAs. Such a scale presents unique problems in coordination, execution and measurement result collection. > - Section 2 > OLD: > Another possibility is for the > MA may generate (or receive) traffic specially created for the > purpose and measure some metric associated with its transfer. > > NEW: > Another possibility is for the > MA_to_generate (or receive) traffic specially created for the > purpose and measure some metric associated with its transfer. ok > > - Section 2 > OLD: > Messages are transferred over a secure Channel. > > NEW: > Both control and report messages are transferred over a secure Channel. ok > - > results repository or Results repository? > Please check all instances. > it is Results repository because Results is an LMAP defined term while the repository it is not (it is out of the scope of the framework) The usage is consisten throughout the document. > - Figure 1 > The Report goes over the Report Channel, not Control Channel > ok > - Figure 1 > The traffic between "End user or Measurement Peer" represents the MA > passive monitoring. > If you would add an arrow from the MA to End User or Measurement Peer > on the right (to show that some MAs can generate active traffic), you > would have a complete picture. > Something like this: > > +-----------+ +-----------+ ^ > |End user or| |End user or| | > |Measurement| |Measurement| Non-LMAP > | Peer | | Peer | Scope > +-----------+ +-----------+ v > ^ ^ ^ > \ Observed +---------------+ / / ^ > \.........|...............|........../ / | > Traffic Flow | Measurement ..|.........../ | > +----------->| Agent |Measurement Traffic | > | +---------------+ | > > Note that I have reused your terminology: Measurement Traffic and > Observed Traffic Flow > done > - Section 5.2.2 > Instruction: -> > [(Measurement Task configuration > URI of Metric( > [Input Parameter], > (interface), > (Cycle-ID))), > (Report Channel), > (Schedule), > (Suppression information)] > Should we expect a 1:1 mapping between the parameters above and the > list that follows? > For example, I see in the list > * the Measurement Method role. For some Measurement Methods, > different parties play different roles; for example (figure A3 > in the Appendix) an iperf sender and receiver. Each Metric and > its associated Measurement Method will describe all measurement > roles involved in the process. > > * optionally, the measurement point designation > [I-D.ietf-ippm-lmap-path ] of the MA and, if applicable, of the > MP or other MA. This can be useful for reporting. Right. I have include both the role and the measurment point in the figure. > - Section 5.2.2 > I guess that most MAs will have one Report Channel, as the default > option. Right? > OLD: > o configuration of the Report Channels, each of which needs: > > NEW: > o configuration of the Report Channel(s), each of which needs: ok > - Section 5.2.3 > > OLD: > the MA failed record the Measurement Results because it > (unexpectedly) is out of spare memory > > NEW: > the MA failed_to_record the Measurement Results because it > (unexpectedly) is out of spare memory ok > - Section 5.4.1 > To match the charter: > OLD: > It may also be possible to transfer the information via the MA. > > NEW: > If the subscriber's service parameters are available to the MAs, > they could be reported > with the Measurement Results in the Report Protocol. > ok > - section 6 Deployment considerations > The Appendix has some examples of possible deployment arrangements of > Measurement Agents and Peers. > What does this text tell me? Should I read the appendix before proceeding? > If yes (btw, I think this is the natural reading flow), why is this an > appendix, and not in the core of the document? > Note: this appendix contains some nice examples that really glue all > the concepts into practical examples. > ok, i have moved the examples to section 6 > - Appendix A > OLD: > Next, we consider Measurement Methods that measure user traffic. > NEW: > Next, we consider Measurement Methods that meter the Observed Traffic Flow. ok > NEW figure A4 > +--------+ +----------------+ +--------+ ^ > |End user| | MA: Monitor | Observed |End user| | > | or MP |<--|----------------|--Traffic ->| or MP | non-LMAP > | | | | Flow | | Scope > +--------+ | | +--------+ | > ...|................|............................v.. > | LMAP interface | ^ > +----------------+ | > ^ | | > Instruction | | Report | > | +-----------------+ | > | | | > | v LMAP > +------------+ +------------+ Scope > | Controller | | Collector | | > +------------+ +------------+ v > > > Figure A4: Schematic of LMAP-based Measurement System, > with a Measurement Agent monitoring traffic > ok > - Security Considerations > There is a privacy aspects for Observed Traffic Flow (typically the > figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe > some others). FYI. This has been addressed in IPFIX: see > https://tools.ietf.org/html/rfc7011#section-11.8 > ok, i added a reference to RFC7011 in section 8.3 > - Question: Have you discussed the ability for LMAP to use sampling > for Observed Traffic Flows? Is this necessary? > See http://datatracker.ietf.org/wg/psamp/documents/ > The current framework doesnt go deep into the specifics of the different measurement (just what is needed to understand the framework), so i believe this probably is too specific for this document. I dont really have a strong opinion. If you have an specific text you would like to include in the document, feel free to suggest, we will be happy to discuss it. Regards, marcelo > Regards, Benoit From nobody Sun Feb 22 03:13:09 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE761A1BDB; Sun, 22 Feb 2015 03:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20mqDustjWCn; Sun, 22 Feb 2015 03:13:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0991A1BDE; Sun, 22 Feb 2015 03:13:00 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222111300.28364.63236.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 03:13:00 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-11.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 11:13:05 -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 Working Group of the IETF. Title : A framework for Large-Scale Measurement of Broadband Performance (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-11.txt Pages : 58 Date : 2015-02-22 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 22 03:13:10 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553071A1BDE; Sun, 22 Feb 2015 03:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPbbGlCBXuME; Sun, 22 Feb 2015 03:13:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E381A1BE0; Sun, 22 Feb 2015 03:13:00 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222111300.28364.53453.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 03:13:00 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-framework-11.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 11:13:06 -0000 A new version (-11) has been submitted for draft-ietf-lmap-framework: http://www.ietf.org/internet-drafts/draft-ietf-lmap-framework-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-11 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. IETF Secretariat. From nobody Sun Feb 22 03:13:11 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-framework.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 73C171A1BE0; Sun, 22 Feb 2015 03:13:06 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553071A1BDE; Sun, 22 Feb 2015 03:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPbbGlCBXuME; Sun, 22 Feb 2015 03:13:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E381A1BE0; Sun, 22 Feb 2015 03:13:00 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222111300.28364.53453.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 03:13:00 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-framework-11.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 11:13:06 -0000 A new version (-11) has been submitted for draft-ietf-lmap-framework: http://www.ietf.org/internet-drafts/draft-ietf-lmap-framework-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-11 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. IETF Secretariat. From nobody Sun Feb 22 03:13:40 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CAB1A1BB8 for ; Sun, 22 Feb 2015 03:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-iAR-Fbm1tH for ; Sun, 22 Feb 2015 03:13:34 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CD21A1BD7 for ; Sun, 22 Feb 2015 03:13:34 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id b13so20737756wgh.0 for ; Sun, 22 Feb 2015 03:13:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CNh1Zuik1V0X8mLc/9LnNOencvZBw/JtjzAaLy+69Is=; b=SI+BsDLEoAfQ4Xu5IDRq/k1pp+pfb0hBGaTgepvL3s/YINSCX7zVzaSMFS9QxZf2C2 Slyg2MiH5Ym7x6jcamLQt1J/dU7Yjs12fJ+bnKpccFsok2IDxRtivOuomyqQpNwShILz dtMJCn3uBxNMB1QT8K6XZ1w3Vnhi2plwmaB2dJlwQvoLqU5VarArR5vsZYT3TAtGIPl8 fguEgmoEj1wlk45aojWCfvJlJacCr/g+oAXn/6wGqvKWapzZUCJH4V329I/NLG9SNkZP 928ETsKy1Dv9HR9sabAYxg6Q7Ehwz6b25lk5xH9mW1yyDDoqMI/15KBgmVyY8PVAScc7 LzAA== X-Gm-Message-State: ALoCoQmAzgfqDcEor0vDUGAAoFE0+mQdsATfSmHMJeRDRX0j+kPF7blUyIacVEhRLmQ4H0EzmvlS X-Received: by 10.194.86.135 with SMTP id p7mr12221357wjz.89.1424603612686; Sun, 22 Feb 2015 03:13:32 -0800 (PST) Received: from Macintosh-2.local (224.205.221.87.dynamic.jazztel.es. [87.221.205.224]) by mx.google.com with ESMTPSA id ax10sm50659157wjc.26.2015.02.22.03.13.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 03:13:32 -0800 (PST) Message-ID: <54E9B9D9.4090000@it.uc3m.es> Date: Sun, 22 Feb 2015 12:13:29 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "lmap@ietf.org" References: <54E9B772.101@neomailbox.ch> In-Reply-To: <54E9B772.101@neomailbox.ch> X-Forwarded-Message-Id: <54E9B772.101@neomailbox.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [lmap] Fwd: Re: AD review of draft-ietf-lmap-framework-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Feb 2015 11:13:39 -0000 resending with correct source address -------- Mensaje reenviado -------- Asunto: Re: AD review of draft-ietf-lmap-framework-10 Fecha: Sun, 22 Feb 2015 12:03:14 +0100 De: marcelo bagnulo Para: Benoit Claise , lmap@ietf.org CC: Radia Perlman , draft-ietf-lmap-framework@tools.ietf.org Hi, Thanks for the review. I think we addressed all your points. We will submit an updated version of the document now and if there are more changes needed, we submit another one. El 17/02/15 a las 19:25, Benoit Claise escribió: > Dear all, > > First of all, very sorry for the delay in getting back to you. > Thank you for this new draft version. The document really improved > between version 8 and 10. > Here is my feedback on version 10. Nothing major. I propose to start > the IETF LC as soon a new version is posted > > - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP > stands for Large-scale Measurement of Broadband Performance. > Here, in the abstract, it stands for large-scale measurement > platforms. Please change it. > done > - Some repetitions in section 1 > It is expected > that such a system could easily comprise 100,000 devices. > > It is expected that a Measurement > System could easily encompass a few hundred thousand or even > millions of Measurement Agents. agree, rephrased as: There is a desire to be able to coordinate the execution of broadband measurements and the collection of measurement results across a large scale set of Measurement Agents (MAs). These MAs could be software based agents on PCs, embedded agents in consumer devices (such as TVs or gaming consoles), embedded in service provider controlled devices such as set-top boxes and home gateways, or simply dedicated probes. MAs may also be embedded on a device that is part of an ISP's network, such as a DSLAM (Digital Subscriber Line Access Multiplexer), router, Carrier Grade NAT (Network Address Translator) or ISP Gateway. It is expected that a measurement system could easily encompass a few hundred thousand or even millions of such MAs. Such a scale presents unique problems in coordination, execution and measurement result collection. > - Section 2 > OLD: > Another possibility is for the > MA may generate (or receive) traffic specially created for the > purpose and measure some metric associated with its transfer. > > NEW: > Another possibility is for the > MA_to_generate (or receive) traffic specially created for the > purpose and measure some metric associated with its transfer. ok > > - Section 2 > OLD: > Messages are transferred over a secure Channel. > > NEW: > Both control and report messages are transferred over a secure Channel. ok > - > results repository or Results repository? > Please check all instances. > it is Results repository because Results is an LMAP defined term while the repository it is not (it is out of the scope of the framework) The usage is consisten throughout the document. > - Figure 1 > The Report goes over the Report Channel, not Control Channel > ok > - Figure 1 > The traffic between "End user or Measurement Peer" represents the MA > passive monitoring. > If you would add an arrow from the MA to End User or Measurement Peer > on the right (to show that some MAs can generate active traffic), you > would have a complete picture. > Something like this: > > +-----------+ +-----------+ ^ > |End user or| |End user or| | > |Measurement| |Measurement| Non-LMAP > | Peer | | Peer | Scope > +-----------+ +-----------+ v > ^ ^ ^ > \ Observed +---------------+ / / ^ > \.........|...............|........../ / | > Traffic Flow | Measurement ..|.........../ | > +----------->| Agent |Measurement Traffic | > | +---------------+ | > > Note that I have reused your terminology: Measurement Traffic and > Observed Traffic Flow > done > - Section 5.2.2 > Instruction: -> > [(Measurement Task configuration > URI of Metric( > [Input Parameter], > (interface), > (Cycle-ID))), > (Report Channel), > (Schedule), > (Suppression information)] > Should we expect a 1:1 mapping between the parameters above and the > list that follows? > For example, I see in the list > * the Measurement Method role. For some Measurement Methods, > different parties play different roles; for example (figure A3 > in the Appendix) an iperf sender and receiver. Each Metric and > its associated Measurement Method will describe all measurement > roles involved in the process. > > * optionally, the measurement point designation > [I-D.ietf-ippm-lmap-path ] of the MA and, if applicable, of the > MP or other MA. This can be useful for reporting. Right. I have include both the role and the measurment point in the figure. > - Section 5.2.2 > I guess that most MAs will have one Report Channel, as the default > option. Right? > OLD: > o configuration of the Report Channels, each of which needs: > > NEW: > o configuration of the Report Channel(s), each of which needs: ok > - Section 5.2.3 > > OLD: > the MA failed record the Measurement Results because it > (unexpectedly) is out of spare memory > > NEW: > the MA failed_to_record the Measurement Results because it > (unexpectedly) is out of spare memory ok > - Section 5.4.1 > To match the charter: > OLD: > It may also be possible to transfer the information via the MA. > > NEW: > If the subscriber's service parameters are available to the MAs, > they could be reported > with the Measurement Results in the Report Protocol. > ok > - section 6 Deployment considerations > The Appendix has some examples of possible deployment arrangements of > Measurement Agents and Peers. > What does this text tell me? Should I read the appendix before proceeding? > If yes (btw, I think this is the natural reading flow), why is this an > appendix, and not in the core of the document? > Note: this appendix contains some nice examples that really glue all > the concepts into practical examples. > ok, i have moved the examples to section 6 > - Appendix A > OLD: > Next, we consider Measurement Methods that measure user traffic. > NEW: > Next, we consider Measurement Methods that meter the Observed Traffic Flow. ok > NEW figure A4 > +--------+ +----------------+ +--------+ ^ > |End user| | MA: Monitor | Observed |End user| | > | or MP |<--|----------------|--Traffic ->| or MP | non-LMAP > | | | | Flow | | Scope > +--------+ | | +--------+ | > ...|................|............................v.. > | LMAP interface | ^ > +----------------+ | > ^ | | > Instruction | | Report | > | +-----------------+ | > | | | > | v LMAP > +------------+ +------------+ Scope > | Controller | | Collector | | > +------------+ +------------+ v > > > Figure A4: Schematic of LMAP-based Measurement System, > with a Measurement Agent monitoring traffic > ok > - Security Considerations > There is a privacy aspects for Observed Traffic Flow (typically the > figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe > some others). FYI. This has been addressed in IPFIX: see > https://tools.ietf.org/html/rfc7011#section-11.8 > ok, i added a reference to RFC7011 in section 8.3 > - Question: Have you discussed the ability for LMAP to use sampling > for Observed Traffic Flows? Is this necessary? > See http://datatracker.ietf.org/wg/psamp/documents/ > The current framework doesnt go deep into the specifics of the different measurement (just what is needed to understand the framework), so i believe this probably is too specific for this document. I dont really have a strong opinion. If you have an specific text you would like to include in the document, feel free to suggest, we will be happy to discuss it. Regards, marcelo > Regards, Benoit From nobody Sun Feb 22 03:16:25 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88241A1BB8 for ; Sun, 22 Feb 2015 03:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqRcr0zMCpQJ for ; Sun, 22 Feb 2015 03:16:21 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F431A1BB0 for ; Sun, 22 Feb 2015 03:16:20 -0800 (PST) Received: by wevm14 with SMTP id m14so13027690wev.13 for ; Sun, 22 Feb 2015 03:16:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TysrDptFnvEI5GvNegOcJRPwf3cqfZ8VfuUQAbxmUkY=; b=LCVAaAUg19vDH3+3SP9t6g6Vy3nTSE6zheHneP7VqmVR8EZn35Ferr/qxaKiNdggZH G6m5+lq9lHCP5V5v4WwU3sQTn6Yqh0JzroU1xatDFZP6EZjq6FXxHs52JXarCdx0pgHC xcxurtHi9DU9qLG85nV/RwS10BZNbZ5vSlGSj1ckq7VV31dFk1oRdf5MLqCHJ80QeU5+ r3jHWF5gBFveb7aaLpMLY6FSzCP5lsdQ9+COzYbn6qWP2ZQLJfWUO05ZHiNXYu56G8Kb +O2EGWadQCQ0s9GPw8P+2PSV54Cf3wVAtyngij2Tl+gvFV1RDRrPe1LAjJIGgCtqzYBP E8nA== X-Gm-Message-State: ALoCoQnekiCSUvI45SARYct6pPur660QV+3F7tsQ5qTjUlQHoK8ecBmcY9JLe07cyirE9h37akmI X-Received: by 10.180.90.197 with SMTP id by5mr11177714wib.70.1424603778992; Sun, 22 Feb 2015 03:16:18 -0800 (PST) Received: from Macintosh-2.local (224.205.221.87.dynamic.jazztel.es. [87.221.205.224]) by mx.google.com with ESMTPSA id yy9sm50672727wjc.20.2015.02.22.03.16.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 03:16:18 -0800 (PST) Message-ID: <54E9BA80.3090304@it.uc3m.es> Date: Sun, 22 Feb 2015 12:16:16 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benoit Claise , "lmap@ietf.org" References: <54E38787.2090009@cisco.com> <54E9B772.101@neomailbox.ch> In-Reply-To: <54E9B772.101@neomailbox.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] AD review of draft-ietf-lmap-framework-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Feb 2015 11:16:24 -0000 Hi, I have just submitted a new version of the draft with the proposed changes. Hopefully this clears the path for this draft moving forward. The new version of the draft is: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-11 Regards, marcelo El 22/02/15 a las 12:03, marcelo bagnulo escribió: > Hi, > > Thanks for the review. I think we addressed all your points. We will > submit an updated version of the document now and if there are more > changes needed, we submit another one. > > El 17/02/15 a las 19:25, Benoit Claise escribió: >> Dear all, >> >> First of all, very sorry for the delay in getting back to you. >> Thank you for this new draft version. The document really improved >> between version 8 and 10. >> Here is my feedback on version 10. Nothing major. I propose to start >> the IETF LC as soon a new version is posted >> >> - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP >> stands for Large-scale Measurement of Broadband Performance. >> Here, in the abstract, it stands for large-scale measurement >> platforms. Please change it. >> > > done > > >> - Some repetitions in section 1 >> It is expected >> that such a system could easily comprise 100,000 devices. >> >> It is expected that a Measurement >> System could easily encompass a few hundred thousand or even >> millions of Measurement Agents. > > agree, rephrased as: > > There is a desire to be able to coordinate the execution of > broadband > measurements and the collection of measurement results across a > large > scale set of Measurement Agents (MAs). These MAs could be > software based > agents on PCs, embedded agents in consumer devices (such as TVs or > gaming consoles), embedded in service provider controlled > devices such as set-top > boxes and home gateways, or simply dedicated probes. > MAs may also be embedded on a device that is part of an ISP's > network, such > as a DSLAM (Digital Subscriber Line Access Multiplexer), router, > Carrier > Grade NAT (Network Address Translator) or ISP Gateway. > It is expected that > a measurement system could easily encompass a few hundred > thousand or even > millions of such MAs. Such a scale > presents unique problems in coordination, execution and measurement > result collection. > >> - Section 2 >> OLD: >> Another possibility is for the >> MA may generate (or receive) traffic specially created for the >> purpose and measure some metric associated with its transfer. >> >> NEW: >> Another possibility is for the >> MA_to_generate (or receive) traffic specially created for the >> purpose and measure some metric associated with its transfer. > > ok > >> - Section 2 >> OLD: >> Messages are transferred over a secure Channel. >> >> NEW: >> Both control and report messages are transferred over a secure >> Channel. > > ok > > >> - >> results repository or Results repository? >> Please check all instances. >> > > it is Results repository because Results is an LMAP defined term while > the repository it is not (it is out of the scope of the framework) > The usage is consisten throughout the document. > > >> - Figure 1 >> The Report goes over the Report Channel, not Control Channel >> > ok > >> - Figure 1 >> The traffic between "End user or Measurement Peer" represents the MA >> passive monitoring. >> If you would add an arrow from the MA to End User or Measurement Peer >> on the right (to show that some MAs can generate active traffic), you >> would have a complete picture. >> Something like this: >> >> +-----------+ +-----------+ ^ >> |End user or| |End user or| | >> |Measurement| |Measurement| Non-LMAP >> | Peer | | Peer | Scope >> +-----------+ +-----------+ v >> ^ ^ ^ >> \ Observed +---------------+ / / ^ >> \.........|...............|........../ / | >> Traffic Flow | Measurement ..|.........../ | >> +----------->| Agent |Measurement Traffic | >> | +---------------+ | >> >> Note that I have reused your terminology: Measurement Traffic and >> Observed Traffic Flow >> > done > >> - Section 5.2.2 >> Instruction: -> >> [(Measurement Task configuration >> URI of Metric( >> [Input Parameter], >> (interface), >> (Cycle-ID))), >> (Report Channel), >> (Schedule), >> (Suppression information)] >> Should we expect a 1:1 mapping between the parameters above and the >> list that follows? >> For example, I see in the list >> * the Measurement Method role. For some Measurement Methods, >> different parties play different roles; for example (figure A3 >> in the Appendix) an iperf sender and receiver. Each Metric >> and >> its associated Measurement Method will describe all >> measurement >> roles involved in the process. >> >> * optionally, the measurement point designation >> [I-D.ietf-ippm-lmap-path >> ] >> of the MA and, if applicable, of the >> MP or other MA. This can be useful for reporting. > > Right. > I have include both the role and the measurment point in the figure. >> - Section 5.2.2 >> I guess that most MAs will have one Report Channel, as the default >> option. Right? >> OLD: >> o configuration of the Report Channels, each of which needs: >> >> NEW: >> o configuration of the Report Channel(s), each of which needs: > ok > >> - Section 5.2.3 >> >> OLD: >> the MA failed record the Measurement Results because it >> (unexpectedly) is out of spare memory >> >> NEW: >> the MA failed_to_record the Measurement Results because it >> (unexpectedly) is out of spare memory > ok > >> - Section 5.4.1 >> To match the charter: >> OLD: >> It may also be possible to transfer the information via the MA. >> >> NEW: >> If the subscriber's service parameters are available to the MAs, >> they could be reported >> with the Measurement Results in the Report Protocol. >> > ok > >> - section 6 Deployment considerations >> The Appendix has some examples of possible deployment >> arrangements of >> Measurement Agents and Peers. >> What does this text tell me? Should I read the appendix before >> proceeding? >> If yes (btw, I think this is the natural reading flow), why is this >> an appendix, and not in the core of the document? >> Note: this appendix contains some nice examples that really glue all >> the concepts into practical examples. >> > > ok, i have moved the examples to section 6 > >> - Appendix A >> OLD: >> Next, we consider Measurement Methods that measure user traffic. >> NEW: >> Next, we consider Measurement Methods that meter the Observed >> Traffic Flow. > ok > >> NEW figure A4 >> +--------+ +----------------+ +--------+ ^ >> |End user| | MA: Monitor | Observed |End user| | >> | or MP |<--|----------------|--Traffic ->| or MP | non-LMAP >> | | | | Flow | | Scope >> +--------+ | | +--------+ | >> ...|................|............................v.. >> | LMAP interface | ^ >> +----------------+ | >> ^ | | >> Instruction | | Report | >> | +-----------------+ | >> | | | >> | v LMAP >> +------------+ +------------+ Scope >> | Controller | | Collector | | >> +------------+ +------------+ v >> >> >> Figure A4: Schematic of LMAP-based Measurement System, >> with a Measurement Agent monitoring traffic >> > ok > >> - Security Considerations >> There is a privacy aspects for Observed Traffic Flow (typically the >> figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe >> some others). FYI. This has been addressed in IPFIX: see >> https://tools.ietf.org/html/rfc7011#section-11.8 >> > > ok, i added a reference to RFC7011 in section 8.3 > >> - Question: Have you discussed the ability for LMAP to use sampling >> for Observed Traffic Flows? Is this necessary? >> See http://datatracker.ietf.org/wg/psamp/documents/ >> > > The current framework doesnt go deep into the specifics of the > different measurement (just what is needed to understand the > framework), so i believe this probably is too specific for this > document. I dont really have a strong opinion. If you have an specific > text you would like to include in the document, feel free to suggest, > we will be happy to discuss it. > > Regards, marcelo > >> Regards, Benoit > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 23 00:32:34 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB91A0381 for ; Mon, 23 Feb 2015 00:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3h9GtVsvD7N for ; Mon, 23 Feb 2015 00:32:30 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A111A037E for ; Mon, 23 Feb 2015 00:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1424680350; x=1425889950; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xWn86z8T/p63MEcuP+qi57uBjQSGCYpxUNYTAhuh9Yw=; b=gjEOAQKlPxPXf/kPfjmLWMPreGhOqeq+YmGkTzaU8EK7S1MLL6u89hMc BGd20WNhKyA8yLH4/eaIdTa9Dl0xl+4t18821owhiPY8exE1eRPLuA3Dw IwtJVlzwO9WwKwwRwvRyyXkKmLruGR95ZITI3qVgxmVrZQLfbMo1P4za8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQDg5OpU/xbLJq1bg1haAYMHtk6JQoVuAoFjAQEBAQEBfIQQAQEEIwQLAQUvEQEQCxoCBRYLAgIJAwIBAgFFBgEJAwEHAQGIKw26YJd8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXKEbgeCaIFDAQSFYo1OhWWBGziCXYIuIYh2gz4ig289MQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.09,629,1418083200"; d="scan'208";a="358366259" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Feb 2015 08:32:28 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1N8WPVZ006695; Mon, 23 Feb 2015 08:32:26 GMT Message-ID: <54EAE599.5000407@cisco.com> Date: Mon, 23 Feb 2015 09:32:25 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "marcelo@it.uc3m.es >> marcelo bagnulo braun" , "lmap@ietf.org" References: <54E38787.2090009@cisco.com> <54E9B772.101@neomailbox.ch> In-Reply-To: <54E9B772.101@neomailbox.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Radia Perlman , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] AD review of draft-ietf-lmap-framework-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2015 08:32:32 -0000 Hi Marcelo, Thanks for the quick reaction, and for the new draft version. I'm progressing this document to IETF LC now. Regards, Benoit > Hi, > > Thanks for the review. I think we addressed all your points. We will > submit an updated version of the document now and if there are more > changes needed, we submit another one. > > El 17/02/15 a las 19:25, Benoit Claise escribió: >> Dear all, >> >> First of all, very sorry for the delay in getting back to you. >> Thank you for this new draft version. The document really improved >> between version 8 and 10. >> Here is my feedback on version 10. Nothing major. I propose to start >> the IETF LC as soon a new version is posted >> >> - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP >> stands for Large-scale Measurement of Broadband Performance. >> Here, in the abstract, it stands for large-scale measurement >> platforms. Please change it. >> > > done > > >> - Some repetitions in section 1 >> It is expected >> that such a system could easily comprise 100,000 devices. >> >> It is expected that a Measurement >> System could easily encompass a few hundred thousand or even >> millions of Measurement Agents. > > agree, rephrased as: > > There is a desire to be able to coordinate the execution of > broadband > measurements and the collection of measurement results across a > large > scale set of Measurement Agents (MAs). These MAs could be > software based > agents on PCs, embedded agents in consumer devices (such as TVs or > gaming consoles), embedded in service provider controlled > devices such as set-top > boxes and home gateways, or simply dedicated probes. > MAs may also be embedded on a device that is part of an ISP's > network, such > as a DSLAM (Digital Subscriber Line Access Multiplexer), router, > Carrier > Grade NAT (Network Address Translator) or ISP Gateway. > It is expected that > a measurement system could easily encompass a few hundred > thousand or even > millions of such MAs. Such a scale > presents unique problems in coordination, execution and measurement > result collection. > >> - Section 2 >> OLD: >> Another possibility is for the >> MA may generate (or receive) traffic specially created for the >> purpose and measure some metric associated with its transfer. >> >> NEW: >> Another possibility is for the >> MA_to_generate (or receive) traffic specially created for the >> purpose and measure some metric associated with its transfer. > > ok > >> - Section 2 >> OLD: >> Messages are transferred over a secure Channel. >> >> NEW: >> Both control and report messages are transferred over a secure >> Channel. > > ok > > >> - >> results repository or Results repository? >> Please check all instances. >> > > it is Results repository because Results is an LMAP defined term while > the repository it is not (it is out of the scope of the framework) > The usage is consisten throughout the document. > > >> - Figure 1 >> The Report goes over the Report Channel, not Control Channel >> > ok > >> - Figure 1 >> The traffic between "End user or Measurement Peer" represents the MA >> passive monitoring. >> If you would add an arrow from the MA to End User or Measurement Peer >> on the right (to show that some MAs can generate active traffic), you >> would have a complete picture. >> Something like this: >> >> +-----------+ +-----------+ ^ >> |End user or| |End user or| | >> |Measurement| |Measurement| Non-LMAP >> | Peer | | Peer | Scope >> +-----------+ +-----------+ v >> ^ ^ ^ >> \ Observed +---------------+ / / ^ >> \.........|...............|........../ / | >> Traffic Flow | Measurement ..|.........../ | >> +----------->| Agent |Measurement Traffic | >> | +---------------+ | >> >> Note that I have reused your terminology: Measurement Traffic and >> Observed Traffic Flow >> > done > >> - Section 5.2.2 >> Instruction: -> >> [(Measurement Task configuration >> URI of Metric( >> [Input Parameter], >> (interface), >> (Cycle-ID))), >> (Report Channel), >> (Schedule), >> (Suppression information)] >> Should we expect a 1:1 mapping between the parameters above and the >> list that follows? >> For example, I see in the list >> * the Measurement Method role. For some Measurement Methods, >> different parties play different roles; for example (figure A3 >> in the Appendix) an iperf sender and receiver. Each Metric >> and >> its associated Measurement Method will describe all >> measurement >> roles involved in the process. >> >> * optionally, the measurement point designation >> [I-D.ietf-ippm-lmap-path >> ] >> of the MA and, if applicable, of the >> MP or other MA. This can be useful for reporting. > > Right. > I have include both the role and the measurment point in the figure. >> - Section 5.2.2 >> I guess that most MAs will have one Report Channel, as the default >> option. Right? >> OLD: >> o configuration of the Report Channels, each of which needs: >> >> NEW: >> o configuration of the Report Channel(s), each of which needs: > ok > >> - Section 5.2.3 >> >> OLD: >> the MA failed record the Measurement Results because it >> (unexpectedly) is out of spare memory >> >> NEW: >> the MA failed_to_record the Measurement Results because it >> (unexpectedly) is out of spare memory > ok > >> - Section 5.4.1 >> To match the charter: >> OLD: >> It may also be possible to transfer the information via the MA. >> >> NEW: >> If the subscriber's service parameters are available to the MAs, >> they could be reported >> with the Measurement Results in the Report Protocol. >> > ok > >> - section 6 Deployment considerations >> The Appendix has some examples of possible deployment >> arrangements of >> Measurement Agents and Peers. >> What does this text tell me? Should I read the appendix before >> proceeding? >> If yes (btw, I think this is the natural reading flow), why is this >> an appendix, and not in the core of the document? >> Note: this appendix contains some nice examples that really glue all >> the concepts into practical examples. >> > > ok, i have moved the examples to section 6 > >> - Appendix A >> OLD: >> Next, we consider Measurement Methods that measure user traffic. >> NEW: >> Next, we consider Measurement Methods that meter the Observed >> Traffic Flow. > ok > >> NEW figure A4 >> +--------+ +----------------+ +--------+ ^ >> |End user| | MA: Monitor | Observed |End user| | >> | or MP |<--|----------------|--Traffic ->| or MP | non-LMAP >> | | | | Flow | | Scope >> +--------+ | | +--------+ | >> ...|................|............................v.. >> | LMAP interface | ^ >> +----------------+ | >> ^ | | >> Instruction | | Report | >> | +-----------------+ | >> | | | >> | v LMAP >> +------------+ +------------+ Scope >> | Controller | | Collector | | >> +------------+ +------------+ v >> >> >> Figure A4: Schematic of LMAP-based Measurement System, >> with a Measurement Agent monitoring traffic >> > ok > >> - Security Considerations >> There is a privacy aspects for Observed Traffic Flow (typically the >> figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe >> some others). FYI. This has been addressed in IPFIX: see >> https://tools.ietf.org/html/rfc7011#section-11.8 >> > > ok, i added a reference to RFC7011 in section 8.3 > >> - Question: Have you discussed the ability for LMAP to use sampling >> for Observed Traffic Flows? Is this necessary? >> See http://datatracker.ietf.org/wg/psamp/documents/ >> > > The current framework doesnt go deep into the specifics of the > different measurement (just what is needed to understand the > framework), so i believe this probably is too specific for this > document. I dont really have a strong opinion. If you have an specific > text you would like to include in the document, feel free to suggest, > we will be happy to discuss it. > > Regards, marcelo > >> Regards, Benoit > > . > From nobody Mon Feb 23 00:40:18 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F21A03FF; Mon, 23 Feb 2015 00:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogiNTQNzqfsF; Mon, 23 Feb 2015 00:40:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E851A038A; Mon, 23 Feb 2015 00:40:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223084015.4389.91231.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 00:40:15 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:40:17 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ From nobody Mon Feb 23 00:40:20 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-framework.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5555E1A038D; Mon, 23 Feb 2015 00:40:17 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F21A03FF; Mon, 23 Feb 2015 00:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogiNTQNzqfsF; Mon, 23 Feb 2015 00:40:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E851A038A; Mon, 23 Feb 2015 00:40:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223084015.4389.91231.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 00:40:15 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:40:17 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ From nobody Mon Feb 23 03:25:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4611A1A29 for ; Mon, 23 Feb 2015 03:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boF21uwL-ekE for ; Mon, 23 Feb 2015 03:25:43 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D701A1A27 for ; Mon, 23 Feb 2015 03:25:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAOEN61TGmAcV/2dsb2JhbABbgkMhIiIwWgSwMwEBAQEBAQYFkiUgAQmFcAKBI0MBAQEBAQF8hBEBAQMSCxBeARUVViYBBBsaiA0BDKpuhH+iRgEBCAEBAQEBGQSGB4lJLYI4DEEdgRQFj1KDXocAgxWCRIkBgz4ig25vAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,630,1418101200"; d="scan'208,217";a="105144135" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2015 06:25:43 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2015 06:25:42 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 23 Feb 2015 12:25:41 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 92 - call for agenda items Thread-Index: AdBPW3QAcBvSkQTaRlWN3pitu0dk+w== Date: Mon, 23 Feb 2015 11:25:40 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9A0918@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A0918AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF 92 - call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2015 11:25:46 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A0918AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda of IETF 92 was posted at https://datatracker.ietf.or= g/meeting/92/agenda.txt. Note that this agenda is preliminary and the time of the meetings are subje= ct to change. The LMAP WG session is scheduled for: WEDNESDAY, March 25, 2015 0900-1130 Morning Session I Parisian OPS lmap Large-Scale Measurement of Br= oadband Performance WG As we start building the agenda, please send your proposals about the struc= ture of the meeting, and the requests for presentation and discussion slots= . Based on the proposals that we shall receive the chairs will build and po= st the draft agenda in the next few days. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A0918AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The preliminary agenda of IETF 92 was posted at https://datatracker.ietf.org/meeting/92/agenda.txt.

 

Note that this agenda is preliminary and the time of= the meetings are subject to change.

 

The LMAP WG session is scheduled for:

 

WEDNESDAY, March 25, 2015

0900-1130  Morning Session I

Parisian      &n= bsp;        OPS     lmap =           Large-Scale Measurement o= f Broadband Performance WG

 

As we start building the agenda, please send your pr= oposals about the structure of the meeting, and the requests for presentati= on and discussion slots. Based on the proposals that we shall receive the c= hairs will build and post the draft agenda in the next few days.

 

Thanks and Regards,

 

Dan

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A0918AZFFEXMB04globa_-- From nobody Mon Feb 23 07:35:11 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096321A1B40; Mon, 23 Feb 2015 07:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEfCZ3abLLZ2; Mon, 23 Feb 2015 07:35:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1B51A1B05; Mon, 23 Feb 2015 07:35:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150223153506.10316.86367.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 07:35:06 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] Last Call: (A framework for Large-Scale Measurement of Broadband Performance (LMAP)) to Informational RFC X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:35:08 -0000 The IESG has received a request from the Large-Scale Measurement of Broadband Performance WG (lmap) to consider the following document: - 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 23 07:35:27 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727C01A1B6B; Mon, 23 Feb 2015 07:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awOiERLVwkE7; Mon, 23 Feb 2015 07:35:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351521A1B4B; Mon, 23 Feb 2015 07:35:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223153508.10316.50063.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 07:35:08 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:35:15 -0000 Last call has been made for draft-ietf-lmap-framework and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ From nobody Mon Feb 23 07:35:28 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-framework.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 912C11A1B6E; Mon, 23 Feb 2015 07:35:15 -0800 (PST) X-Original-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727C01A1B6B; Mon, 23 Feb 2015 07:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awOiERLVwkE7; Mon, 23 Feb 2015 07:35:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351521A1B4B; Mon, 23 Feb 2015 07:35:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223153508.10316.50063.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 07:35:08 -0800 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:35:15 -0000 Last call has been made for draft-ietf-lmap-framework and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ From nobody Tue Feb 24 03:43:44 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6CD1A0AF7 for ; Tue, 24 Feb 2015 03:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2RUo54HfMmy for ; Tue, 24 Feb 2015 03:43:40 -0800 (PST) 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 149241A03A9 for ; Tue, 24 Feb 2015 03:43:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB0D5ADF for ; Tue, 24 Feb 2015 12:43:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1Zez-H-YafdL for ; Tue, 24 Feb 2015 12:43:31 +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 for ; Tue, 24 Feb 2015 12:43:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F25AE20036 for ; Tue, 24 Feb 2015 12:43:37 +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 z_qyypopcPFj; Tue, 24 Feb 2015 12:43:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4273220031; Tue, 24 Feb 2015 12:43:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6749332369B4; Tue, 24 Feb 2015 12:43:36 +0100 (CET) Date: Tue, 24 Feb 2015 12:43:35 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150224114335.GA50356@elstar.local> Mail-Followup-To: lmap@ietf.org References: <20150212185304.GA16990@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212185304.GA16990@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [lmap] status codes aka condition codes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Feb 2015 11:43:43 -0000 On Thu, Feb 12, 2015 at 07:53:04PM +0100, Juergen Schoenwaelder wrote: > Hi, > > to achieve interoperability, I think we need to define concrete status > codes (aka condition codes), e.g. for runtime errors such as > "measurement task could not be started", "measurement task aborted > abnormally", etc. There are two options: > > a) We define a set of status codes as part of the information model. > + Different LMAP implementations that comply to the same > information model will use the same status codes. > - The downside is that we have to nail them down now. > > b) We define a set of status codes as part of the data models. > - Different protocols complying to the information model > will use different status codes. > + We can postpone the work needed to work out the essential > status codes. > > If we decide for option b), I like to request that note is added to > the information model that data models are expected to define a set of > well-known status codes (aka condition codes) and that they may be > encoded in something different than a string (that is the type used in > the data model is more acting like a placeholder). > I have thought a bit more about this. My understanding is that the information / data models talk about the status code returned by the task. I think this should be modeled as an int since this is how most operating systems deal with it. And it seems most systems interpret 0 as successful termination. There may be limitations for status codes outside the range 0..255. My further understanding is that runtime failures of the software component starting tasks etc. are handled via the logging mechanism. While looking it up, I found that ma-log-obj has a field ma-log-code of type 'code' - whatever that is. ;-) Summary: In the information model, I suggest to change ma-condition-code from string to int (perhaps adding text about the number range from above). In the YANG data model, we will then make a corresponding change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 25 05:09:08 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F641A0181 for ; Wed, 25 Feb 2015 05:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-FyRoHRcaW2 for ; Wed, 25 Feb 2015 05:09:05 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB8F1A0006 for ; Wed, 25 Feb 2015 05:09:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAE7I7VSHCzIm/2dsb2JhbABbgj8hIlJbA7A9AQEBAQEHkleFbgKBIkMBAQEBAQF8hBEBAQMSG14BDAkVVh8HAQQbARmIDQEMq3CEf6QXhgeGSQGCf4NPgRQFhCqLModMgxSDGYJGC4w5IoFRgh2CM38BAQE X-IronPort-AV: E=Sophos;i="5.09,644,1418101200"; d="scan'208,217";a="108456886" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Feb 2015 08:09:04 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 25 Feb 2015 08:09:04 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 25 Feb 2015 08:09:03 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: minutes of the virtual interim and other wg announcements Thread-Index: AdBQ/DlaNRNpq4ZGQemv/W7aVbs+Mw== Date: Wed, 25 Feb 2015 13:09:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9A30A5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A30A5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] minutes of the virtual interim and other wg announcements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2015 13:09:07 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A30A5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted the minutes of the 2/12/15 virtual interim at http://www.i= etf.org/proceedings/interim/2015/02/12/lmap/minutes/minutes-interim-2015-lm= ap-1. Thanks to Barbara Stark and Joan Luciani for the notes that made possible t= he minutes. Please read and let me know if I forgot or got wrong anything. Please pay attention to the action items! 11 days are left until the submis= sion deadline and we are expecting the revised I-Ds and protocol submission= s to show up until then. We are also expecting requests and proposals for the agenda for the meeting= at IETF 92. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A30A5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have submitted the minutes of the 2/12/15 virtual = interim at http://www.ietf.org/proceedings/interim/2015/02/12/lmap/minutes/minutes-int= erim-2015-lmap-1.

 

Thanks to Barbara Stark and Joan Luciani for the not= es that made possible the minutes.

 

Please read and let me know if I forgot or got wrong= anything.

 

Please pay attention to the action items! 11 days ar= e left until the submission deadline and we are expecting the revised I-Ds = and protocol submissions to show up until then.

 

We are also expecting requests and proposals for the= agenda for the meeting at IETF 92.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9A30A5AZFFEXMB04globa_--