From nobody Fri Aug 1 08:09:27 2014 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 8D54D1B27B3 for ; Fri, 1 Aug 2014 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 vAt-SIkkNvPM for ; Fri, 1 Aug 2014 08:09:18 -0700 (PDT) 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 DD5171A04B7 for ; Fri, 1 Aug 2014 08:09:17 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 1 Aug 2014 16:03:43 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.210]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 1 Aug 2014 16:08:39 +0100 From: To: , Date: Fri, 1 Aug 2014 16:08:37 +0100 Thread-Topic: Framework comments Thread-Index: Ac+tf3mLHmBJzbu5T7iuMNUFJoYjFQAB/IIg Message-ID: References: In-Reply-To: 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: http://mailarchive.ietf.org/arch/msg/lmap/srcOeKz53J9Y_WWX3K-eWm5ThRE Subject: [lmap] Framework comments 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: Fri, 01 Aug 2014 15:09:25 -0000 Matt, I wanted to follow up on a couple of comments you made at the mike during t= he Toronto meeting. They were both about avoiding sampling bias in results = analysis - in particular, if the test has errors or is suppressed, then you= think test results should be reported (as it's more likely that performanc= e is bad). I agree. I think the framework is ok, but it could make your po= int more clearly. =20 Assuming you were reading S5.4 Report protocol http://tools.ietf.org/html/d= raft-ietf-lmap-framework-07#section-5.4 - here's what it says:- << Optionally, a Report is not sent when there are no Measurement Results. In the initial LMAP Information Model and Report Protocol, for simplicity we assume that all Measurement Results are reported as-is, but allow extensibility so that a measurement system (or perhaps a second phase of LMAP) could allow a MA to: o label, or perhaps not include, Measurement Results impacted by, for instance, cross-traffic or the Measurement Peer (or other Measurement Agent) being busy o label Measurement Results obtained by a Measurement Task that overlapped with another o not report the Measurement Results if the MA believes that they are invalid o detail when Suppression started and ended >> I think this text is OK, but we could add a pointer to Section 6.1, somethi= ng like:- << As discussed in Section 6.1, data analysis of the results should careful= ly consider potential bias from any Measurement Results that are not report= ed, or from Measurement Results that are reported but may be invalid. >> S6.1 says: << An Instruction is likely to include several Measurement Tasks. Typically these run at different times, but it is also possible for them to run at the same time. Some Tasks may be compatible, in that they do not affect each other's Results, whilst with others great care would need to be taken. ...=20 The measurement system also needs to consider carefully how to interpret missing Results; for example, if the missing Results are ignored and the lack of a Report is caused by its broadband being broken, then the estimate of overall performance, averaged across all MAs, would be too optimistic. >> Do you think more needs to be added to this? maybe we should add: << The correction interpretation may depend on the specifics of the Measure= ment Task and Measurement Schedule.>> S5.6 about " Items beyond the scope of the initial LMAP work" says << 5. It does not define how to analyse Measurement Results, including how to interpret missing Results. >> The other section that may need discussion is S5.2.2.1: << The Suppression information may include any of the following optional fields: [list of bullets, including:] o a demand that the MA immediately ends on-going Measurement Task(s) that are tagged for suppression (and deletes the associated partial Measurement Result(s)). =09 (Side-note: normally suppression stops new Measurement Tasks from starting;= this is about Tasks that are stopped mid-test) I think the text is reasonable - for most Tasks partial Measurement Results= are basically meaningless. It's possible there are some Tasks where the pa= rtial results are useful, so perhaps we should change "and deletes the asso= ciated partial Measurement Result(s)" to "and most likely deletes the assoc= iated partial Measurement Result(s)" If you have other review comments, they would be great - but please send th= em as soon as possible (I'll be working on an update early next week - Dan = mentioned a deadline fo 31st July for comments.) Thanks, Best wishes phil From nobody Fri Aug 1 08:53:08 2014 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 21C661B2793 for ; Fri, 1 Aug 2014 08:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jig0-hOUgwaL for ; Fri, 1 Aug 2014 08:53:05 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17AB1B2791 for ; Fri, 1 Aug 2014 08:53:04 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s71Fqwke023235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 10:52:59 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 940EF1E006C; Fri, 1 Aug 2014 09:52:53 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 6479D1E0035; Fri, 1 Aug 2014 09:52:53 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s71FqqAn022474; Fri, 1 Aug 2014 10:52:52 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s71Fqqjd022441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 10:52:52 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 10:52:51 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "'matt.mathis@gmail.com'" , "'lmap@ietf.org'" Thread-Topic: Framework comments Thread-Index: Ac+tf3mLHmBJzbu5T7iuMNUFJoYjFQAB/IIgAAYpOyA= Date: Fri, 1 Aug 2014 15:52:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/JYdTFPpj-X8mQhvGfGVVtO9qIdg Subject: Re: [lmap] Framework comments 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: Fri, 01 Aug 2014 15:53:07 -0000 I'll be sending out my comments by next Friday. I'm traveling and in meetings all this week so unfortunately I couldn't add= ress them this week. Thanks, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, August 01, 2014 10:09 AM To: matt.mathis@gmail.com; lmap@ietf.org Subject: [lmap] Framework comments Matt, I wanted to follow up on a couple of comments you made at the mike during t= he Toronto meeting. They were both about avoiding sampling bias in results = analysis - in particular, if the test has errors or is suppressed, then you= think test results should be reported (as it's more likely that performanc= e is bad). I agree. I think the framework is ok, but it could make your po= int more clearly. =20 Assuming you were reading S5.4 Report protocol http://tools.ietf.org/html/d= raft-ietf-lmap-framework-07#section-5.4 - here's what it says:- << Optionally, a Report is not sent when there are no Measurement Results. In the initial LMAP Information Model and Report Protocol, for simplicity we assume that all Measurement Results are reported as-is, but allow extensibility so that a measurement system (or perhaps a second phase of LMAP) could allow a MA to: o label, or perhaps not include, Measurement Results impacted by, for instance, cross-traffic or the Measurement Peer (or other Measurement Agent) being busy o label Measurement Results obtained by a Measurement Task that overlapped with another o not report the Measurement Results if the MA believes that they are invalid o detail when Suppression started and ended >> I think this text is OK, but we could add a pointer to Section 6.1, somethi= ng like:- << As discussed in Section 6.1, data analysis of the results should careful= ly consider potential bias from any Measurement Results that are not report= ed, or from Measurement Results that are reported but may be invalid. >> S6.1 says: << An Instruction is likely to include several Measurement Tasks. Typically these run at different times, but it is also possible for them to run at the same time. Some Tasks may be compatible, in that they do not affect each other's Results, whilst with others great care would need to be taken. ...=20 The measurement system also needs to consider carefully how to interpret missing Results; for example, if the missing Results are ignored and the lack of a Report is caused by its broadband being broken, then the estimate of overall performance, averaged across all MAs, would be too optimistic. >> Do you think more needs to be added to this? maybe we should add: << The correction interpretation may depend on the specifics of the Measure= ment Task and Measurement Schedule.>> S5.6 about " Items beyond the scope of the initial LMAP work" says << 5. It does not define how to analyse Measurement Results, including how to interpret missing Results. >> The other section that may need discussion is S5.2.2.1: << The Suppression information may include any of the following optional fields: [list of bullets, including:] o a demand that the MA immediately ends on-going Measurement Task(s) that are tagged for suppression (and deletes the associated partial Measurement Result(s)). =09 (Side-note: normally suppression stops new Measurement Tasks from starting;= this is about Tasks that are stopped mid-test) I think the text is reasona= ble - for most Tasks partial Measurement Results are basically meaningless.= It's possible there are some Tasks where the partial results are useful, s= o perhaps we should change "and deletes the associated partial Measurement = Result(s)" to "and most likely deletes the associated partial Measurement R= esult(s)" If you have other review comments, they would be great - but please send th= em as soon as possible (I'll be working on an update early next week - Dan = mentioned a deadline fo 31st July for comments.) Thanks, Best wishes phil _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Aug 8 08:58:32 2014 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 A7E991B2B1B; Fri, 8 Aug 2014 08:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m0fd9dk2t2R; Fri, 8 Aug 2014 08:58:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE51B2BBF; Fri, 8 Aug 2014 08:58:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808155826.9584.36522.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 08:58:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NA-m0qiMnbZd1HPAg-lSkiF2huo Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-08.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, 08 Aug 2014 15:58:29 -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 platforms (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-08.txt Pages : 55 Date : 2014-08-08 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 platforms). 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-08 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 Fri Aug 8 09:35:39 2014 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 D61B91B2B1B for ; Fri, 8 Aug 2014 09:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 VoX_Rb6douIu for ; Fri, 8 Aug 2014 09:35:35 -0700 (PDT) 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 6168E1A0046 for ; Fri, 8 Aug 2014 09:35:34 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 17:35:33 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.210]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 8 Aug 2014 17:35:32 +0100 From: To: Date: Fri, 8 Aug 2014 17:35:27 +0100 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-framework-08.txt Thread-Index: Ac+zIaibtvH9xKGGSf+PxJz8jqq0TgAAOaHw Message-ID: References: <20140808155826.9584.36522.idtracker@ietfa.amsl.com> In-Reply-To: <20140808155826.9584.36522.idtracker@ietfa.amsl.com> 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: http://mailarchive.ietf.org/arch/msg/lmap/wfFbmGVFEsnhFEw4YgjIrxf8IOs Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-08.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: Fri, 08 Aug 2014 16:35:39 -0000 Hi, I just submitted an update of the framework document. This updates with the= clarifications requested in the recent WG last call and agreed during the = Toronto meeting. There aren't many changes compared with -07, you'll shortly be able to see = them via the Diff link at http://tools.ietf.org/html/draft-ietf-lmap-framew= ork (html version of -08 not yet appeared) I think there is only one technical change that wasn't discussed in Toronto= . This results from working with Mike Bugenhagen about his comments. So we'= ve added a couple of bits of text about "measurement point designations" (t= hese were already mentioned in S8.6.2 (Mitigations .. Anonymity) but not ea= rlier in the document) (background: they're discussed in http://tools.ietf.= org/html/draft-ietf-ippm-lmap-path-05 which is in IETF last call) In Instruction, add to Measurement Task configuration: * optionally, the measurement point designation [I-D.ietf-ippm-lmap-path] o= f the MA and, if applicable, of the MP or other MA. This can be useful for = reporting. In S5.4 add to the list of what the Report contains: * the measurement point designation of the MA and, if applicable, the MP or= other MA, if the information was included in the Instruction. This numberi= ng system is defined in [I-D.ietf-ippm-lmap-path] and allows a Measurement = Report to describe abstractly the path measured (for example, "from a MA at= a home gateway to a MA at a DSLAM"). Also, the MA can anonymise results by= including measurement point designations instead of IP addresses (Section = 8.6.2).=20 I add the couple of small clarifications, following up Matt M's comment - a= s mentioned in http://www.ietf.org/mail-archive/web/lmap/current/msg01739.h= tml =20 I've also worked through all the editorial comments - thanks. I think I acc= ounted for them all, except two: Ken said << This comment applies to all of the figures - leave the detail in the mes= sage structures to the Information Model.>> I didn't reduce the level of detail in the figures - think it's useful for = the high-level protocol model to illustrate. I added a note: << (If there is any difference between this document and the Information Model, the latter is definitive, since it is on the standards track.) >> Juergen said << Section 8.4.4 .. It is not clear why a detailed figure is needed here.>> We thought this it was worth keeping, as it's the high-level protocol model= picture (and RFC4101 encourages pictures) =20 Best wishes phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 08 August 2014 16:58 > To: i-d-announce@ietf.org > Cc: lmap@ietf.org > Subject: [lmap] I-D Action: draft-ietf-lmap-framework-08.txt >=20 >=20 > 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. >=20 > Title : A framework for large-scale measurement > platforms (LMAP) > Authors : Philip Eardley > Al Morton > Marcelo Bagnulo > Trevor Burbridge > Paul Aitken > Aamer Akhter > Filename : draft-ietf-lmap-framework-08.txt > Pages : 55 > Date : 2014-08-08 >=20 > 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 platforms). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-framework-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sat Aug 9 10:09:14 2014 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 4E90B1A004E for ; Sat, 9 Aug 2014 10:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 d4W7ssownipB for ; Sat, 9 Aug 2014 10:09:08 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAB11A0047 for ; Sat, 9 Aug 2014 10:09:07 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 6AA33E43A89A1 for ; Sat, 9 Aug 2014 17:09:03 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s79H96sc018777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Aug 2014 13:09:06 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.12]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sat, 9 Aug 2014 13:09:06 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: LMAP Information Model: Calendar Schedule elements evaluation Thread-Index: Ac+z9J+fjYLlLMBaShyZL8WRSVq28g== Date: Sat, 9 Aug 2014 17:09:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734F5D171@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734F5D171US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/TpCcsIhwbwLBa6qTrs3JAyb-8kA Subject: [lmap] LMAP Information Model: Calendar Schedule elements evaluation 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: Sat, 09 Aug 2014 17:09:10 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734F5D171US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, I am in the process of taking the LMAP Information Model in draft-01 and de= veloping the corresponding TR-069 data model. As I was going through the information model - I had a question on how the = Calendar schedule elements are evaluated - especially when the lists are em= pty (we did define the behavior for days). // Timing specialisation to run repeated Tasks at specific times and/or day= s object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-days-of-week<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; BTW a data type for days is not defined in the draft - I didn't know if it = was a string of the day (full or short) or an integer - if so does it start= at 0 or 1. We should be explicit to the domain values as we would want the same interp= retation for the various data models that would use these data type.s BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7734F5D171US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

I am in the process= of taking the LMAP Information Model in draft-01 and developing the corres= ponding TR-069 data model.

 

As I was going thro= ugh the information model – I had a question on how the Calendar sche= dule elements are evaluated – especially when the lists are empty (we= did define the behavior for days).

 

// Timing specialisation to run repeated Tasks at specific times= and/or days

object {

[datetime ma-calendar-start;] // default: immediate

[datetime ma-calendar-end;] // default: indefinite

[int ma-calendar-months&l= t;0..*>;] // default: 1-12

[days ma-calendar-days-of= -week<0..*>;] // default: all

[int ma-calen= dar-hours<0..*>;] // default: 0-23

[int ma-calen= dar-minutes<0..*>;] // default: 0-59

[int ma-calen= dar-seconds<0..*>;] // default: 0-59

[int ma-calen= dar-timezone-offset;]

// default: system timezo= ne offset

} ma-calendar-obj;<= o:p>

 

BTW a data type for= days is not defined in the draft – I didn’t know if it was a s= tring of the day (full or short) or an integer – if so does it start = at 0 or 1.

 

We should be explic= it to the domain values as we would want the same interpretation for the va= rious data models that would use these data type.s

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F7734F5D171US70UWXCHMBA05z_-- From nobody Sun Aug 10 06:32:56 2014 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 260C21A0717 for ; Sun, 10 Aug 2014 06:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 iBRWydKZeZbU for ; Sun, 10 Aug 2014 06:32:52 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FA81A0713 for ; Sun, 10 Aug 2014 06:32:51 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 7F9F7B2C43760 for ; Sun, 10 Aug 2014 13:32:48 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s7ADWnLq030020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 10 Aug 2014 09:32:50 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.12]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sun, 10 Aug 2014 09:32:50 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: LMAP Information Model: Comments Thread-Index: Ac+0n5O207YKVP3uQhqqotbVTPyckA== Date: Sun, 10 Aug 2014 13:32:49 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734F5D2CF@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734F5D2CFUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fi7WnEVOpNMZQf3bnY80DRJqKMk Subject: [lmap] LMAP Information Model: Comments 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, 10 Aug 2014 13:32:55 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734F5D2CFUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, As I was going through the IM to develop the TR-069 data model I noticed a = couple of items that might need clarifications and maybe some consideration= . 1) Item 1 // Channel object with name string allowing reference from Schedule. Contai= ns channel endpoint target URL and security // credentials to establish secure channel. Optionally allows interface spe= cification (by interface name string reference) // and connection when no data is pending for transfer object { string ma-channel-name; url ma-channel-target; credentials ma-channel-credentials; [string ma-channel-interface-name;] } ma-channel-obj; We should define the datatype for credentials - I think you mention it in t= he text but for a data model - I really needed to know what it constituted. 2) Item 2 // Task Configuration object with string name to allow reference from Sched= ule. Contains URI to link to registry or local // specification of Task. Options allow the configuration of Task parameter= s (in the form of name-value pairs) object { string ma-task-name; uri ma-task-registry; name-value-pair ma-task-options<0..*>; [boolean ma-task-suppress-by-default;] // default: TRUE [string ma-task-cycle-id;] } ma-task-obj; For the "names" in many of these objects it seems we want to make these uni= que keys within the context of the MA. This may be a problem from the contr= oller perspective. The controller would have to know which "names" are used= for what MA. - Much easier to make these names UUIDs and call it a day. - = You can still have a label if you like - but identifiers should be unique i= n the context of the controller. As to the name-value pair - I think we just need a small comment that this = type implementation specific (JSON, XML, TR-069) will all have different fo= rmats for name value pairs. 3) Item 3 // MA Configuration object { uuid ma-agent-id; [ma-task-obj ma-control-tasks<0..*>;] ma-channel-obj ma-control-channels<1..*>; [mas-schedule-obj ma-control-schedules<0..*>]; [urn ma-device-id;] Just a typo mas instead of ma 4) Item 4 // Report tasks result rows object { datetime ma-report-result-time; string ma-report-conflicting-tasks<0..*>; [int ma-report-result-cross-traffic;] // Bytes of non-measurement traffic // on measurement interface during measurement period data ma-report-result-values<0..*>; } ma-result-row-obj; Same comment as name-value pairs - implementation specific 5) Item 5 // Selected Task interfaces (filtered by Integer list) can be output to oth= er Task Configurations // (referenced by name string) or connected to input/output Channels (refer= enced by name string) object { [int ma-schedule-task-filters<0..*>;] // default: all [string ma-schedule-task-output-task-names<0..*>]; [string ma-schedule-task-channel-names<0..*>]; } ma-sched-dataset-obj; This is the biggest problem that I found: After your explaination these int= egers represent an index into the a documented output of a registry item (m= easurement or local) for the scheduled task. - This sounds very "brittle" -= Especially if I change the registry item... Why don't we just give these outputs a URI? Just a thought. Maybe its too h= eavy. BTW - I did find a couple of spelling and other editorial comments (e.g., o= uput) - I just forgot to note them. I will make a point of getting those on= my next review of draft-02. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7734F5D2CFUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

As I was going through the IM to develop the TR-069= data model I noticed a couple of items that might need clarifications and = maybe some consideration.

 

1)    Item 1

// = Channel object with name string allowing reference from Schedule. Contains = channel endpoint target URL and security

// = credentials to establish secure channel. Optionally allows interface specif= ication (by interface name string reference)

// = and connection when no data is pending for transfer

obj= ect {

str= ing ma-channel-name;

url= ma-channel-target;

credentials[st= ring ma-channel-interface-name;]

} ma-channel-obj;

 

We should define the datatype for credentials ̵= 1; I think you mention it in the text but for a data model – I really= needed to know what it constituted.

 

2)    Item 2

 

// = Task Configuration object with string name to allow reference from Schedule= . Contains URI to link to registry or local

// = specification of Task. Options allow the configuration of Task parameters (= in the form of name-value pairs)

obj= ect {

string ma-task-name;

uri= ma-task-registry;

name-value-pair ma-task-options<0..*>;

[bo= olean ma-task-suppress-by-default;] // default: TRUE<= /p>

[st= ring ma-task-cycle-id;]

} ma-task-obj;<= /b>

 

For the “names” in many of these object= s it seems we want to make these unique keys within the context of the MA. = This may be a problem from the controller perspective. The controller would have to know which “names” are used for what MA. –= Much easier to make these names UUIDs and call it a day. – You can s= till have a label if you like – but identifiers should be unique in t= he context of the controller.

 

As to the name-value pair – I think we just n= eed a small comment that this type implementation specific (JSON, XML, TR-0= 69) will all have different formats for name value pairs.=

 

3)    Item 3

 

// MA Configuration

object {

uuid ma-agent-id;

[ma-task-obj ma-control-tasks<0..*>;]<= /p>

ma-channel-obj ma-control-channels<1..*>;<= /b>

[mas-schedule-obj ma-control-schedules<0..*>];

[ur= n ma-device-id;]

 

Just a typo mas instead of ma

 

4)    Item 4

 

// = Report tasks result rows

obj= ect {

dat= etime ma-report-result-time;

str= ing ma-report-conflicting-tasks<0..*>;

[in= t ma-report-result-cross-traffic;] // Bytes of non-measurement traffic=

// = on measurement interface during measurement period

data ma-r= eport-result-values<0..*>;

} ma-result-row-obj;

 

Same comment as name-value pairs – implementa= tion specific

 

5)    Item 5

 

// = Selected Task interfaces (filtered by Integer list) can be output to other = Task Configurations

// = (referenced by name string) or connected to input/output Channels (referenc= ed by name string)

obj= ect {

[int ma-schedule-task-f= ilters<0..*>;] // default: all

[st= ring ma-schedule-task-output-task-names<0..*>];=

[st= ring ma-schedule-task-channel-names<0..*>];

} ma-sched-dataset-obj;

 

This is the biggest problem that I found: After you= r explaination these integers represent an index into the a documented outp= ut of a registry item (measurement or local) for the scheduled task. – This sounds very “brittle” – Especially if= I change the registry item…

Why don’t we just give these outputs a URI? J= ust a thought. Maybe its too heavy.

 

BTW – I did find a couple of spelling and oth= er editorial comments (e.g., ouput) – I just forgot to note them. I w= ill make a point of getting those on my next review of draft-02.=

 

BR,

Tim

 

--_000_9966516C6EB5FC4381E05BF80AA55F7734F5D2CFUS70UWXCHMBA05z_-- From nobody Mon Aug 11 01:31:33 2014 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 441121A037C for ; Mon, 11 Aug 2014 01:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 5U9BRKmepNfm for ; Mon, 11 Aug 2014 01:31:29 -0700 (PDT) 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 307F41A037A for ; Mon, 11 Aug 2014 01:31:28 -0700 (PDT) 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; Mon, 11 Aug 2014 09:31:30 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.42]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 11 Aug 2014 09:30:59 +0100 From: To: , Date: Mon, 11 Aug 2014 09:30:58 +0100 Thread-Topic: LMAP Information Model: Calendar Schedule elements evaluation Thread-Index: Ac+z9J+fjYLlLMBaShyZL8WRSVq28gBSF7ZA Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7734F5D171@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734F5D171@US70UWXCHMBA05.zam.alcatel-lucent.com> 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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72E0882B05AEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BMKeiJkTI8eQ5pRb3M3ceUefxbM Subject: Re: [lmap] LMAP Information Model: Calendar Schedule elements evaluation 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, 11 Aug 2014 08:31:32 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72E0882B05AEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point about the format of days. Does anyone have a strong preference? = E.g.: 1) Mon, Tue, Wed 2) 1..7 with 1 being Monday, Sunday? Personally I'd favour Strings to avoid the ambiguity of the starting day-of= -week. Not sure what the question is regarding some of the list being empty. Hopef= ully an example will answer it. "ma-timing-calendar": { "ma-calendar-minutes": ["00"], "ma-calendar-seconds": ["00"] } This is an example from the current draft. Since months, days, days-of-week= and hours are all not defined, they all default to "all" - i.e. the action= will be performed at 00m:00s of each and every hour regardless of the day = of week, day of month or month of year. I have just realised days (as in days of month) has got lost somewhere alon= g the way, so I'll add that back in. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 09 August 2014 18:09 To: lmap@ietf.org Subject: [lmap] LMAP Information Model: Calendar Schedule elements evaluati= on Team, I am in the process of taking the LMAP Information Model in draft-01 and de= veloping the corresponding TR-069 data model. As I was going through the information model - I had a question on how the = Calendar schedule elements are evaluated - especially when the lists are em= pty (we did define the behavior for days). // Timing specialisation to run repeated Tasks at specific times and/or day= s object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-days-of-week<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; BTW a data type for days is not defined in the draft - I didn't know if it = was a string of the day (full or short) or an integer - if so does it start= at 0 or 1. We should be explicit to the domain values as we would want the same interp= retation for the various data models that would use these data type.s BR, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72E0882B05AEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good point about the format of days. Does anyone have a stron= g preference? E.g.:

 

1)   &nbs= p;  Mon, = Tue, Wed

2)      <= /span>1..7 with 1 being Mond= ay, Sunday?

 

Personally I’d favour Strings to avoid the ambiguity of = the starting day-of-week.

 

Not sure what the question is regarding some of = the list being empty. Hopefully an example will answer it.

 

"ma-timing-calendar": {

        &n= bsp;   "ma-calendar-minutes": ["00"],

       &= nbsp;    "ma-calendar-seconds": ["00"]

      &= nbsp;   }

 

This is an example from the current draft. Since mon= ths, days, days-of-week and hours are all not defined, they all default to = “all” – i.e. the action will be performed at 00m:00s of e= ach and every hour regardless of the day of week, day of month or month of = year.

 

I have just realised days (as in days of month) has got lost somewhe= re along the way, so I’ll add that back in.

 

=

Trevor.

 

From:= lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timoth= y (Timothy)
Sent: 09 August 2014 18:09
To: lmap@ietf.or= g
Subject: [lmap] LMAP Information Model: Calendar Schedule eleme= nts evaluation

&= nbsp;

Team,

 

= I am in the process of taking= the LMAP Information Model in draft-01 and developing the corresponding TR= -069 data model.

 

As I was going through th= e information model – I had a question on how the Calendar schedule e= lements are evaluated – especially when the lists are empty (we did d= efine the behavior for days).

 

// Timing specialisation to run repeated Tasks at specifi= c times and/or days

object {

[datetime ma-calendar-start;] // de= fault: immediate

[datetime ma-ca= lendar-end;] // default: indefinite

[int ma-calendar-months<0..*&= gt;;] // default: 1-12

[days ma-calendar-days-of-week<0..*>;] = // default: all

[int ma-calendar-hours<0..*>;] // default: 0-23

[int ma-calendar-minutes<0..*>;] // default: 0-59

[int ma-cale= ndar-seconds<0..*>;] // default: 0-59

[int ma-calendar-timezone= -offset;]

// default: system timezone offset

} ma-calendar-obj;

=  

BTW a data type for days is not defined in the draft = – I didn’t know if it was a string of the day (full or short) o= r an integer – if so does it start at 0 or 1.

 = ;

We should be explicit to the domain values as we would want the s= ame interpretation for the various data models that would use these data ty= pe.s

 

BR,

Tim

= --_000_ED51D9282D1D3942B9438CA8F3372EB72E0882B05AEMV64UKRDdoma_-- From nobody Mon Aug 11 05:50:05 2014 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 CCF2D1A0296 for ; Mon, 11 Aug 2014 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 tvC5eqFj8i15 for ; Mon, 11 Aug 2014 05:49:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512951A0176 for ; Mon, 11 Aug 2014 05:49:58 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 17992CF801409; Mon, 11 Aug 2014 12:49:56 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s7BCnvjd024824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 08:49:57 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.12]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 11 Aug 2014 08:49:57 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model: Calendar Schedule elements evaluation Thread-Index: Ac+z9J+fjYLlLMBaShyZL8WRSVq28gBSF7ZAAAjjN7A= Date: Mon, 11 Aug 2014 12:49:55 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734F5DE6A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734F5D171@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734F5DE6AUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hyIoquF6jXnRStuPCR-jHvc2Rnk Subject: Re: [lmap] LMAP Information Model: Calendar Schedule elements evaluation 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, 11 Aug 2014 12:50:02 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734F5DE6AUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Monday, August 11, 2014 3:31 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model: Calendar Schedule elements evaluation Good point about the format of days. Does anyone have a strong preference? = E.g.: 1) Mon, Tue, Wed 2) 1..7 with 1 being Monday, Sunday? Personally I'd favour Strings to avoid the ambiguity of the starting day-of= -week. I would prefer short code abbreviations for days as strings as well. = ( "Mon", "Tue", "Wed" "Thu" "Fri" "Sat" "Sun") Not sure what the question is regarding some of the list being empty. Hopef= ully an example will answer it. "ma-timing-calendar": { "ma-calendar-minutes": ["00"], "ma-calendar-seconds": ["00"] } This is an example from the current draft. Since months, days, days-of-week= and hours are all not defined, they all default to "all" - i.e. the action= will be performed at 00m:00s of each and every hour regardless of the day = of week, day of month or month of year. Yes that answers the question. Empty list (not defined) means all val= ues in the domain are used. I have just realised days (as in days of month) has got lost somewhere alon= g the way, so I'll add that back in. Ok I will as well. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 09 August 2014 18:09 To: lmap@ietf.org Subject: [lmap] LMAP Information Model: Calendar Schedule elements evaluati= on Team, I am in the process of taking the LMAP Information Model in draft-01 and de= veloping the corresponding TR-069 data model. As I was going through the information model - I had a question on how the = Calendar schedule elements are evaluated - especially when the lists are em= pty (we did define the behavior for days). // Timing specialisation to run repeated Tasks at specific times and/or day= s object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-days-of-week<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; BTW a data type for days is not defined in the draft - I didn't know if it = was a string of the day (full or short) or an integer - if so does it start= at 0 or 1. We should be explicit to the domain values as we would want the same interp= retation for the various data models that would use these data type.s BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7734F5DE6AUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Monday, August 11, 2014 3:31 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: LMAP Information Model: Calendar Schedule elements eval= uation

 

Good po= int about the format of days. Does anyone have a strong preference? E.g.:

&n= bsp;

1)      Mon, Tue, Wed

2)      1..7 with 1 being Monday, Sunday?

&n= bsp;

Persona= lly I’d favour Strings to avoid the ambiguity of the starting day-of-= week.

<TAC> I would pr= efer short code abbreviations for days as strings as well. ( “MonR= 21;, “Tue”, “Wed” “Thu” “Fri̶= 1; “Sat” “Sun”)

&n= bsp;

Not sur= e what the question is regarding some of the list being empty. Hopefully an= example will answer it.

&n= bsp;

"ma-timing-calendar"= : {

     =        "ma-calendar-minutes": [&quo= t;00"],

     =        "ma-calendar-seconds": [&quo= t;00"]

     =      }

&n= bsp;

This is= an example from the current draft. Since months, days, days-of-week and ho= urs are all not defined, they all default to “all” – i.e.= the action will be performed at 00m:00s of each and every hour regardless of the day of week, day of month or month of year.

<TAC> Yes that a= nswers the question. Empty list (not defined) means all values in the domai= n are used.

&n= bsp;

I have = just realised days (as in days of month) has got lost somewhere along the w= ay, so I’ll add that back in.

<TAC> Ok I will = as well.

&n= bsp;

Trevor.=

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 August 2014 18:09
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model: Calendar Schedule elements e= valuation

 

Team,

 

I am in the process= of taking the LMAP Information Model in draft-01 and developing the corres= ponding TR-069 data model.

 

As I was going thro= ugh the information model – I had a question on how the Calendar sche= dule elements are evaluated – especially when the lists are empty (we= did define the behavior for days).

 

// Timing specialisation to run repeated Tasks at specific times= and/or days

object {

[datetime ma-calendar-start;] // default: immediate

[datetime ma-calendar-end;] // default: indefinite

[int ma-calendar-months&l= t;0..*>;] // default: 1-12

[days ma-calendar-days-of= -week<0..*>;] // default: all

[int ma-calen= dar-hours<0..*>;] // default: 0-23

[int ma-calen= dar-minutes<0..*>;] // default: 0-59

[int ma-calen= dar-seconds<0..*>;] // default: 0-59

[int ma-calen= dar-timezone-offset;]

// default: system timezo= ne offset

} ma-calendar-obj;<= o:p>

 

BTW a data type for= days is not defined in the draft – I didn’t know if it was a s= tring of the day (full or short) or an integer – if so does it start = at 0 or 1.

 

We should be explic= it to the domain values as we would want the same interpretation for the va= rious data models that would use these data type.s

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F7734F5DE6AUS70UWXCHMBA05z_-- From nobody Mon Aug 11 09:33:14 2014 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 0E53C1A05C0 for ; Mon, 11 Aug 2014 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 ugLFzwoQcV2A for ; Mon, 11 Aug 2014 09:33:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65241A0584 for ; Mon, 11 Aug 2014 09:33:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3903EABB; Mon, 11 Aug 2014 18:33:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id btkEGYDUc1kk; Mon, 11 Aug 2014 18:33:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Aug 2014 18:33:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCAAF20037; Mon, 11 Aug 2014 18:33:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ELjPChzykDp6; Mon, 11 Aug 2014 18:33:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E9FE20039; Mon, 11 Aug 2014 18:33:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 883232E05DC4; Mon, 11 Aug 2014 18:33:05 +0200 (CEST) Date: Mon, 11 Aug 2014 18:33:05 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140811163304.GA90095@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734F5D2CF@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734F5D2CF@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/B2fMra0pytTjleix7PUnxYNSyWc Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model: Comments 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, 11 Aug 2014 16:33:14 -0000 On Sun, Aug 10, 2014 at 01:32:49PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, > > As I was going through the IM to develop the TR-069 data model I noticed a couple of items that might need clarifications and maybe some consideration. > > > 1) Item 1 > // Channel object with name string allowing reference from Schedule. Contains channel endpoint target URL and security > // credentials to establish secure channel. Optionally allows interface specification (by interface name string reference) > // and connection when no data is pending for transfer > object { > string ma-channel-name; > url ma-channel-target; > credentials ma-channel-credentials; > [string ma-channel-interface-name;] > } ma-channel-obj; > > We should define the datatype for credentials - I think you mention it in the text but for a data model - I really needed to know what it constituted. But the credentials you need depend on the security features of the protocol you use. I do not think we can be more precise in the information model without contraining the protocol choice. > 2) Item 2 > > // Task Configuration object with string name to allow reference from Schedule. Contains URI to link to registry or local > // specification of Task. Options allow the configuration of Task parameters (in the form of name-value pairs) > object { > string ma-task-name; > uri ma-task-registry; > name-value-pair ma-task-options<0..*>; > [boolean ma-task-suppress-by-default;] // default: TRUE > [string ma-task-cycle-id;] > } ma-task-obj; > > For the "names" in many of these objects it seems we want to make these unique keys within the context of the MA. This may be a problem from the controller perspective. The controller would have to know which "names" are used for what MA. - Much easier to make these names UUIDs and call it a day. - You can still have a label if you like - but identifiers should be unique in the context of the controller. > I am not sure using UUIDs is a good choice for names yet. Several deployed systems seem to use names scoped by the local system and in fact that same name for the same thing over multiple MAs. I do not see why the names benefit from being globally unique. The MA has a unique identifier and hence uniqueness can always be achieved when needed. > As to the name-value pair - I think we just need a small comment > that this type implementation specific (JSON, XML, TR-069) will all > have different formats for name value pairs. Not sure why this would be needed. Again, an information model is conceptual anyway. > Same comment as name-value pairs - implementation specific If at all, this is data model specific not implementation specific. And yes, everything in the information model needs to become concrete in the data model. So I think such disclaimers are not needed. > 5) Item 5 > > // Selected Task interfaces (filtered by Integer list) can be output to other Task Configurations > // (referenced by name string) or connected to input/output Channels (referenced by name string) > object { > [int ma-schedule-task-filters<0..*>;] // default: all > [string ma-schedule-task-output-task-names<0..*>]; > [string ma-schedule-task-channel-names<0..*>]; > } ma-sched-dataset-obj; > > This is the biggest problem that I found: After your explaination these integers represent an index into the a documented output of a registry item (measurement or local) for the scheduled task. - This sounds very "brittle" - Especially if I change the registry item... > Why don't we just give these outputs a URI? Just a thought. Maybe its too heavy. I agree that this may need improvement. > BTW - I did find a couple of spelling and other editorial comments > (e.g., ouput) - I just forgot to note them. I will make a point of > getting those on my next review of draft-02. OK. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Aug 11 11:39:42 2014 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 05AE71A0769 for ; Mon, 11 Aug 2014 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.668] 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 sBw9Wxc3Ttgu for ; Mon, 11 Aug 2014 11:39:39 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE851A075B for ; Mon, 11 Aug 2014 11:39:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 935723AB536C1; Mon, 11 Aug 2014 18:39:34 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7BIdZuM026470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 14:39:37 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.12]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 11 Aug 2014 14:39:36 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Information Model: Comments Thread-Index: Ac+0n5O207YKVP3uQhqqotbVTPyckABA+ByAAASfSGA= Date: Mon, 11 Aug 2014 18:39:35 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734F5E2DB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734F5D2CF@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140811163304.GA90095@elstar.local> In-Reply-To: <20140811163304.GA90095@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/u5X-pWzL9CImn1Xy7W2B07Ae1Ys Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model: Comments 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, 11 Aug 2014 18:39:42 -0000 Juergen, Comments inline. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, August 11, 2014 11:33 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Information Model: Comments On Sun, Aug 10, 2014 at 01:32:49PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > As I was going through the IM to develop the TR-069 data model I noticed = a couple of items that might need clarifications and maybe some considerati= on. >=20 >=20 > 1) Item 1 > // Channel object with name string allowing reference from Schedule.=20 > Contains channel endpoint target URL and security // credentials to=20 > establish secure channel. Optionally allows interface specification=20 > (by interface name string reference) // and connection when no data is=20 > pending for transfer object { string ma-channel-name; url=20 > ma-channel-target; credentials ma-channel-credentials; [string=20 > ma-channel-interface-name;] } ma-channel-obj; >=20 > We should define the datatype for credentials - I think you mention it in= the text but for a data model - I really needed to know what it constitute= d. But the credentials you need depend on the security features of the protoco= l you use. I do not think we can be more precise in the information model w= ithout contraining the protocol choice. So we should say the credentials will be dependent on the protocol se= lected and leave it at that. It's the item 4 discussion. =20 > 2) Item 2 >=20 > // Task Configuration object with string name to allow reference from=20 > Schedule. Contains URI to link to registry or local // specification=20 > of Task. Options allow the configuration of Task parameters (in the=20 > form of name-value pairs) object { string ma-task-name; uri=20 > ma-task-registry; name-value-pair ma-task-options<0..*>; [boolean=20 > ma-task-suppress-by-default;] // default: TRUE [string=20 > ma-task-cycle-id;] } ma-task-obj; >=20 > For the "names" in many of these objects it seems we want to make these u= nique keys within the context of the MA. This may be a problem from the con= troller perspective. The controller would have to know which "names" are us= ed for what MA. - Much easier to make these names UUIDs and call it a day. = - You can still have a label if you like - but identifiers should be unique= in the context of the controller. >=20 I am not sure using UUIDs is a good choice for names yet. Several deployed = systems seem to use names scoped by the local system and in fact that same = name for the same thing over multiple MAs. I do not see why the names benef= it from being globally unique. The MA has a unique identifier and hence uni= queness can always be achieved when needed. Well then we should say that the MA+Name is what makes it unique. My = point was that a controller will need to figure out how to make a the objec= t instance unique. If our expectation is that the name will be unique for t= hat object type in the context of an MA, then lets state that expectation. = That way a controller can figure out how it would like to define the names.= It also helps people when they develop a data model (e.g., TR-069). Now I = know I can put a uniqueKey constraint on all the Name parameters; before yo= ur statement I was hesitant given the examples. > As to the name-value pair - I think we just need a small comment that=20 > this type implementation specific (JSON, XML, TR-069) will all have=20 > different formats for name value pairs. Not sure why this would be needed. Again, an information model is conceptua= l anyway. =20 > Same comment as name-value pairs - implementation specific If at all, this is data model specific not implementation specific. And yes= , everything in the information model needs to become concrete in the data = model. So I think such disclaimers are not needed. Indeed you are correct - I was suggesting we provide language in the = IM that says when we expect the element to be implementation specific - to = state that. I'm not adamant; just concerned about a person picking this up = without the benefit of the last year of discussion and looking how to defin= e a credential, or name-value pair or whatever. I know I did a search on th= ese types just to be sure they were not defined and I missed something... =20 > 5) Item 5 >=20 > // Selected Task interfaces (filtered by Integer list) can be output=20 > to other Task Configurations // (referenced by name string) or=20 > connected to input/output Channels (referenced by name string) object=20 > { [int ma-schedule-task-filters<0..*>;] // default: all [string=20 > ma-schedule-task-output-task-names<0..*>]; > [string ma-schedule-task-channel-names<0..*>]; > } ma-sched-dataset-obj; >=20 > This is the biggest problem that I found: After your explaination these i= ntegers represent an index into the a documented output of a registry item = (measurement or local) for the scheduled task. - This sounds very "brittle"= - Especially if I change the registry item... > Why don't we just give these outputs a URI? Just a thought. Maybe its too= heavy. I agree that this may need improvement. > BTW - I did find a couple of spelling and other editorial comments=20 > (e.g., ouput) - I just forgot to note them. I will make a point of=20 > getting those on my next review of draft-02. OK. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Aug 11 12:38:15 2014 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 38DD91A008B for ; Mon, 11 Aug 2014 12:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.668] 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 ZZ0td2OPKGMU for ; Mon, 11 Aug 2014 12:38:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7F11A001B for ; Mon, 11 Aug 2014 12:38:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CABD08A3; Mon, 11 Aug 2014 21:38:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZTPCf5un6VSO; Mon, 11 Aug 2014 21:38:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Aug 2014 21:38:09 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 048EC20039; Mon, 11 Aug 2014 21:38:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mw2oO_YpOmG0; Mon, 11 Aug 2014 21:38:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BFC720038; Mon, 11 Aug 2014 21:38:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA8F32E06084; Mon, 11 Aug 2014 21:38:05 +0200 (CEST) Date: Mon, 11 Aug 2014 21:38:05 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140811193805.GA90410@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734F5D2CF@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140811163304.GA90095@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734F5E2DB@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734F5E2DB@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/q_lW_ysN_apdglE33t6xW8i49vI Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model: Comments 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, 11 Aug 2014 19:38:13 -0000 On Mon, Aug 11, 2014 at 06:39:35PM +0000, Carey, Timothy (Timothy) wrote: > > 2) Item 2 > > > > // Task Configuration object with string name to allow reference from > > Schedule. Contains URI to link to registry or local // specification > > of Task. Options allow the configuration of Task parameters (in the > > form of name-value pairs) object { string ma-task-name; uri > > ma-task-registry; name-value-pair ma-task-options<0..*>; [boolean > > ma-task-suppress-by-default;] // default: TRUE [string > > ma-task-cycle-id;] } ma-task-obj; > > > > For the "names" in many of these objects it seems we want to make these unique keys within the context of the MA. This may be a problem from the controller perspective. The controller would have to know which "names" are used for what MA. - Much easier to make these names UUIDs and call it a day. - You can still have a label if you like - but identifiers should be unique in the context of the controller. > > > > I am not sure using UUIDs is a good choice for names yet. Several deployed systems seem to use names scoped by the local system and in fact that same name for the same thing over multiple MAs. I do not see why the names benefit from being globally unique. The MA has a unique identifier and hence uniqueness can always be achieved when needed. > > Well then we should say that the MA+Name is what makes it unique. My point was that a controller will need to figure out how to make a the object instance unique. If our expectation is that the name will be unique for that object type in the context of an MA, then lets state that expectation. That way a controller can figure out how it would like to define the names. It also helps people when they develop a data model (e.g., TR-069). Now I know I can put a uniqueKey constraint on all the Name parameters; before your statement I was hesitant given the examples. > I am not sure about the "uniqueKey constraint on all the Name parameters" and surely do not want to be held responsible for whatever this means. If I were to translate the information model to YANG, the names would be unique for the given thing they are naming (the smallest possible scope). For example, I would allow a channel and a schedule to have the same name but the names of all schedules would have to be unique and the names of all channels would have to be unique. /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 Aug 12 13:51:31 2014 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 57E901A01E6; Tue, 12 Aug 2014 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JdvSKHJuB6W; Tue, 12 Aug 2014 13:51:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8451A01AA; Tue, 12 Aug 2014 13:51:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812205126.14865.76161.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 13:51:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iqiAOUZGGU5wxlf00DSisb-qc7U Cc: lmap@ietf.org Subject: [lmap] LMAP WG Interim Meeting, September 15, 2014 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: Tue, 12 Aug 2014 20:51:28 -0000 The IETF LMAP Working Group has agreed to hold an Interim face-to-face meeting in coordination with the BroadBand Forum's Q3 meeting in Dublin, Ireland. The LMAP Interim meeting will take place on Monday, September 15th and will be followed by a SB-304 Straw Ballot, joint IETF/BBF workshop, and Educational session on Tuesday. Participation in the LMAP Interim meeting is open to all IETF participants and does not require BBF membership. Participants in the LMAP WG, who are not regular BBF WG participants, will be provided with Guest BBF badges that will allow them into the joint workshop and SB-304 meetings. Note that BBF members who plan to attend BBF WG sessions should still register as per the normal BBF process. DETAILS Date: September 15, 2014 Time: 1430-1830 (2:30-6:30) IST Place: DoubleTree Dublin - Burlington Road * BBF discount rates apply, see http://www.broadband-forum.org/meetings/registration.php#Hotel for details. * Hotel reservation deadline is August 22, 2014 TO REGISTER Registration Deadline: Tuesday, September 2, 2014 Please RSVP to the LMAP WG chairs at lmap-chairs@tools.ietf.org by Tuesday, September 2, 2014. Please include the following information in your RSVP: To: lmap-chairs@tools.ietf.org Subject: RSVP for LMAP WG Interim First Name: Last Name: Company: Are you a BBF Member: [Yes / No] If yes, do you plan to attend the rest of the BBF Meeting (separate registration required, see http://www.broadband-forum.org/meetings/registration.php): [Yes / No] From nobody Wed Aug 20 03:43:41 2014 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 583AE1A01EF; Wed, 20 Aug 2014 03:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlRr4HgCSl-u; Wed, 20 Aug 2014 03:43:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 407631A01D8; Wed, 20 Aug 2014 03:43:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820104338.28419.16584.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 03:43:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CVAZy6hP5uLTGhOLGO15pEQ19_c Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-02.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, 20 Aug 2014 10:43: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 : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-02.txt Pages : 36 Date : 2014-08-20 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-information-model-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-02 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 Wed Aug 20 03:54:52 2014 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 E498E1A01DC for ; Wed, 20 Aug 2014 03:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 YiXBT6UKQTCG for ; Wed, 20 Aug 2014 03:54:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE621A01D8 for ; Wed, 20 Aug 2014 03:54:47 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 11:54:49 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.42]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 20 Aug 2014 11:54:45 +0100 From: To: Date: Wed, 20 Aug 2014 11:54:43 +0100 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-02.txt Thread-Index: Ac+8Y6ChLLtC1/ZUR/KR/Sxbt9OE+AAAI0Bw Message-ID: References: <20140820104338.28419.16584.idtracker@ietfa.amsl.com> In-Reply-To: <20140820104338.28419.16584.idtracker@ietfa.amsl.com> 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: http://mailarchive.ietf.org/arch/msg/lmap/fLmVmpKb5PE1q7y--zLKLnxBn9Y Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-02.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, 20 Aug 2014 10:54:51 -0000 I have submitted version 02 of the information model following comments rec= eived before or during Toronto IETF. The only significant revision is to task outputs assignment within the sche= dule. This has now changed to separate out channel assignment and output ma= pping to downstream tasks. This hopefully makes things clearer and allows m= ore specific/meaningful language to be used. I have accommodated all the suggestions from Ken Ko, Tim Carey and Michael = Faath (thanks all!) except the following that remain as further discussion = points: - credentials still remains as an undefined data object - names for task configurations, channels etc. remain as text set by the co= ntroller. There was a suggestion by Tim to have these automated to UUIDs in= some manner. I think we need a discussion on how this could work. Trevor Burbridge >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- >drafts@ietf.org >Sent: 20 August 2014 11:44 >To: i-d-announce@ietf.org >Cc: lmap@ietf.org >Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-02.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Large-Scale Measurement of Broadband >Performance Working Group of the IETF. > > Title : Information Model for Large-Scale Measurement Pl= atforms >(LMAP) > Authors : Trevor Burbridge > Philip Eardley > Marcelo Bagnulo > Juergen Schoenwaelder > Filename : draft-ietf-lmap-information-model-02.txt > Pages : 36 > Date : 2014-08-20 > >Abstract: > This Information Model applies to the Measurement Agent within a > Large-Scale Measurement Platform. As such it outlines the > information that is (pre-)configured on the MA or exists in > communications with a Controller or Collector within an LMAP > framework. The purpose of such an Information Model is to provide a > protocol and device independent view of the MA that can be > implemented via one or more Control and Report protocols. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-lmap-information-model-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-information-model-02 > > >Please note that it may take a couple of minutes from the time of submissi= on >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/ > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Aug 20 08:27:45 2014 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 09A1D1A069D for ; Wed, 20 Aug 2014 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 3xTkkafuFU_c for ; Wed, 20 Aug 2014 08:27:37 -0700 (PDT) Received: from catr.cn (mail.catr.cn [114.242.138.122]) by ietfa.amsl.com (Postfix) with ESMTP id 909851A06A8 for ; Wed, 20 Aug 2014 08:27:36 -0700 (PDT) Received: from userTHINK (unknown [106.37.28.2]) by app2 (Coremail) with SMTP id FxADCgBnkx0LvvRTNUMJAA--.14972S2; Wed, 20 Aug 2014 23:26:07 +0800 (CST) From: "Liu,Shu@CATR" To: , References: <20140820104338.28419.16584.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Aug 2014 23:26:06 +0800 Message-ID: <002401cfbc8b$12262700$36727500$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+8Y6ChLLtC1/ZUR/KR/Sxbt9OE+AAAI0BwAAldoyA= Content-Language: zh-cn X-Antivirus: avast! (VPS 140820-0, 2014/08/20), Outbound message X-Antivirus-Status: Clean X-CM-TRANSID: FxADCgBnkx0LvvRTNUMJAA--.14972S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWF4rCF15WrWDXrWfXryfCrg_yoW5uF18pF Wag3sYka1rJF1xWan7Ww18Zr1rZ395JFWUAF1fGw1jkas8Ga4qqr1ft3W5A34DGry5JF4j vr1S9r1UWFs5JrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x0EwIxGrwCFx2Iq xVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r 106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AK xVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7 xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWU JVW8JbIYCTnIWIevJa73UjIFyTuYvjxUgg_TUUUUU X-CM-SenderInfo: polx2xnx6ft3fuof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9FjPAA4lxjksZUWg3JHvH6NfDfw Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-02.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, 20 Aug 2014 15:27:44 -0000 There are a lot of syntax errors with the json blocks, I had checked = those in the previous version, I will do it again. If those errors keep = the way they are now, there will be pains for those coding guys.=20 First of all, please DO NOT add comment lines in json blocks, you can = add such thing as "comment": "my comment" key/value. Andrew I have submitted version 02 of the information model following comments = received before or during Toronto IETF. The only significant revision is to task outputs assignment within the = schedule. This has now changed to separate out channel assignment and = output mapping to downstream tasks. This hopefully makes things clearer = and allows more specific/meaningful language to be used. I have accommodated all the suggestions from Ken Ko, Tim Carey and = Michael Faath (thanks all!) except the following that remain as further = discussion points: - credentials still remains as an undefined data object - names for task configurations, channels etc. remain as text set by the = controller. There was a suggestion by Tim to have these automated to = UUIDs in some manner. I think we need a discussion on how this could = work. Trevor Burbridge >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet-=20 >drafts@ietf.org >Sent: 20 August 2014 11:44 >To: i-d-announce@ietf.org >Cc: lmap@ietf.org >Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-02.txt > > >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=20 >Performance Working Group of the IETF. > > Title : Information Model for Large-Scale Measurement = Platforms >(LMAP) > Authors : Trevor Burbridge > Philip Eardley > Marcelo Bagnulo > Juergen Schoenwaelder > Filename : draft-ietf-lmap-information-model-02.txt > Pages : 36 > Date : 2014-08-20 > >Abstract: > This Information Model applies to the Measurement Agent within a > Large-Scale Measurement Platform. As such it outlines the > information that is (pre-)configured on the MA or exists in > communications with a Controller or Collector within an LMAP > framework. The purpose of such an Information Model is to provide a > protocol and device independent view of the MA that can be > implemented via one or more Control and Report protocols. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-lmap-information-model-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-information-model-02 > > >Please note that it may take a couple of minutes from the time of=20 >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/ > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Aug 20 08:32:31 2014 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 5D6181A064D for ; Wed, 20 Aug 2014 08:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=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 tuF3b-Yit4iW for ; Wed, 20 Aug 2014 08:32:19 -0700 (PDT) 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 7F4BF1A06BB for ; Wed, 20 Aug 2014 08:32:12 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 16:32:16 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.42]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 20 Aug 2014 16:32:09 +0100 From: To: , Date: Wed, 20 Aug 2014 16:32:08 +0100 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-02.txt Thread-Index: Ac+8Y6ChLLtC1/ZUR/KR/Sxbt9OE+AAAI0BwAAldoyAAAHjCMA== Message-ID: References: <20140820104338.28419.16584.idtracker@ietfa.amsl.com> <002401cfbc8b$12262700$36727500$@cn> In-Reply-To: <002401cfbc8b$12262700$36727500$@cn> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/R23BFRIGXJ4Fe6w5V2c7A7AsHgc Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-02.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, 20 Aug 2014 15:32:28 -0000 SSB3b3VsZCBhcHByZWNpYXRlIGFueSBjb3JyZWN0aW9ucyB0byB0aGUgSlNPTiBvciBhbnkgb3Ro ZXIgdGV4dCAtIGhvd2V2ZXIsIEkgY2FuJ3QgZmluZCBhbnkgcHJldmlvdXMgcG9zdCBvciBlbWFp bCBmcm9tIHlvdSByZWdhcmRpbmcgdGhlc2UuDQoNClRyZXZvci4NCg0KDQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBMaXUsU2h1QENBVFIgW21haWx0bzpsaXVzaHVAY2F0ci5j bl0NCj5TZW50OiAyMCBBdWd1c3QgMjAxNCAxNjoyNg0KPlRvOiBCdXJicmlkZ2UsVCxUcmV2b3Is VFVCOCBSOyBsbWFwQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtsbWFwXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWxtYXAtaW5mb3JtYXRpb24tbW9kZWwtMDIudHh0DQo+DQo+VGhlcmUgYXJlIGEg bG90IG9mIHN5bnRheCBlcnJvcnMgd2l0aCB0aGUganNvbiBibG9ja3MsIEkgaGFkIGNoZWNrZWQg dGhvc2UgaW4gdGhlDQo+cHJldmlvdXMgdmVyc2lvbiwgSSB3aWxsIGRvIGl0IGFnYWluLiBJZiB0 aG9zZSBlcnJvcnMga2VlcCB0aGUgd2F5IHRoZXkgYXJlIG5vdywNCj50aGVyZSB3aWxsIGJlIHBh aW5zIGZvciB0aG9zZSBjb2RpbmcgZ3V5cy4NCj5GaXJzdCBvZiBhbGwsIHBsZWFzZSBETyBOT1Qg YWRkIGNvbW1lbnQgbGluZXMgaW4ganNvbiBibG9ja3MsIHlvdSBjYW4gYWRkIHN1Y2gNCj50aGlu ZyBhcyAgImNvbW1lbnQiOiAibXkgY29tbWVudCIgIGtleS92YWx1ZS4NCj4NCj5BbmRyZXcNCj4N Cj4NCj5JIGhhdmUgc3VibWl0dGVkIHZlcnNpb24gMDIgb2YgdGhlIGluZm9ybWF0aW9uIG1vZGVs IGZvbGxvd2luZyBjb21tZW50cw0KPnJlY2VpdmVkIGJlZm9yZSBvciBkdXJpbmcgVG9yb250byBJ RVRGLg0KPg0KPlRoZSBvbmx5IHNpZ25pZmljYW50IHJldmlzaW9uIGlzIHRvIHRhc2sgb3V0cHV0 cyBhc3NpZ25tZW50IHdpdGhpbiB0aGUgc2NoZWR1bGUuDQo+VGhpcyBoYXMgbm93IGNoYW5nZWQg dG8gc2VwYXJhdGUgb3V0IGNoYW5uZWwgYXNzaWdubWVudCBhbmQgb3V0cHV0IG1hcHBpbmcgdG8N Cj5kb3duc3RyZWFtIHRhc2tzLiBUaGlzIGhvcGVmdWxseSBtYWtlcyB0aGluZ3MgY2xlYXJlciBh bmQgYWxsb3dzIG1vcmUNCj5zcGVjaWZpYy9tZWFuaW5nZnVsIGxhbmd1YWdlIHRvIGJlIHVzZWQu DQo+DQo+SSBoYXZlIGFjY29tbW9kYXRlZCBhbGwgdGhlIHN1Z2dlc3Rpb25zIGZyb20gS2VuIEtv LCBUaW0gQ2FyZXkgYW5kIE1pY2hhZWwNCj5GYWF0aCAodGhhbmtzIGFsbCEpIGV4Y2VwdCB0aGUg Zm9sbG93aW5nIHRoYXQgcmVtYWluIGFzIGZ1cnRoZXIgZGlzY3Vzc2lvbiBwb2ludHM6DQo+DQo+ LSBjcmVkZW50aWFscyBzdGlsbCByZW1haW5zIGFzIGFuIHVuZGVmaW5lZCBkYXRhIG9iamVjdA0K Pi0gbmFtZXMgZm9yIHRhc2sgY29uZmlndXJhdGlvbnMsIGNoYW5uZWxzIGV0Yy4gcmVtYWluIGFz IHRleHQgc2V0IGJ5IHRoZQ0KPmNvbnRyb2xsZXIuIFRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gYnkg VGltIHRvIGhhdmUgdGhlc2UgYXV0b21hdGVkIHRvIFVVSURzIGluDQo+c29tZSBtYW5uZXIuIEkg dGhpbmsgd2UgbmVlZCBhIGRpc2N1c3Npb24gb24gaG93IHRoaXMgY291bGQgd29yay4NCj4NCj5U cmV2b3IgQnVyYnJpZGdlDQo+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206 IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5l dC0NCj4+ZHJhZnRzQGlldGYub3JnDQo+PlNlbnQ6IDIwIEF1Z3VzdCAyMDE0IDExOjQ0DQo+PlRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Q2M6IGxtYXBAaWV0Zi5vcmcNCj4+U3ViamVjdDog W2xtYXBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0wMi50 eHQNCj4+DQo+Pg0KPj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBMYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBvZiBCcm9hZGJhbmQNCj4+ UGVyZm9ybWFuY2UgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+DQo+PiAgICAgICAgVGl0 bGUgICAgICAgICAgIDogSW5mb3JtYXRpb24gTW9kZWwgZm9yIExhcmdlLVNjYWxlIE1lYXN1cmVt ZW50IFBsYXRmb3Jtcw0KPj4oTE1BUCkNCj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBUcmV2 b3IgQnVyYnJpZGdlDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbGlwIEVhcmRsZXkN Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjZWxvIEJhZ251bG8NCj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4+CUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0wMi50eHQNCj4+CVBhZ2VzICAg ICAgICAgICA6IDM2DQo+PglEYXRlICAgICAgICAgICAgOiAyMDE0LTA4LTIwDQo+Pg0KPj5BYnN0 cmFjdDoNCj4+ICAgVGhpcyBJbmZvcm1hdGlvbiBNb2RlbCBhcHBsaWVzIHRvIHRoZSBNZWFzdXJl bWVudCBBZ2VudCB3aXRoaW4gYQ0KPj4gICBMYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBQbGF0Zm9y bS4gIEFzIHN1Y2ggaXQgb3V0bGluZXMgdGhlDQo+PiAgIGluZm9ybWF0aW9uIHRoYXQgaXMgKHBy ZS0pY29uZmlndXJlZCBvbiB0aGUgTUEgb3IgZXhpc3RzIGluDQo+PiAgIGNvbW11bmljYXRpb25z IHdpdGggYSBDb250cm9sbGVyIG9yIENvbGxlY3RvciB3aXRoaW4gYW4gTE1BUA0KPj4gICBmcmFt ZXdvcmsuICBUaGUgcHVycG9zZSBvZiBzdWNoIGFuIEluZm9ybWF0aW9uIE1vZGVsIGlzIHRvIHBy b3ZpZGUgYQ0KPj4gICBwcm90b2NvbCBhbmQgZGV2aWNlIGluZGVwZW5kZW50IHZpZXcgb2YgdGhl IE1BIHRoYXQgY2FuIGJlDQo+PiAgIGltcGxlbWVudGVkIHZpYSBvbmUgb3IgbW9yZSBDb250cm9s IGFuZCBSZXBvcnQgcHJvdG9jb2xzLg0KPj4NCj4+DQo+Pg0KPj5UaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsLw0KPj4NCj4+VGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0wMg0KPj4N Cj4+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj5o dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxtYXAtaW5mb3JtYXRp b24tbW9kZWwtMDINCj4+DQo+Pg0KPj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj5zdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+Pg0KPj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pg0KPj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5sbWFwIG1haWxp bmcgbGlzdA0KPj5sbWFwQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbG1hcA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+bG1hcCBtYWlsaW5nIGxpc3QNCj5sbWFwQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwDQo+DQoNCg== From nobody Tue Aug 26 07:21:28 2014 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 DC10E1A70FF for ; Tue, 26 Aug 2014 07:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.568 X-Spam-Level: * X-Spam-Status: No, score=1.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, 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 oKSwKqpqa65f for ; Tue, 26 Aug 2014 07:21:19 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E11A51A70E2 for ; Tue, 26 Aug 2014 07:21:18 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,404,1406606400"; d="scan'208,217";a="482086088" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Aug 2014 10:20:33 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 26 Aug 2014 10:21:18 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 26 Aug 2014 10:21:16 -0400 Thread-Topic: RSVP List for LMAP Interim Meeting - Deadline September 2nd Thread-Index: Ac/BOQAac4YMXl3OQ4CNeLMTIdnmfQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D0220FE433243jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/SltsopnaAJhBVC48pQ7S9wkNmZg Subject: [lmap] RSVP List for LMAP Interim Meeting - Deadline September 2nd 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, 26 Aug 2014 14:21:20 -0000 --_000_D0220FE433243jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable LMAP WG, Below is the current current RSVP list for the LMAP Interim meeting on Sept= ember 15th in Dublin, Ireland. If you have sent an RSVP and I don=92t have = you on this list please let know. For others thinking of attending, this is= a reminder that the registration deadline is September 2nd. We have room f= or 30 in the session so if you are able to attend we have room and would ap= preciate your input. 1. Jason Weil 2. Stephen Farrell (Maybe) 3. Marcelo Bagnulo Braun 4. Ken Ko 5. Philip Eardley 6. Timothy Carey 7. Juergen Schoenwaelder 8. Valibhav Bajpai Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D0220FE433243jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
LMAP WG,

Below is the current current RSVP list for the LMAP Interim meeting on= September 15th in Dublin, Ireland. If you have sent an RSVP and I don=92t = have you on this list please let know. For others thinking of attending, th= is is a reminder that the registration deadline is September 2nd. We have room for 30 in the session so if you ar= e able to attend we have room and would appreciate your input. 
  1. Jason Weil
  2. Stephen Farrell (Maybe)
  3. Marcelo Bagnulo Brau= n
  4. Ken Ko
  5. Philip Eardley
  6. Timothy Carey
  7. Juerg= en Schoenwaelder
  8. Valibhav Bajpai
Thanks,

Jason

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D0220FE433243jasonweiltwcablecom_-- From nobody Tue Aug 26 08:32:20 2014 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 CB67B1A872E for ; Tue, 26 Aug 2014 08:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 2A1MiyJxJT8U for ; Tue, 26 Aug 2014 08:32:17 -0700 (PDT) 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 100C31A8716 for ; Tue, 26 Aug 2014 08:32:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkLAAio/FOHCzIm/2dsb2JhbABbgkcjIyAzVwSvKAEBAQEGBYMXmCKBOh8BCYdNAYESFneEBQEBAxILEF4BDAkVViYBBBsBGYggAQyaT4Rln2wXhXyJH4JwD0QkgR0FkSaEKYhShgCES4hpg15sAYFHgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,405,1406606400"; d="scan'208,217"; a="79856149" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2014 11:32:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 26 Aug 2014 11:32:15 -0400 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; Tue, 26 Aug 2014 17:32:14 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC for draft-ietf-lmap-information-model-02 Thread-Index: Ac/BQujDjG1RKhmLRGOmCs5EZkqp/A== Date: Tue, 26 Aug 2014 15:32:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@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.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CEDBAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/w_AAecigXGb_fp2vnr5P-AJ-Bro Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 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, 26 Aug 2014 15:32:19 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CEDBAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 9, 2014. If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list. The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CEDBAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message opens a Working Group Last Call for the= draft-ietf-lmap-information-model-02 Internet-Draft.

 

Please read and send comments about this document to= the LMAP WG list before Wednesday September 9, 2014.

 

If you read the document and believe that it’s= ready to be submitted to the IESG for consideration as Proposed standards,= please state this in a short message to the list.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. <= /o:p>

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CEDBAZFFEXMB04globa_-- From nobody Tue Aug 26 08:44:51 2014 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 35A3E1A875D for ; Tue, 26 Aug 2014 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 ypJJ93G3H9XI for ; Tue, 26 Aug 2014 08:44:47 -0700 (PDT) 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 EB11B1A8759 for ; Tue, 26 Aug 2014 08:44:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkLADOq/FOHCzIm/2dsb2JhbABbgkcjIyAzVwSvKAEBAQEGBYMXmCKBOh8BCYdNAYESFneEBQEBAxILEF4BDAkVViYBBBsBGYggAQyaVIRln2wXhXyJH4JwD0QkgR0FkSaEKYhShgCES4hpg15sAYFHgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,405,1406606400"; d="scan'208,217"; a="69941847" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Aug 2014 11:44:43 -0400 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; 26 Aug 2014 11:44:42 -0400 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; Tue, 26 Aug 2014 11:44:41 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQ== Date: Tue, 26 Aug 2014 15:44:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@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.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CF15AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0eoVFsGm6nSvYUnCT-g-zlQRjXc Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 26 Aug 2014 15:44:49 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CF15AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 10, 2014. If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list. The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CF15AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message opens a Working Group Last Call for the= draft-ietf-lmap-information-model-02 Internet-Draft.

 

Please read and send comments about this document to= the LMAP WG list before Wednesday September 10, 2014.

 

If you read the document and believe that it’s= ready to be submitted to the IESG for consideration as Proposed standards,= please state this in a short message to the list.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. <= /o:p>

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C87CF15AZFFEXMB04globa_-- From nobody Tue Aug 26 17:38:57 2014 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 6613A1A0296 for ; Tue, 26 Aug 2014 17:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.687 X-Spam-Level: X-Spam-Status: No, score=0.687 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 kkwAfV7lWGl1 for ; Tue, 26 Aug 2014 17:38:54 -0700 (PDT) Received: from catr.cn (catrma.catr.cn [219.239.97.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5EF1A0295 for ; Tue, 26 Aug 2014 17:38:53 -0700 (PDT) Received: from userTHINK (unknown [172.30.10.149]) by app1 (Coremail) with SMTP id FhADCgC3ve0XKP1TLFMMAA--.6672S2; Wed, 27 Aug 2014 08:36:40 +0800 (CST) From: "Liu,Shu@CATR" To: "'Romascanu, Dan \(Dan\)'" , References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> Date: Wed, 27 Aug 2014 08:36:40 +0800 Message-ID: <003401cfc18e$f87b2310$e9716930$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CFC1D2.069E6310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFg Content-Language: zh-cn X-Antivirus: avast! (VPS 140826-1, 2014/08/27), Outbound message X-Antivirus-Status: Clean X-CM-TRANSID: FhADCgC3ve0XKP1TLFMMAA--.6672S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKw13GryrWF45Jr4kCw1kGrg_yoWfCrgE9F yDtas8tFWUJFsxAr4Sgrsxtr4aq39I9Fy3AaykAr12q348Aan5AF9Fqwn8Zw1Fqw45uF15 AFs3J34rAFWfWjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb9AYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6ryj6rWUMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r4j6ryUMc02F4 0E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAazxkCjI0Eb7x7McIj6xIIjxv20xvE 14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2 IYc2Ij64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxAIw28IcxkI7VAKI48JMxC20s026xCa FVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_Jr Wlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j 6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WF yUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4U YxBIdaVFxhVjvjDU0xZFpf9x07j1WlkUUUUU= X-CM-SenderInfo: polx2xnx6ft3fuof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hug1SrfDSDKFA_bJ_wQjrErrwoc Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 27 Aug 2014 00:38:56 -0000 һ MIME ʽĶಿʼ ------=_NextPart_000_0035_01CFC1D2.069E6310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The JSON blocks have a lot of syntax errors, I sent the parsable blocks = to Trevor, since the list did not allow me to post it. =20 Andy From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = Romascanu, Dan (Dan) Sent: Tuesday, August 26, 2014 11:45 PM To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected = date) =20 This message opens a Working Group Last Call for the = draft-ietf-lmap-information-model-02 = = Internet-Draft. =20 Please read and send comments about this document to the LMAP WG list = before Wednesday September 10, 2014.=20 =20 If you read the document and believe that it=E2=80=99s ready to be = submitted to the IESG for consideration as Proposed standards, please = state this in a short message to the list.=20 =20 The document is available at = http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt.=20 =20 Thanks and Regards, =20 Jason and Dan =20 =20 ------=_NextPart_000_0035_01CFC1D2.069E6310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The JSON blocks have a lot of syntax errors, I sent the parsable blocks to = Trevor, since the list did not allow me to post it.

 

Andy

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Tuesday, August 26, 2014 11:45 PM
To: lmap@ietf.org
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 = (corrected date)

 

This message opens a Working = Group Last Call for the draft-ietf-lmap-information-model-02 Internet-Draft.

 

Please read and send comments = about this document to the LMAP WG list before Wednesday September 10, 2014. =

 

If you read the document and = believe that it=E2=80=99s ready to be submitted to the IESG for consideration as = Proposed standards, please state this in a short message to the list.

 

The document is available at = http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt.

 

Thanks and = Regards,

 

Jason and = Dan

 

 

------=_NextPart_000_0035_01CFC1D2.069E6310-- From nobody Wed Aug 27 03:41:58 2014 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 12BE21A05C0 for ; Wed, 27 Aug 2014 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 yrHkDIsEa83k for ; Wed, 27 Aug 2014 03:41:55 -0700 (PDT) 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 5996A1A058E for ; Wed, 27 Aug 2014 03:41:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmILALa0/VPGmAcV/2dsb2JhbABbgkcjIyAzVwSvCQiceCEBCYdMAYEPFneEBQEBAxIbXgEMCRVWJgEEGwEZiCABDJs/hGWfBBeFfIYhAYJdAQEegnAPRCSBHQWRL4ZnjB+ENYkFg15sAYEOOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,409,1406606400"; d="scan'208,217"; a="79977094" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Aug 2014 06:41:54 -0400 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; 27 Aug 2014 06:41:53 -0400 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, 27 Aug 2014 06:41:52 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP Framework - ready for submission to the IESG? Thread-Index: Ac/B44MV/q3ebtFuToqdna6pxGH8yQ== Date: Wed, 27 Aug 2014 10:41:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2@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.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zMXT9Cgdkf1g17VenrS0HrjLVxg Subject: [lmap] LMAP Framework - ready for submission to the IESG? 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, 27 Aug 2014 10:41:57 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A revised I-D for the LMAP framework was submitted and is available at http= ://www.ietf.org/id/draft-ietf-lmap-framework-08.txt. We already ran two WGLCs for this I-D, and we deferred the decision about t= he need of a third one after IETF-90, in order to allow for an examination = of the list of changes. Phil described the changes in http://www.ietf.org/m= ail-archive/web/lmap/current/msg01742.html. Jason and me believe that a ful= l WGLC is not needed, but we would like to allow for one more week for folk= s who have sent comments to check and confirm that they were addressed, and= for everybody else to have another look and share any concerns left. So, please, have another read of this document and let us know if you belie= ve that there are good reasons NOT to forward this document to the IESG for= considerations and Informational RFC. Please send these before Wednesday, = September 3, 2014, COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A revised I-D for the LMAP framework was submitted a= nd is available at http://= www.ietf.org/id/draft-ietf-lmap-framework-08.txt.

 

We already ran two WGLCs for this I-D, and we deferr= ed the decision about the need of a third one after IETF-90, in order to al= low for an examination of the list of changes. Phil described the changes i= n http://www.ietf.org/mail-archive/web/lmap/current/msg01742.html. Jason= and me believe that a full WGLC is not needed, but we would like to allow = for one more week for folks who have sent comments to check and confirm that they were addressed, and for every= body else to have another look and share any concerns left.

 

So, please, have another read of this document and l= et us know if you believe that there are good reasons NOT to forward this d= ocument to the IESG for considerations and Informational RFC. Please send t= hese before Wednesday, September 3, 2014, COB.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2AZFFEXMB04globa_-- From nobody Wed Aug 27 06:21:30 2014 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 255401A06B1 for ; Wed, 27 Aug 2014 06:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 6TODIirLnx5I for ; Wed, 27 Aug 2014 06:21:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0551A06AC for ; Wed, 27 Aug 2014 06:21:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 86212ED4; Wed, 27 Aug 2014 15:21:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qSqwQNowJdmT; Wed, 27 Aug 2014 15:21:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 15:21:18 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC34B20035; Wed, 27 Aug 2014 15:21:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fz8DdM2e-e9d; Wed, 27 Aug 2014 15:21:17 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 9799320033; Wed, 27 Aug 2014 15:21:15 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 15:21:15 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFgABaVdwA= Date: Wed, 27 Aug 2014 13:21:15 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> In-Reply-To: <003401cfc18e$f87b2310$e9716930$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F53157EA49545489376D49F83BE1A1E@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/IzC37RiYzdansp8zipB1tRtzUQ4 Cc: "Bajpai, Vaibhav" , Dan Romascanu , "Liu, Shu@CATR" Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 27 Aug 2014 13:21:27 -0000 ** LMAP > On 27 Aug 2014, at 02:36, Liu,Shu@CATR wrote: >=20 > The JSON blocks have a lot of syntax errors, I sent the > parsable blocks to Trevor, since the list did not allow me to > post it. AFAIK, the JSON example is in the appendix for a reason. It=20 is only meant to provide a _hint_ on how to translate the=20 abstract objects into a concrete data model. As such, the=20 example should not be used by implementations anyway. In order to avoid digressing ourselves into the JSON example, I propose to remove the JSON fragments from this document. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com From nobody Wed Aug 27 06:39:27 2014 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 DF64E1A06BC for ; Wed, 27 Aug 2014 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, 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 E4OU_pyOLXf4 for ; Wed, 27 Aug 2014 06:39:24 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7CE1A06BB for ; Wed, 27 Aug 2014 06:39:24 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so301437pab.15 for ; Wed, 27 Aug 2014 06:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=i79+NLRalAVxliQUmKF01B0QDmYsWC4SxHeYejOX8SA=; b=hVfzCJA1F9c1totJhF9zD2d4VAIIeMHFBdLjlwZ3+S7ewUU0sLb/7mj2JYyfQbN3DP 0k36J/GcDI8Ck/c3OCg3MBbelA9L6XrmgToamE9FeaAJPz52z/vQDu79BgVvYVBAgObk laPJWD864tSOvtTCUQ1vfkvHXNH+aBl3JQvBvbnW/vb8y3oTlMX33iQcVJHiCyi74vNJ RPQeYa6UP4aAsCtkpjNWIx+4l4d6PX23pIlKRFm5VHTeNGih1RY20Ap8LigrJKbyxmH9 eI7jAcIldOP339zxN0Widd5h2rcogAh7CKfeDjaFYw+rI3P9gJwGfu52xS3oR89MJNn7 GKVQ== X-Received: by 10.68.200.101 with SMTP id jr5mr46311043pbc.36.1409146761442; Wed, 27 Aug 2014 06:39:21 -0700 (PDT) Received: from [192.168.255.64] ([106.37.28.5]) by mx.google.com with ESMTPSA id y9sm1514585pas.23.2014.08.27.06.39.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 06:39:20 -0700 (PDT) Date: Wed, 27 Aug 2014 21:39:19 +0800 Message-ID: From: "pop.andrew" To: "Bajpai, Vaibhav" , lmap@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QqE1ihzdKIlRMLGmg8yEfGLQv_A Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 27 Aug 2014 13:39:26 -0000 PHAgZGlyPSJsdHIiPkkgdGhpbmsgd2UgaGFkIGJldHRlciBrZWVwIHRob3NlLCB0aGV5IHdvbid0 IGNhdXNlIGFueSB0cm91YmxlLjwvcD4KPGRpdiBjbGFzcz0icXVvdGUiPiZxdW90O0JhanBhaSwg VmFpYmhhdiZxdW90OyAmbHQ7di5iYWpwYWlAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q75LqOIDIw MTQtOC0yNyDkuIvljYg5OjIx5YaZ6YGT77yaPGJyIHR5cGU9J2F0dHJpYnV0aW9uJz48YmxvY2tx dW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48cCBkaXI9Imx0ciI+KiogTE1BUCYjMTM7 PGJyPgomIzEzOzxicj4KJmd0OyBPbiAyNyBBdWcgMjAxNCwgYXQgMDI6MzYsIExpdSxTaHVAQ0FU UiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpdXNodUBjYXRyLmNuIj5saXVzaHVAY2F0ci5jbjwvYT4m Z3Q7IHdyb3RlOiYjMTM7PGJyPgomZ3Q7ICYjMTM7PGJyPgomZ3Q7IFRoZSBKU09OIGJsb2NrcyBo YXZlIGEgbG90IG9mIHN5bnRheCBlcnJvcnMsIEkgc2VudCB0aGUmIzEzOzxicj4KJmd0OyBwYXJz YWJsZSBibG9ja3MgdG8gVHJldm9yLCBzaW5jZSB0aGUgbGlzdCBkaWQgbm90IGFsbG93IG1lIHRv JiMxMzs8YnI+CiZndDsgcG9zdCBpdC4mIzEzOzxicj4KJiMxMzs8YnI+CkFGQUlLLCB0aGUgSlNP TiBleGFtcGxlIGlzIGluIHRoZSBhcHBlbmRpeCBmb3IgYSByZWFzb24uIEl0ICYjMTM7PGJyPgpp cyBvbmx5IG1lYW50IHRvIHByb3ZpZGUgYSBfaGludF8gb24gaG93IHRvIHRyYW5zbGF0ZSB0aGUg JiMxMzs8YnI+CmFic3RyYWN0IG9iamVjdHMgaW50byBhIGNvbmNyZXRlIGRhdGEgbW9kZWwuIEFz IHN1Y2gsIHRoZSAmIzEzOzxicj4KZXhhbXBsZSBzaG91bGQgbm90IGJlIHVzZWQgYnkgaW1wbGVt ZW50YXRpb25zIGFueXdheS4mIzEzOzxicj4KJiMxMzs8YnI+CkluIG9yZGVyIHRvIGF2b2lkIGRp Z3Jlc3Npbmcgb3Vyc2VsdmVzIGludG8gdGhlIEpTT04gZXhhbXBsZSwmIzEzOzxicj4KSSBwcm9w b3NlIHRvIHJlbW92ZSB0aGUgSlNPTiBmcmFnbWVudHMgZnJvbSB0aGlzIGRvY3VtZW50LiYjMTM7 PGJyPgomIzEzOzxicj4KQmVzdCwgVmFpYmhhdiYjMTM7PGJyPgomIzEzOzxicj4KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzEzOzxicj4KVmFp YmhhdiBCYWpwYWkmIzEzOzxicj4KJiMxMzs8YnI+ClJlc2VhcmNoIEksIFJvb20gOTEmIzEzOzxi cj4KQ29tcHV0ZXIgTmV0d29ya3MgYW5kIERpc3RyaWJ1dGVkIFN5c3RlbXMmbmJzcDsgKENORFMp IExhYiYjMTM7PGJyPgpTY2hvb2wgb2YgRW5naW5lZXJpbmcgYW5kIFNjaWVuY2VzJiMxMzs8YnI+ CkphY29icyBVbml2ZXJzaXR5IEJyZW1lbiwgR2VybWFueSYjMTM7PGJyPgomIzEzOzxicj4KPGEg aHJlZj0iaHR0cDovL3d3dy52YWliaGF2YmFqcGFpLmNvbSI+d3d3LnZhaWJoYXZiYWpwYWkuY29t PC9hPiYjMTM7PGJyPgomIzEzOzxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18mIzEzOzxicj4KbG1hcCBtYWlsaW5nIGxpc3QmIzEzOzxicj4KPGEgaHJl Zj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciPmxtYXBAaWV0Zi5vcmc8L2E+JiMxMzs8YnI+CjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwPC9hPiYjMTM7PGJyPgo8L3A+CjwvYmxv Y2txdW90ZT48L2Rpdj4= From nobody Thu Aug 28 03:25:34 2014 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 261081A6F1E for ; Thu, 28 Aug 2014 03:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 yb_22fmfmFJL for ; Thu, 28 Aug 2014 03:25:31 -0700 (PDT) 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 8FCDF1A6F11 for ; Thu, 28 Aug 2014 03:25:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQLABcD/1PGmAcV/2dsb2JhbABbgmojU1cErmoMAQUGhVSXTIdTAYEdFneEAwEBAQEDEigPMAwEAgEIDQMBBAEBAQoUCQcyFAkIAQEEAQ0FCBqIIAGgNZ8EF4V8hAOFHDEHBoMpgR0FhhOLHIZnjCGETYhug15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,417,1406606400"; d="scan'208";a="80132024" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Aug 2014 06:25:30 -0400 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; 28 Aug 2014 06:25:30 -0400 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; Thu, 28 Aug 2014 12:25:28 +0200 From: "Romascanu, Dan (Dan)" To: "Bajpai, Vaibhav" , "" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFgABaVdwAAMEkT0A== Date: Thu, 28 Aug 2014 10:25:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LSs7ltzANIMOR4Zj2x_JjXlajNU Cc: "Liu,Shu@CATR" Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 28 Aug 2014 10:25:33 -0000 Hi, If we decide to keep them, the examples should be as clean syntactically as= we can make them. (even if included in an appendix) Regards, Dan > -----Original Message----- > From: Bajpai, Vaibhav [mailto:v.bajpai@jacobs-university.de] > Sent: Wednesday, August 27, 2014 4:21 PM > To: > Cc: Bajpai, Vaibhav; Romascanu, Dan (Dan); Liu,Shu@CATR > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > (corrected date) >=20 > ** LMAP >=20 > > On 27 Aug 2014, at 02:36, Liu,Shu@CATR wrote: > > > > The JSON blocks have a lot of syntax errors, I sent the parsable > > blocks to Trevor, since the list did not allow me to post it. >=20 > AFAIK, the JSON example is in the appendix for a reason. It is only meant= to > provide a _hint_ on how to translate the abstract objects into a concrete= data > model. As such, the example should not be used by implementations > anyway. >=20 > In order to avoid digressing ourselves into the JSON example, I propose t= o > remove the JSON fragments from this document. >=20 > Best, Vaibhav >=20 > ----------------------------------------------------- > Vaibhav Bajpai >=20 > Research I, Room 91 > Computer Networks and Distributed Systems (CNDS) Lab School of > Engineering and Sciences Jacobs University Bremen, Germany >=20 > www.vaibhavbajpai.com From nobody Thu Aug 28 06:36:47 2014 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 EE50C1A0421 for ; Thu, 28 Aug 2014 06:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_IS_SMALL6=0.556, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 79GNqKlLoyAH for ; Thu, 28 Aug 2014 06:36:42 -0700 (PDT) Received: from catr.cn (catrma.catr.cn [219.239.97.64]) by ietfa.amsl.com (Postfix) with ESMTP id EE9891A0424 for ; Thu, 28 Aug 2014 06:36:40 -0700 (PDT) Received: from userTHINK (unknown [106.37.24.64]) by app1 (Coremail) with SMTP id FhADCgAHD+8vMP9T+u4MAA--.7626S2; Thu, 28 Aug 2014 21:35:47 +0800 (CST) From: "Liu,Shu@CATR" To: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> Date: Thu, 28 Aug 2014 21:35:44 +0800 Message-ID: <002c01cfc2c4$fbd91440$f38b3cc0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFgABaVdwAAMEkT0AAGrpQQ Content-Language: zh-cn X-Antivirus: avast! (VPS 140827-1, 2014/08/28), Outbound message X-Antivirus-Status: Clean X-CM-TRANSID: FhADCgAHD+8vMP9T+u4MAA--.7626S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uw4rtryftFykKF1xWF48Zwb_yoW8WrWDpF y3ta43tr4kJF17XFWvgF4qkr1rZwn5tr1UXwnxKwnY9345CFyvqr4aya4xXFWUGryUJw45 tr42qryDZ3WfWFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyab7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l4I8I 3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxV WUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAF wI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcI k0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_ Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8pnQUUUUUU== X-CM-SenderInfo: polx2xnx6ft3fuof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zYzG_BPkfaUQusjOuMVEiQenDQ4 Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 28 Aug 2014 13:36:44 -0000 I couldn't agree more. Andy -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Thursday, August 28, 2014 6:25 PM To: Bajpai, Vaibhav; Cc: Liu,Shu@CATR Subject: RE: [lmap] WGLC for draft-ietf-lmap-information-model-02 = (corrected date) Hi, If we decide to keep them, the examples should be as clean syntactically = as we can make them. (even if included in an appendix) Regards, Dan > -----Original Message----- > From: Bajpai, Vaibhav [mailto:v.bajpai@jacobs-university.de] > Sent: Wednesday, August 27, 2014 4:21 PM > To: > Cc: Bajpai, Vaibhav; Romascanu, Dan (Dan); Liu,Shu@CATR > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > (corrected date) >=20 > ** LMAP >=20 > > On 27 Aug 2014, at 02:36, Liu,Shu@CATR wrote: > > > > The JSON blocks have a lot of syntax errors, I sent the parsable=20 > > blocks to Trevor, since the list did not allow me to post it. >=20 > AFAIK, the JSON example is in the appendix for a reason. It is only=20 > meant to provide a _hint_ on how to translate the abstract objects=20 > into a concrete data model. As such, the example should not be used by = > implementations anyway. >=20 > In order to avoid digressing ourselves into the JSON example, I=20 > propose to remove the JSON fragments from this document. >=20 > Best, Vaibhav >=20 > ----------------------------------------------------- > Vaibhav Bajpai >=20 > Research I, Room 91 > Computer Networks and Distributed Systems (CNDS) Lab School of=20 > Engineering and Sciences Jacobs University Bremen, Germany >=20 > www.vaibhavbajpai.com From nobody Thu Aug 28 08:59:37 2014 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 AAE7F1A877B for ; Thu, 28 Aug 2014 08:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 rCcEORoobgxM for ; Thu, 28 Aug 2014 08:59:21 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770EA1A8770 for ; Thu, 28 Aug 2014 08:59:10 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s7SFx8UL011778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 09:59:08 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5EB441E0077; Thu, 28 Aug 2014 09:59:03 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 37ABE1E0076; Thu, 28 Aug 2014 09:59:03 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s7SFx2VE003591; Thu, 28 Aug 2014 10:59:02 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s7SFx2sI003566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 10:59:02 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 28 Aug 2014 10:59:01 -0500 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , "'lmap@ietf.org'" , "Cook, Charles" Thread-Topic: [lmap] RSVP List for LMAP Interim Meeting - Deadline September 2nd Thread-Index: Ac/BOQAac4YMXl3OQ4CNeLMTIdnmfQBn+bZQ Date: Thu, 28 Aug 2014 15:59:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E04C0950Cpodcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/AwXVYy9G7JRTs6hp5R1-a5BmZoQ Subject: Re: [lmap] RSVP List for LMAP Interim Meeting - Deadline September 2nd 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, 28 Aug 2014 15:59:26 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04C0950Cpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles Cook should be there... you may want to add him. :) Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Tuesday, August 26, 2014 9:21 AM To: lmap@ietf.org Subject: [lmap] RSVP List for LMAP Interim Meeting - Deadline September 2nd LMAP WG, Below is the current current RSVP list for the LMAP Interim meeting on Sept= ember 15th in Dublin, Ireland. If you have sent an RSVP and I don't have yo= u on this list please let know. For others thinking of attending, this is a= reminder that the registration deadline is September 2nd. We have room for= 30 in the session so if you are able to attend we have room and would appr= eciate your input. 1. Jason Weil 2. Stephen Farrell (Maybe) 3. Marcelo Bagnulo Braun 4. Ken Ko 5. Philip Eardley 6. Timothy Carey 7. Juergen Schoenwaelder 8. Valibhav Bajpai Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04C0950Cpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charles Cook should be th= ere…   you may want to add him.

 <= /p>

J

 <= /p>

Thanks,=

Mike

 <= /p>

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason
Sent: Tuesday, August 26, 2014 9:21 AM
To: lmap@ietf.org
Subject: [lmap] RSVP List for LMAP Interim Meeting - Deadline Septem= ber 2nd

 

LMAP WG,<= /p>

 

Below is the current curren= t RSVP list for the LMAP Interim meeting on September 15th in Dublin, Irela= nd. If you have sent an RSVP and I don’t have you on this list please let know. For others thinking of attending, this is a reminder= that the registration deadline is September 2nd. We have room for 30 in th= e session so if you are able to attend we have room and would appreciate yo= ur input. 

  1. Jason Weil
  2. Stephen Farrell (Maybe)
  3. Marcelo Bagnulo Braun
  4. Ken Ko
  5. Philip Eardley
  6. Timothy Carey
  7. Juergen Schoenwaelder
  8. Valibhav Bajpai

Thanks,

 

Jason

 

This E-mail and any of its atta= chments may contain Time Warner Cable proprietary information, which is pri= vileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the in= dividual or entity to which it is addressed. If you are not the intended re= cipient of this E-mail, you are hereby notified that any dissemination, dis= tribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly = prohibited and may be unlawful. If you have received this E-mail in error, = please notify the sender immediately and permanently delete the original an= d any copy of this E-mail and any printout.

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E04C0950Cpodcwmbxex505ct_-- From nobody Thu Aug 28 20:36:47 2014 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 D3BAE1A01F7 for ; Thu, 28 Aug 2014 20:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.354 X-Spam-Level: * X-Spam-Status: No, score=1.354 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, 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 dx1rk18s--26 for ; Thu, 28 Aug 2014 20:36:43 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 463FF1A01E4 for ; Thu, 28 Aug 2014 20:36:42 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee453fff54440c-0a52e; Fri, 29 Aug 2014 11:36:36 +0800 (CST) X-RM-TRANSID: 2ee453fff54440c-0a52e X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.43.17]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee953fff5409ed-aea0f; Fri, 29 Aug 2014 11:36:36 +0800 (CST) X-RM-TRANSID: 2ee953fff5409ed-aea0f From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: , , , References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> Date: Fri, 29 Aug 2014 11:36:37 +0800 Message-ID: <003b01cfc33a$704d7e40$50e87ac0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CFC37D.7E70BE40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/BQujDjG1RKhmLRGOmCs5EZkqp/AB8qeOA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/763QhCZ0cS6xIu_sFcX4mZmohmI Cc: "'Romascanu, Dan \(Dan\)'" , lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 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: Fri, 29 Aug 2014 03:36:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003C_01CFC37D.7E70BE40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Authors, =20 I read the document and would like to see the following issue be = clarified. =20 The current design seems to be like this: 1, The information exchange between the controller and MA are organized = as =E2=80=9Cschedules=E2=80=9D, which contains a name, possibly multiple = task configurations, and a single timing. 2, For a measurement task to an MA, its task configuration description = and result report description is separated as two = =E2=80=9Crelated=E2=80=9D task configurations within a same schedule. =20 It is therefore, not clear to me that if there is a chance of specifying a different schedule timing for the = reporting from its corresponding measurement. =20 Lingli =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan) Sent: Tuesday, August 26, 2014 11:32 PM To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 =20 This message opens a Working Group Last Call for the = draft-ietf-lmap-information-model-02 = = Internet-Draft. =20 Please read and send comments about this document to the LMAP WG list = before Wednesday September 9, 2014.=20 =20 If you read the document and believe that it=E2=80=99s ready to be = submitted to the IESG for consideration as Proposed standards, please = state this in a short message to the list.=20 =20 The document is available at = http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt.=20 =20 Thanks and Regards, =20 Jason and Dan =20 =20 ------=_NextPart_000_003C_01CFC37D.7E70BE40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear = Authors,

 

I read the document and would = like to see the following issue be clarified.

 

The current design seems to be = like this:

1, The information exchange = between the controller and MA are organized as = =E2=80=9Cschedules=E2=80=9D, which contains a name, possibly multiple = task configurations, and a single timing.

2, For a measurement task to an = MA, its task configuration description and result report description is = separated as two =E2=80=9Crelated=E2=80=9D task configurations within a = same schedule.

 

It is therefore, not clear to = me that if

there is a chance of specifying = a different schedule timing for the reporting from its corresponding = measurement.

 

Lingli

 

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Tuesday, August 26, 2014 11:32 PM
To: = lmap@ietf.org
Subject: [lmap] WGLC for = draft-ietf-lmap-information-model-02

 

This message opens a Working Group = Last Call for the draft-ietf-lmap-information-model-02 = Internet-Draft.

 

Please read and = send comments about this document to the LMAP WG list before Wednesday = September 9, 2014.

 

If you read the document and believe that it=E2=80=99s = ready to be submitted to the IESG for consideration as Proposed = standards, please state this in a short message to the list. =

 

The document is available at = http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. =

 

Thanks and Regards,

 

Jason and = Dan

 

 

------=_NextPart_000_003C_01CFC37D.7E70BE40-- From nobody Thu Aug 28 20:42:10 2014 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 9268A1A02DD for ; Thu, 28 Aug 2014 20:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, 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 v2qYQY3nO_lE for ; Thu, 28 Aug 2014 20:42:07 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 879741A0267 for ; Thu, 28 Aug 2014 20:42:06 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee953fff68c93e-0aa58; Fri, 29 Aug 2014 11:42:05 +0800 (CST) X-RM-TRANSID: 2ee953fff68c93e-0aa58 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.43.17]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee653fff68baa2-aeabc; Fri, 29 Aug 2014 11:42:05 +0800 (CST) X-RM-TRANSID: 2ee653fff68baa2-aeabc From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'Liu,Shu@CATR'" , References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> <002c01cfc2c4$fbd91440$f38b3cc0$@cn> In-Reply-To: <002c01cfc2c4$fbd91440$f38b3cc0$@cn> Date: Fri, 29 Aug 2014 11:42:06 +0800 Message-ID: <004c01cfc33b$345d99f0$9d18cdd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFgABaVdwAAMEkT0AAGrpQQAB2NzNA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/q_PVTQSiVLuN7C5gV-NoilCVVgU Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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: Fri, 29 Aug 2014 03:42:08 -0000 I echo Vaibhav in removing the JSON blocks from this document, for they = are neither required to understand the text nor helping with the call. Lingli > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Liu,Shu@CATR > Sent: Thursday, August 28, 2014 9:36 PM > To: lmap@ietf.org > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > (corrected date) >=20 > I couldn't agree more. >=20 > Andy >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, August 28, 2014 6:25 PM > To: Bajpai, Vaibhav; > Cc: Liu,Shu@CATR > Subject: RE: [lmap] WGLC for draft-ietf-lmap-information-model-02 > (corrected date) >=20 > Hi, >=20 > If we decide to keep them, the examples should be as clean = syntactically > as we can make them. (even if included in an appendix) >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Bajpai, Vaibhav [mailto:v.bajpai@jacobs-university.de] > > Sent: Wednesday, August 27, 2014 4:21 PM > > To: > > Cc: Bajpai, Vaibhav; Romascanu, Dan (Dan); Liu,Shu@CATR > > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > > (corrected date) > > > > ** LMAP > > > > > On 27 Aug 2014, at 02:36, Liu,Shu@CATR wrote: > > > > > > The JSON blocks have a lot of syntax errors, I sent the parsable > > > blocks to Trevor, since the list did not allow me to post it. > > > > AFAIK, the JSON example is in the appendix for a reason. It is only > > meant to provide a _hint_ on how to translate the abstract objects > > into a concrete data model. As such, the example should not be used = by > > implementations anyway. > > > > In order to avoid digressing ourselves into the JSON example, I > > propose to remove the JSON fragments from this document. > > > > Best, Vaibhav > > > > ----------------------------------------------------- > > Vaibhav Bajpai > > > > Research I, Room 91 > > Computer Networks and Distributed Systems (CNDS) Lab School of > > Engineering and Sciences Jacobs University Bremen, Germany > > > > www.vaibhavbajpai.com >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Aug 29 01:17:24 2014 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 0181B1A06A5 for ; Fri, 29 Aug 2014 01:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 Zk_-nSXb_2bU for ; Fri, 29 Aug 2014 01:17:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709181A06A4 for ; Fri, 29 Aug 2014 01:17:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3F66A133B; Fri, 29 Aug 2014 10:17:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RntFsDyPotUz; Fri, 29 Aug 2014 10:17:19 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Aug 2014 10:17:19 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E0AC20035; Fri, 29 Aug 2014 10:17:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qyH5bOPdt583; Fri, 29 Aug 2014 10:17:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1BB420033; Fri, 29 Aug 2014 10:17:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A4262E53187; Fri, 29 Aug 2014 10:17:15 +0200 (CEST) Date: Fri, 29 Aug 2014 10:17:14 +0200 From: Juergen Schoenwaelder To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaQ==?= Deng Message-ID: <20140829081714.GB63622@elstar.local> Mail-Followup-To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaQ==?= Deng , trevor.burbridge@bt.com, philip.eardley@bt.com, marcelo@it.uc3m.es, "'Romascanu, Dan (Dan)'" , lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <003b01cfc33a$704d7e40$50e87ac0$@com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/v6OzoSRpxGXPT52uAF9CtkYvfwU Cc: marcelo@it.uc3m.es, "'Romascanu, Dan \(Dan\)'" , trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 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: Fri, 29 Aug 2014 08:17:23 -0000 On Fri, Aug 29, 2014 at 11:36:37AM +0800, 邓灵莉/Lingli Deng wrote: > Dear Authors, > > I read the document and would like to see the following issue be clarified. > > The current design seems to be like this: > > 1, The information exchange between the controller and MA are organized as “schedules”, which contains a name, possibly multiple task configurations, and a single timing. > > 2, For a measurement task to an MA, its task configuration description and result report description is separated as two “related” task configurations within a same schedule. > > It is therefore, not clear to me that if > > there is a chance of specifying a different schedule timing for the reporting from its corresponding measurement. > In the information model, everything is a task. Some tasks are measurement tasks and some tasks are reporting tasks. All tasks are driven by a schedule and of course different tasks can have different schedules. In other words, schedule A can trigger a measurement tasks. The results produced are handed over to a reporting task. Schedule B triggers the reporting task and thus the transmission of results to a collector. As such, report scheduling is independent from measurement task scheduling. /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 Aug 29 03:27:18 2014 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 BDDD41A0070 for ; Fri, 29 Aug 2014 03:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, 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 Asf_z73IeXqs for ; Fri, 29 Aug 2014 03:27:14 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 246671A0068 for ; Fri, 29 Aug 2014 03:27:13 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee35400557a758-1588f; Fri, 29 Aug 2014 18:27:06 +0800 (CST) X-RM-TRANSID: 2ee35400557a758-1588f X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.43.17]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee754005579199-b11d1; Fri, 29 Aug 2014 18:27:06 +0800 (CST) X-RM-TRANSID: 2ee754005579199-b11d1 From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'Juergen Schoenwaelder'" References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> In-Reply-To: <20140829081714.GB63622@elstar.local> Date: Fri, 29 Aug 2014 18:27:07 +0800 Message-ID: <00f701cfc373$c91cffd0$5b56ff70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/DYaqwRXAtUWlGSQuVZmOVEAz23QADK9ew Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/N-72_cldTAGkDzjTpU-QXqOQ47o Cc: marcelo@it.uc3m.es, "'Romascanu, Dan \(Dan\)'" , trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 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: Fri, 29 Aug 2014 10:27:16 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Friday, August 29, 2014 4:17 PM > To: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng > Cc: marcelo@it.uc3m.es; 'Romascanu, Dan (Dan)'; > trevor.burbridge@bt.com; philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 >=20 > On Fri, Aug 29, 2014 at 11:36:37AM +0800, = =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote: > > Dear Authors, > > > > I read the document and would like to see the following issue be > clarified. > > > > The current design seems to be like this: > > > > 1, The information exchange between the controller and MA are > organized as =E2=80=9Cschedules=E2=80=9D, which contains a name, = possibly multiple task > configurations, and a single timing. > > > > 2, For a measurement task to an MA, its task configuration = description > and result report description is separated as two = =E2=80=9Crelated=E2=80=9D task > configurations within a same schedule. > > > > It is therefore, not clear to me that if > > > > there is a chance of specifying a different schedule timing for the > reporting from its corresponding measurement. > > >=20 > In the information model, everything is a task. Some tasks are > measurement tasks and some tasks are reporting tasks. All tasks are > driven by a schedule and of course different tasks can have different > schedules. In other words, schedule A can trigger a measurement tasks. > The results produced are handed over to a reporting task. Schedule B > triggers the reporting task and thus the transmission of results to a > collector. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Point taken. So the schedule = for the measurement task, even the one contained a reporting task = description (as one of the downstream task) is not intended to set = schedule for the reporting task., right? What about a measurement task that requires instant reporting after each = round? Does one still need another independent schedule for the = reporting task? >=20 > As such, report scheduling is independent from measurement task > scheduling. >=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 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Aug 29 11:42:16 2014 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 737891A0A94 for ; Fri, 29 Aug 2014 11:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.268 X-Spam-Level: ** X-Spam-Status: No, score=2.268 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 X2QtrdvlxUrg for ; Fri, 29 Aug 2014 11:42:11 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8231A0AD4 for ; Fri, 29 Aug 2014 11:42:10 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,425,1406606400"; d="scan'208,217";a="489966673" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Aug 2014 14:41:03 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 29 Aug 2014 14:41:57 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Fri, 29 Aug 2014 14:42:07 -0400 Thread-Topic: Draft LMAP Interim Meeting Agenda Thread-Index: Ac/DuPB/cJwVvGXKRq6K+QGBlUJftQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D02641BF33A0Ejasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WYdP-x4waQ4kKUuukEi23X-WrXA Subject: [lmap] Draft LMAP Interim Meeting Agenda 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: Fri, 29 Aug 2014 18:42:12 -0000 --_000_D02641BF33A0Ejasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable LMAP WG Interim Meeting Date and Time: Monday, September 15, 2014, 0230-1830 IST 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 min) 2. WG Status - Chairs (5 min) 3. Use Cases Discussion =96 Respond to AD Comments (tentative) - 15 min 4. LMAP Information Model =96 Address LC Comments =96 TBD =96 30 min 5. Protocol Discussion =96 105 min YANG Model =96 Arne O. - 15min HTTP Style Protocol - ? - 15min REST Style Protocols - ? - 15 min Protocol Discussion - ? - 60 min 6. Next steps and open mic If there is time remaining (it looks like there will be) we can insert a di= scussion on the Registry. Please send additional requests for time slots if= needed. I will be reaching out to authors of the Protocol drafts and the F= ramework for topics during the Protocol Discussion Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D02641BF33A0Ejasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
LMAP WG Interim Meet=
ing
Date and Time: Monday, September 15, 2014, 0230-1830 IST
         =20
         =20

1. Note Well, Note Takers, Jabber Scribes, Agenda =
Bashing - Chairs (5 min)
         =20
2. WG Status - Chairs (5 min)
         =20
3. Use Cases Discussion =96 Respond to AD Comments (tent=
ative) - 15 min
         =20
4. LMAP Information Model =96 Address LC Comments =96 TB=
D =96 30 min
         =20
5. Protocol Discussion =96 105 min 
	YANG Model =96 Arne O. - 15min
	HTTP Style Protocol  - ? - 15min 
	REST Style Protocols -  ? - 15 min
	Protocol Discussion - ?   - 60 min
6. Nex=
t steps and open mic

If there =
is time remaining (it looks like there will be) we can insert a discussion =
on the Registry. Please send additional requests for time slots if needed. =
I will be reaching out to authors of the Protocol drafts and the Framework =
for topics during the Protocol Discussion
Thanks,
Jason

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D02641BF33A0Ejasonweiltwcablecom_-- From nobody Sun Aug 31 03:29:17 2014 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 23AA41A8916 for ; Sun, 31 Aug 2014 03:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 o9tjxwEiYi6C for ; Sun, 31 Aug 2014 03:29:13 -0700 (PDT) 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 16AAF1A88FF for ; Sun, 31 Aug 2014 03:29:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0LAAj4AlSHCzIm/2dsb2JhbABagmojIDNXBIJ4rA2YPRwKh0wBGXIWd4QDAQEBAQMSCwYRUQYBCA0EBAEBAwIGCxIDAgQwFAEGAQEFBAEEEwgMDoggAQyVc4RlikqURAEXgSyEUIYigk0RAR8+BIIuDzISJIEdBZExhC6COoYehgWENYkJg2FsgQ85gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,436,1406606400"; d="scan'208";a="80494578" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Aug 2014 06:29:11 -0400 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; 31 Aug 2014 06:29:11 -0400 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; Sun, 31 Aug 2014 12:29:10 +0200 From: "Romascanu, Dan (Dan)" To: "" Thread-Topic: NOMCOM 2014 - Call for Nominations Thread-Index: Ac/FBmRjehsSViQNTaCV/O0TUpTz6g== Date: Sun, 31 Aug 2014 10:29:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C882ADB@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.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3ShbtLiBa6M10pQaexLg7j-AcRA Subject: [lmap] FW: NOMCOM 2014 - Call for Nominations 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, 31 Aug 2014 10:29:15 -0000 U2VlIHRoZSBtZXNzYWdlIGZyb20gdGhlIE5PTUNPTSBjaGFpci4gUGxlYXNlIG5vbWluYXRlIHRo ZSBiZXN0IGNhbmRpZGF0ZXMsIGluY2x1ZGluZyB5b3Vyc2VsZiwgZm9yIHRoZSBvcGVuIHBvc2l0 aW9ucyBpbiB0aGUgSUFPQywgSUFCLCBhbmQgSUVTRy4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJRVRGLUFu bm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gTm9tQ29tIENoYWlyIDIwMTQNCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMjksIDIwMTQg NzoxMiBQTQ0KPiBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KPiBDYzogaWV0ZkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBOT01DT00gMjAxNCAtIENhbGwgZm9yIE5vbWluYXRpb25zDQo+IA0KPiBU aGUgMjAxNC0xNSBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29tKSBpcyBzZWVraW5nIG5vbWlu YXRpb25zIGZyb20NCj4gbm93IHVudGlsIE9jdG9iZXIgMTEsIDIwMTQuIFRoZSBvcGVuIHBvc2l0 aW9ucyBiZWluZyBjb25zaWRlcmVkIGJ5IHRoaXMNCj4geWVhcidzIE5vbWNvbSBjYW4gYmUgZm91 bmQgYXQgdGhlIGVuZCBvZiB0aGlzIGVtYWlsIGFuZCBhbHNvIG9uIHRoaXMgeWVhcidzDQo+IE5v bWNvbSB3ZWJzaXRlOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20v MjAxNC8NCj4gDQo+IE5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9t aW5hdGUgbGluayBhdCB0aGUgdG9wIG9mIHRoZQ0KPiBOb21jb20gMjAxNCBob21lIHBhZ2UsIG9y IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9ub21jb20vMjAxNC9ub21pbmF0ZS8NCj4gDQo+ICAge05vdGUgdGhhdCBub21p bmF0aW9ucyBtYWRlIHVzaW5nIHRoZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnDQo+ICAg IGRhdGF0cmFja2VyIGFjY291bnQuIFlvdSBjYW4gY3JlYXRlIGEgZGF0YXRyYWNrZXIgaWV0Zi5v cmcgYWNjb3VudA0KPiAgICBpZiB5b3UgZG9uJ3QgaGF2ZSBvbmUgYWxyZWFkeSBieSB2aXNpdGlu ZyB0aGUgZm9sbG93aW5nIFVSTDoNCj4gICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9hY2NvdW50cy9jcmVhdGUvIH0NCj4gDQo+IE5vbWluYXRpb25zIG1heSBhbHNvIGJlIG1hZGUg YnkgZW1haWwgdG8gbm9tY29tMTNAaWV0Zi5vcmcuDQo+IElmIHVzZSBlbWFpbCwgcGxlYXNlIGlu Y2x1ZGUgdGhlIHdvcmQgIk5vbWluYXRlIiBpbiB0aGUgU3ViamVjdCBhbmQgaW5kaWNhdGUNCj4g aW4gdGhlIGVtYWlsIHdobyBpcyBiZWluZyBub21pbmF0ZWQsIHRoZWlyIGVtYWlsIGFkZHJlc3Mg KHRvIGNvbmZpcm0NCj4gYWNjZXB0YW5jZSBvZiB0aGUgbm9taW5hdGlvbiksIGFuZCB0aGUgcG9z aXRpb24gZm9yIHdoaWNoIHlvdSBhcmUgbWFraW5nDQo+IHRoZSBub21pbmF0aW9uLiBJZiB5b3Ug d2lzaCB0byBub21pbmF0ZSBzb21lb25lIHZpYSBlbWFpbCBmb3IgbW9yZSB0aGFuDQo+IG9uZSBw b3NpdGlvbiwgcGxlYXNlIHVzZSBzZXBhcmF0ZSBlbWFpbHMgdG8gZG8gc28uDQo+IA0KPiBTZWxm LW5vbWluYXRpb24gaXMgd2VsY29tZSENCj4gDQo+IE5vbUNvbSAyMDE0LTE1IHdpbGwgZm9sbG93 IHRoZSBwb2xpY3kgZm9yICJPcGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KPiBOb21pbmVlcyIg ZGVzY3JpYmVkIGluIFJGQyA1NjgwLiAgQXMgc3RhdGVkIGluIFJGQyA1NjgwOiAiVGhlIGxpc3Qg b2YNCj4gbm9taW5lZXMgd2lsbGluZyB0byBiZSBjb25zaWRlcmVkIGZvciBwb3NpdGlvbnMgdW5k ZXIgcmV2aWV3IGluIHRoZSBjdXJyZW50DQo+IE5vbWNvbSBjeWNsZSBpcyBub3QgY29uZmlkZW50 aWFsIi4gV2lsbGluZyBub21pbmVlcyBmb3IgZWFjaCBwb3NpdGlvbiB3aWxsIGJlDQo+IGxpc3Rl ZCBpbiBhIHB1YmxpY2x5IGFjY2Vzc2libGUgd2F5IC0gYW55b25lIHdpdGggYSBkYXRhdHJhY2tl ciBhY2NvdW50IG1heQ0KPiBhY2Nlc3MgdGhlIGxpc3RzLiAgSW4gYWxsIG90aGVyIHdheXMsIHRo ZSBjb25maWRlbnRpYWxpdHkgcmVxdWlyZW1lbnRzIG9mIFJGQw0KPiAzNzc3L0JDUDEwIHJlbWFp biBpbiBlZmZlY3QuICBBbGwgZmVlZGJhY2sgYW5kIGFsbCBOb21jb20gZGVsaWJlcmF0aW9ucyB3 aWxsDQo+IHJlbWFpbiBjb25maWRlbnRpYWwgYW5kIHdpbGwgbm90IGJlIGRpc2Nsb3NlZC4NCj4g DQo+IEluIG9yZGVyIHRvIGVuc3VyZSB0aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVudCBjb21tdW5p dHkgZmVlZGJhY2sgYWJvdXQgZWFjaA0KPiBvZiB0aGUgd2lsbGluZyBub21pbmVlcywgbm9taW5h dGlvbnMgbXVzdCBiZSByZWNlaXZlZCBieSB0aGUgTm9tY29tIG9uIG9yDQo+IGJlZm9yZSBPY3Rv YmVyIDExLCAyMDEzLg0KPiANCj4gUGxlYXNlIHN1Ym1pdCB5b3VyIG5vbWluYXRpb25zIGFzIGVh cmx5IGFzIHBvc3NpYmxlIGZvciB0aGUgc2FrZSBvZiB5b3VyDQo+IG5vbWluZWVzLiBOb3RlIHRo YXQgbm9taW5hdGlvbnMgc2hvdWxkIG5vdCB3YWl0IGZvciBtYW5hZ2VtZW50DQo+IHBlcm1pc3Np b24sIGFzIGl0IGlzIGVhc2llciB0byBkZWNsaW5lIHRoZSBub21pbmF0aW9uLCB0aGFuIHB1dCBv bmUgaW4gbGF0ZS4NCj4gV2UndmUgc2V0IHRoZSBxdWVzdGlvbm5haXJlIHN1Ym1pc3Npb24gZGVh ZGxpbmUgZm9yIE9jdG9iZXIgMjUsIDIwMTQuDQo+IA0KPiBUaGUgTm9tY29tIGFwcG9pbnRzIGlu ZGl2aWR1YWxzIHRvIGZpbGwgdGhlIG9wZW4gc2xvdHMgb24gdGhlIElBT0MsIHRoZSBJQUIsDQo+ IGFuZCB0aGUgSUVTRy4gVGhlIGxpc3Qgb2YgcGVvcGxlIGFuZCBwb3N0cyB3aG9zZSB0ZXJtcyBl bmQgd2l0aCB0aGUgTWFyY2gNCj4gMjAxNCBJRVRGIG1lZXRpbmcsIGFuZCB0aHVzIHRoZSBwb3Np dGlvbnMgZm9yIHdoaWNoIHRoaXMgTm9tY29tIGlzDQo+IHJlc3BvbnNpYmxlLCBmb2xsb3dzOg0K PiANCj4gSUFPQzoNCj4gUmFuZHkgQnVzaA0KPiANCj4gSUFCOg0KPiBKb2VsIEhhbHBlcm4NCj4g UnVzcyBIb3VzbGV5DQo+IEVsaW90IExlYXINCj4gWGluZyBMaQ0KPiBBbmRyZXcgU3VsbGl2YW4N Cj4gRGF2ZSBUaGFsZXINCj4gDQo+IElFU0c6DQo+IFBldGUgUmVzbmljayAoQXBwbGljYXRpb25z KQ0KPiBUZWQgTGVtb24gKEludGVybmV0KQ0KPiBKb2VsIEphZWdnbGkgKE9wZXJhdGlvbnMgYW5k IE1hbmFnZW1lbnQpIFJpY2hhcmQgQmFybmVzIChSQUkpIEFkcmlhbg0KPiBGYXJyZWwqIChSb3V0 aW5nKSBTdGVwaGVuIEZhcnJlbGwgKFNlY3VyaXR5KSBTcGVuY2VyIERhd2tpbnMgKFRyYW5zcG9y dCkgSmFyaQ0KPiBBcmtrbyAoR2VuKQ0KPiANCj4gKi0ga25vd24gdG8gaGF2ZSBkZWNsaW5lIHRv IHJ1biBhZ2Fpbi4NCj4gDQo+IFBsZWFzZSBiZSByZXNvdXJjZWZ1bCBpbiBpZGVudGlmeWluZyBw b3NzaWJsZSBjYW5kaWRhdGVzIGZvciB0aGVzZSBwb3NpdGlvbnMsDQo+IGFzIGRldmVsb3Bpbmcg b3VyIHRhbGVudCBpcyBhIHZlcnkgY3J1Y2lhbCByZXF1aXJlbWVudCBmb3IgdGhlIElFVEYsIGFu ZCBhbHNvLA0KPiBwbGVhc2UgY29uc2lkZXIgYWNjZXB0aW5nIGEgbm9taW5hdGlvbi4gIFlvdSds bCBmaW5kIGV4dGVuc2l2ZSBpbmZvcm1hdGlvbg0KPiBhYm91dCBzcGVjaWZpYyBwb3NpdGlvbnMs IGRldmVsb3BlZCBieSB0aGUgSUFCLCBJRVNHLCBhbmQgSUFPQywgdW5kZXINCj4gaW5kaXZpZHVh bCB0YWJzIGF0Og0KPiANCj4gICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8y MDE0L3JlcXVpcmVtZW50cy8NCj4gDQo+IEluIGFkZGl0aW9uIHRvIG5vbWluYXRpb25zLCB0aGUg Tm9tY29tIHNlZWtzIGNvbW11bml0eSBpbnB1dCBvbiB0aGUNCj4gcG9zaXRpb25zIHRoZW1zZWx2 ZXMuICBXZSBuZWVkIGFuZCB3ZWxjb21lIHRoZSBjb21tdW5pdHkncyB2aWV3cyBhbmQNCj4gaW5w dXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UgaGF2ZSBpZGVh cyBvbiB0aGUgcG9zaXRpb25zJw0KPiByZXNwb25zaWJpbGl0aWVzIChtb3JlLCBsZXNzLCBkaWZm ZXJlbnQpLCBwbGVhc2UgbGV0IHVzIGtub3cuDQo+IA0KPiBQbGVhc2Ugc2VuZCBzdWdnZXN0aW9u cyBhbmQgZmVlZGJhY2sgYWJvdXQgdGhpcyB0byBub21jb20xNEBpZXRmLm9yZy4NCj4gDQo+IFRo YW5rIHlvdSBmb3IgeW91ciBoZWxwIGluIGlkZW50aWZ5aW5nIHF1YWxpZmllZCBub21pbmVlcyEN Cj4gDQo+IE1pY2hhZWwgUmljaGFyZHNvbg0KPiBOb21jb20gQ2hhaXIgMjAxNC0xNQ0KPiBub21j b20tY2hhaXItMjAxNEBpZXRmLm9yZywgbWNyK25vbWNvbUBzYW5kZWxtYW4uY2ENCg0K