From nobody Fri Mar 10 08:14:22 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A9129661; Fri, 10 Mar 2017 08:14:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916245108.6933.7329149063119506579.idtracker@ietfa.amsl.com> Date: Fri, 10 Mar 2017 08:14:11 -0800 Archived-At: Cc: dromasca@gmail.com, lmap-chairs@ietf.org, draft-ietf-lmap-information-model@ietf.org, lmap@ietf.org Subject: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-lmap-information-model-17=3A_=28with_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:14:11 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lmap-information-model-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is this document Standards Track? I think it should be informational! Minor comments/questions: - It's not really explained what tags are (see ma-report-result-tags) ? And what's the differents to options (ma-report-result-options)? - Is it correct that an ma-report-table-obj can cover multiple ma-report-table-functions? Examples would be good here! - Sec 3.7.: "There is no mechanism to prioritise one schedule over another or to mutex scheduled tasks." Why is that? Was this discussed? I would guess that would be important to have! - Wouldn't it makes sense to discuss the common objects first? - The regristry concept is rather unclear to me as it suddently shows up in section 3.10. Especially what's a role in this context (ma-registry-role)? Example? From nobody Fri Mar 10 08:47:11 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A93C212940A; Fri, 10 Mar 2017 08:47:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> Date: Fri, 10 Mar 2017 08:47:09 -0800 Archived-At: Cc: dromasca@gmail.com, lmap-chairs@ietf.org, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Subject: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-l?= =?utf-8?q?map-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:47:09 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lmap-yang-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This draft does not specify a bootstrapping process (see RFC 7594 5.1. Bootstrapping Process) and says: "Pre-Configuration Information: This is not modeled explicitly since bootstrapping information is outside the scope of this data model." So when and where and how will this be specified? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Also it is not clear when and how to perform configuration actions. To be a fully function protocol more guidance is needed. Not sure if that is even the intention of this document but I don't see any other documents that serves this purpose in the lmap queue. (And the milesstones are not up to date and don't indicate with document maps to which milestone.) From nobody Sun Mar 12 07:25:14 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FF129A9B; Sun, 12 Mar 2017 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-RyG-b1BrzW; Sun, 12 Mar 2017 07:25:07 -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 622D01294A2; Sun, 12 Mar 2017 07:25:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2E9D17B3; Sun, 12 Mar 2017 15:25:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1PIAAUITZAQX; Sun, 12 Mar 2017 15:25:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 12 Mar 2017 15:25:02 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2BB520038; Sun, 12 Mar 2017 15:25:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7oxM5Q7utsAI; Sun, 12 Mar 2017 15:25:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F204320036; Sun, 12 Mar 2017 15:25:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 881DD3EB7610; Sun, 12 Mar 2017 15:25:04 +0100 (CET) Date: Sun, 12 Mar 2017 15:25:04 +0100 From: Juergen Schoenwaelder To: Mirja =?iso-8859-1?Q?K=FChlewind?= Message-ID: <20170312142504.GA50980@elstar.local> Mail-Followup-To: Mirja =?iso-8859-1?Q?K=FChlewind?= , The IESG , draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148916245108.6933.7329149063119506579.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <148916245108.6933.7329149063119506579.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-information-model@ietf.org, lmap@ietf.org Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-lmap-information-model-17=3A_=28with_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 14:25:09 -0000 On Fri, Mar 10, 2017 at 08:14:11AM -0800, Mirja Kühlewind wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Why is this document Standards Track? I think it should be > informational! Because this is what the charter says. Jul 2014 - Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC There are two data models implementing this information model, IETF's YANG data model and BBF's data model. Does this qualify for standards track? I don't know. > Minor comments/questions: > - It's not really explained what tags are (see ma-report-result-tags) ? > And what's the differents to options (ma-report-result-options)? Options are passed to tasks, tags are not. > - Is it correct that an ma-report-table-obj can cover multiple > ma-report-table-functions? Examples would be good here! Yes. A measurement task may send a packet train that allows to derives different metrics (aka functions). > - Sec 3.7.: "There is no mechanism to prioritise one schedule over > another or to mutex scheduled tasks." > Why is that? Was this discussed? I would guess that would be important > to have! Why would this be important to have? I am familiar with at least one bigger measurement infrastructure that does not have this. Note that you can gate things via tasks, i.e., you setup sequential schedules and if some gating is needed your first task in the schedule takes care of the gating logic. > - Wouldn't it makes sense to discuss the common objects first? I think this is a stylistic question. Some like to read top-down, some like to read bottom-up. The structure has been top-down since the early days of the document and so far nobody reported an issue with that. > - The regristry concept is rather unclear to me as it suddently shows up > in section 3.10. Especially what's a role in this context > (ma-registry-role)? Example? The registry is mentioned a couple of times before section 3.10. See in particular the 2nd paragraph in section 3.9. /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 Mar 13 14:09:08 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF3812942F; Mon, 13 Mar 2017 14:09:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943934250.20338.17609730068139281956.idtracker@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:09:02 -0700 Archived-At: Cc: dromasca@gmail.com, lmap-chairs@ietf.org, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Subject: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:09:02 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-yang-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The security considerations looks good, but can't YANG also be accessed via RESTCONF? What considerations are needed for that? I thunk we went through this for I2RS, do considerations for RESTCONF apply to this YANG module? From nobody Mon Mar 13 14:18:46 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F463129BAB; Mon, 13 Mar 2017 14:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCOl_Jc9ubzS; Mon, 13 Mar 2017 14:18:40 -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 946C7129B7D; Mon, 13 Mar 2017 14:18:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 67929735; Mon, 13 Mar 2017 22:18:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6hlVT90499cB; Mon, 13 Mar 2017 22:18:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 13 Mar 2017 22:18:31 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21A9B2003C; Mon, 13 Mar 2017 22:18:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xLhHk-gZXgoU; Mon, 13 Mar 2017 22:18:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C115E2003B; Mon, 13 Mar 2017 22:18:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7C8C43EBA82B; Mon, 13 Mar 2017 22:18:35 +0100 (CET) Date: Mon, 13 Mar 2017 22:18:35 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Message-ID: <20170313211835.GA53972@elstar.local> Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148943934250.20338.17609730068139281956.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148943934250.20338.17609730068139281956.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Subject: Re: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:18:42 -0000 On Mon, Mar 13, 2017 at 02:09:02PM -0700, Kathleen Moriarty wrote: > > The security considerations looks good, but can't YANG also be accessed > via RESTCONF? What considerations are needed for that? I thunk we went > through this for I2RS, do considerations for RESTCONF apply to this YANG > module? > Yes, the document is using the old template. Looking at draft-ietf-netmod-rfc6087bis-12.txt (posted March 5th) and https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines I do not see a new template either. I think I recall having seen some discussion somewhere (probably related to I2RS) but then I do not see new text in draft-ietf-i2rs-yang-network-topo-12.txt. While I can make up my own text, I think I prefer following a new template. Benoit? /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 Mar 14 01:53:12 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0351C1294C3; Tue, 14 Mar 2017 01:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad6yHz-xtaS7; Tue, 14 Mar 2017 01:53:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF96126CD8; Tue, 14 Mar 2017 01:53:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A0EA27D4; Tue, 14 Mar 2017 09:53:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RZtkjCIBmeTl; Tue, 14 Mar 2017 09:53:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Mar 2017 09:53:06 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DAB92003D; Tue, 14 Mar 2017 09:53:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o9pkS3D55_bm; Tue, 14 Mar 2017 09:53:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B0F52003C; Tue, 14 Mar 2017 09:53:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B98803EBBBB2; Tue, 14 Mar 2017 09:53:09 +0100 (CET) Date: Tue, 14 Mar 2017 09:53:09 +0100 From: Juergen Schoenwaelder To: Russ Housley Message-ID: <20170314085308.GA54939@elstar.local> Mail-Followup-To: Russ Housley , gen-art@ietf.org, lmap@ietf.org, ietf@ietf.org, draft-ietf-lmap-information-model.all@ietf.org References: <148814339074.2901.10793232146724828053.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148814339074.2901.10793232146724828053.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: gen-art@ietf.org, draft-ietf-lmap-information-model.all@ietf.org, ietf@ietf.org, lmap@ietf.org Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-17 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:53:11 -0000 Russ, thanks for your review. See my response to your comments inline. On Sun, Feb 26, 2017 at 01:09:50PM -0800, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > . > > Document: draft-ietf-lmap-information-model-17 > Reviewer: Russ Housley > Review Date: 2017-02-26 > IETF LC End Date: 2017-03-08 > IESG Telechat date: Unknown > > Summary: Ready > > Major Concerns: > > Section 3.1 says that the pre-configuration information contains > the certificate of the Controller or the certificate of the CA > which issued the certificate for the Controller. Section 3.1.1 > includes ma-preconfig-credentials. Are these the same? The information model on purse is somewhat unspecific about what exactly the security credentials are. The reason is that the information model maps to two data models today (one in the BBF and one in the IETF). The IETF data model can be accessed over NETCONF and RESTCONF. RESTCONF runs over HTTP/TLS while NETCONF by default runs over SSH. As a consequence, the various credentials needed to support the different protocols varies. > Section 6 says that secure communication channels are needed. This > means > that some components of this system (at least the Controller) must > have > secret keys or private keys. I think that Section 6 should talk > about > which components of this system have keys and the consequences if the > keys are not well protected. There is a fairly large discussion of security issues in RFC 7594 and we point to them in section 6 rather than repeating them here. An implementation of this Information Model should support all the security and privacy requirements associated with the LMAP Framework [RFC7594]. > Minor Concerns: > > The Introduction in RFC 7594 says: "There is a desire to be able > to coordinate the execution of broadband measurements and the > collection of measurement results across a large scale set of > Measurement Agents (MAs)." The Fact that LMAP is about broadband > measurements should be stated in the first paragraph of the > Introduction of this document. I suggest to add a sentence including a reference to RFC 7536 so that the 1st paragraph of the Introduction reads: A large-scale measurement platform is a collection of components that work in a coordinated fashion to perform measurements from a large number of vantage points. A typical use case is the execution of broadband measurements [RFC7536]. The main components of a large- scale measurement platform are the Measurement Agents (hereafter MAs), the Controller(s) and the Collector(s). > Nits: > > In Section 3, the reason for the 6 categories should probably be > placed before the list instead of several paragraphs later. I agree, I have moved the text up (and due to some other comment we started to call the categories 'aspects'). So the new text reads: The information model is divided into six aspects. Firstly the grouping of information facilitates reader understanding. Secondly, the particular groupings chosen are expected to map to different protocols or different transmissions within those protocols. > In 3.1: s/If the MA ID is not provided at this stage then/ > /If the MA ID is not provided at this stage, then/ fixed /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 Mar 14 02:06:59 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ED01294E0; Tue, 14 Mar 2017 02:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaUedOe50_3p; Tue, 14 Mar 2017 02:06:55 -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 A092F129529; Tue, 14 Mar 2017 02:06:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 70EED7A2; Tue, 14 Mar 2017 10:06:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id z-iSGeZNzNXe; Tue, 14 Mar 2017 10:06:46 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Mar 2017 10:06:47 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C2872003D; Tue, 14 Mar 2017 10:06:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lOHLe1D-q-Ha; Tue, 14 Mar 2017 10:06:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C1C020014; Tue, 14 Mar 2017 10:06:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BEBFB3EBBDAD; Tue, 14 Mar 2017 10:06:49 +0100 (CET) Date: Tue, 14 Mar 2017 10:06:49 +0100 From: Juergen Schoenwaelder To: Mirja =?iso-8859-1?Q?K=FChlewind?= Message-ID: <20170314090649.GB54939@elstar.local> Mail-Followup-To: Mirja =?iso-8859-1?Q?K=FChlewind?= , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf?= =?iso-8859-1?q?-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:06:58 -0000 On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja Kühlewind wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This draft does not specify a bootstrapping process (see RFC 7594 5.1. > Bootstrapping Process) and says: > "Pre-Configuration Information: This is not modeled explicitly since > bootstrapping information is outside the scope of this data model." > So when and where and how will this be specified? There is work ongoing in NETCONF to provide different pieces for bootstrapping. - draft-ietf-netconf-keystore a model for managing keys - draft-ietf-netconf-netconf-client-server a model for managing NETCONF client and server config - draft-ietf-netconf-restconf-client-server a model for managing RESTCONF client and server config - draft-ietf-netconf-ssh-client-server a model providing NETCONF over SSH config details - draft-ietf-netconf-tls-client-server a model providing NETCONF over TLS config details - draft-ietf-netconf-zerotouch a mechanism for loading bootstrapping information > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Also it is not clear when and how to perform configuration actions. To be > a fully function protocol more guidance is needed. Not sure if that is > even the intention of this document but I don't see any other documents > that serves this purpose in the lmap queue. (And the milesstones are not > up to date and don't indicate with document maps to which milestone.) When and how is up to the controller design. The fully functioning protocol falls out of the YANG data model - once you have YANG data model, you are ready to go. That said, there is a currently expired WG document providing more details. https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 The idea here was just provide an explanation how the LMAP data model works together with RESTCONF. /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 Mar 14 14:06:27 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E9813152F; Tue, 14 Mar 2017 14:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148952558616.24282.2041316603061231135.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 14:06:26 -0700 Archived-At: Subject: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-information-model-17: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:06:26 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-information-model-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the security considerations section, I see the following text: These mechanisms are important to ensure that the MA cannot be hijacked, for example to participate in a distributed denial of service attack. Wouldn't using the systems or the collected data for network recon (or other attacks) be a more important consideration to be listed than DDoS? From nobody Tue Mar 14 18:10:47 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D97BF1293DA; Tue, 14 Mar 2017 18:10:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148954024588.24379.14870049531992197958.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 18:10:45 -0700 Archived-At: Subject: [lmap] Ben Campbell's No Objection on draft-ietf-lmap-information-model-17: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:10:46 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lmap-information-model-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Russ's comment in his GenArt review that the credentials/certificates described in section 3.1 warrant discussion in the security considerations section. From nobody Wed Mar 15 10:01:50 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9211131720; Wed, 15 Mar 2017 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07R1qtm2TCVf; Wed, 15 Mar 2017 10:01:47 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5AB131715; Wed, 15 Mar 2017 10:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1229; q=dns/txt; s=iport; t=1489597306; x=1490806906; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=jVzJSBYy2Jpzs0cKFaoKu61B+1xSnsCZBXw+BAsb40g=; b=LftLdgAguqmJQRkt8eUa2CAjK8SoBWmdh6hW9S1kc1AEt1nbx/qyHsj0 v1CUFTZJGOyM02Z2ACkt5mqIDFgTWOgyTXl+fhdUmo5nxp25S39aFBBQw XntzGvzU3zTWoF8mfCjxyYpsa3fmZ082rpjrJlfUL2msKvRR/jU31pAvw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQBlcslY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDIqjk1zkGOTLYIPgg4qhXgCgy4YAQIBAQEBAQEBayiFFgEFODYbIyM?= =?us-ascii?q?LVwYBDAgBAYl8DrB4imABAQEBAQEBAQEBAQEBAQEBAQEbBYZOggWNIwWcQ4Z2i?= =?us-ascii?q?0WKUoZTiziIDx84gQQjFggXFUGFDYFLP4lnAQEB?= X-IronPort-AV: E=Sophos;i="5.36,169,1486425600"; d="scan'208";a="651472112" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2017 17:01:44 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2FH1gVu018074; Wed, 15 Mar 2017 17:01:44 GMT To: Kathleen Moriarty , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148943934250.20338.17609730068139281956.idtracker@ietfa.amsl.com> <20170313211835.GA53972@elstar.local> From: Benoit Claise Message-ID: <6756d540-e497-a983-0c30-ff46c712eecc@cisco.com> Date: Wed, 15 Mar 2017 18:01:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170313211835.GA53972@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lmap] YANG/RESTCONF security considerations: Kathleen Moriarty's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 17:01:49 -0000 Dear all, > On Mon, Mar 13, 2017 at 02:09:02PM -0700, Kathleen Moriarty wrote: >> The security considerations looks good, but can't YANG also be accessed >> via RESTCONF? What considerations are needed for that? I thunk we went >> through this for I2RS, do considerations for RESTCONF apply to this YANG >> module? >> > Yes, the document is using the old template. Looking at > draft-ietf-netmod-rfc6087bis-12.txt (posted March 5th) and > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines I do not > see a new template either. I think I recall having seen some > discussion somewhere (probably related to I2RS) but then I do not see > new text in draft-ietf-i2rs-yang-network-topo-12.txt. While I can make > up my own text, I think I prefer following a new template. Benoit? Yes, a new template is better. Note that the I2RS discussion is a different one, because they want the ability to have yet another protocol (different that NETCONF and RESTCONF), an insecure protocol. The discussion regarding the new template with a RESTCONF reference started on the NETMOD mailing list. The SEC ADs are copied. We want to make sure that you guys are fine with it. Regards, Benoit > > /js > From nobody Wed Mar 15 16:58:25 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F012E8FA; Wed, 15 Mar 2017 16:58:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148962230318.14229.6598332357400784910.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 16:58:23 -0700 Archived-At: Subject: [lmap] Suresh Krishnan's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:58:23 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lmap-yang-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Figure 1: There is a typo (actually four typos) in the yang module name ietf-lmap-comman.yang should be ietf-lmap-common.yang instead From nobody Wed Mar 15 17:21:58 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2312E870; Wed, 15 Mar 2017 17:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjXJfZlRS8ha; Wed, 15 Mar 2017 17:21:55 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A592A12ECEB; Wed, 15 Mar 2017 17:21:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8E46C2CCC1; Thu, 16 Mar 2017 02:21:53 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFfwtPNYTiIA; Thu, 16 Mar 2017 02:21:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B4DF42CC5E; Thu, 16 Mar 2017 02:21:50 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CB8F321D-D12E-4739-87AA-32F20AFB3153"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148814339074.2901.10793232146724828053.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 09:21:48 +0900 Cc: General Area Review Team , draft-ietf-lmap-information-model.all@ietf.org, IETF , lmap@ietf.org Message-Id: <391122AA-5077-4208-AD6A-4104BDAAEDA0@piuha.net> References: <148814339074.2901.10793232146724828053.idtracker@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-17 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 00:21:57 -0000 --Apple-Mail=_CB8F321D-D12E-4739-87AA-32F20AFB3153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your review, Russ. For what it is worth, I agree with your = comment/question about the credentials. It is fine to have different = arrangements for different situations, but Russ=92s question was really = not about that but whether the CA information mentioned earlier is a = part of a specific part of the information model (ma-credentials). I = think that deserves clarification. Jari --Apple-Mail=_CB8F321D-D12E-4739-87AA-32F20AFB3153 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYydqcAAoJEM80gCTQU46qIncP/1nkY97exXg32sKClJYWiNAS Z+m0lpOuWO1VFGq/t1yO+aNzD/OQ9x/F/HGUydNlBwSY9Soynxuh+rB9O1GubD8E /5e6Cs+yv6VXx3iGAAsCBrqK+4rFAfzSmukenabcXWpeJgAqCec0nAxfro2ethK6 c842wq0cPl0wi6Rugse1VcCnt9dJOn80oUXziO1qaYuYt5LGwJ88Y9XXujBwACyl cRY/MX+y1t66ZRiL3DJTKY+XG7nqsB+sYRdUsq3K3wyZ1OwJNuJvCmuCeb1A/4px WOA/l5PPYFYx+CYjoarA6QQ12aSq3rNiShY3EOROxTTQ5O84B/wIPdMzb2yRoU+1 f+LijEfXx3fpZEbZcphLAXeV4bQN7kra3t41ogowswrVx4b98OmjemZsoYs6Ue0F VNBkQupupssf3iNmgPQR0+AkEVT5y8Q9cRJnA4nhzeKy6U7Spk6m8dKydeGPwWgY 8t283RzmNNpkJzMV+B0dnITtQyK/XtUc53/gNb6qFzLem5/xXuAiU9T2Bx/Ol4Ht ZQrj2hIqg/N6LdG/e3h9fmWfb2gbmydcv7qBCZzY8P3C6J9KBsz2GVF+xHGr1pGj qloIyXMmDQ3ck7j1VXOgHfSTtAh+/2NgpM6knfOxNXYuzOBBH+51/7bMxMl+Twiw OlFS0uY5PPfyCHtlWYo0 =7cXd -----END PGP SIGNATURE----- --Apple-Mail=_CB8F321D-D12E-4739-87AA-32F20AFB3153-- From nobody Thu Mar 16 00:13:44 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3520E126B7F; Thu, 16 Mar 2017 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fB105_TtxCh; Thu, 16 Mar 2017 00:13:40 -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 A8B8C126B6E; Thu, 16 Mar 2017 00:13:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75D0E12C6; Thu, 16 Mar 2017 08:13:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ntVj_j9QyKBN; Thu, 16 Mar 2017 08:13:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 08:13:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F6220038; Thu, 16 Mar 2017 08:13:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hkTIY-AZjYgy; Thu, 16 Mar 2017 08:13:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98F6220035; Thu, 16 Mar 2017 08:13:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E43F13EBEABF; Thu, 16 Mar 2017 08:13:43 +0100 (CET) Date: Thu, 16 Mar 2017 08:13:43 +0100 From: Juergen Schoenwaelder To: Suresh Krishnan Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Message-ID: <20170316071343.GB59114@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Suresh Krishnan , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148962230318.14229.6598332357400784910.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148962230318.14229.6598332357400784910.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Suresh Krishnan's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 07:13:42 -0000 On Wed, Mar 15, 2017 at 04:58:23PM -0700, Suresh Krishnan wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Figure 1: > There is a typo (actually four typos) in the yang module name > > ietf-lmap-comman.yang should be ietf-lmap-common.yang instead > Oops, fixed in my sources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 16 02:27:33 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E716126DED; Thu, 16 Mar 2017 02:27:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org, bill.wu@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 02:27:31 -0700 Archived-At: Subject: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:27:31 -0000 Benoit Claise has entered the following ballot position for draft-ietf-lmap-yang-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - No objection to the publication, but the following phrasing puzzles me. It aims to be consistent with the LMAP Information Model [I-D.ietf-lmap-information-model]. Actually, the data model is based on information model, right? >From the charter: 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). This is reason why the information model is standard track in the charter. Therefore the information model must be a normative reference, right? - one question about the typedefs naming. It would nice to be able to reuse YANG constructs, typedefs being of them We created http://www.yangcatalog.org/yang-search/yang-search.php with that goal in mind. => insert "identifier" => select typedef Some of the typedefs are so generically named in LMAP YANG module: identifier, tag, cycle-number, wildcard, etc. Do you expect YANG designers to reuse them outside of LMAP? Some of them, I guess so Should the other ones be renamed with LMAP in mind. Ex: lmap-identifier? In other words, are all the ietf-lmap-common.yang typedef common? Editorial: - figure 1 OLD: ietf-lmap-comman.yang NEW: ietf-lmap-common.yang From nobody Thu Mar 16 03:26:24 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A270127333; Thu, 16 Mar 2017 03:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1547mIzXOkz; Thu, 16 Mar 2017 03:26:15 -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 5634F127097; Thu, 16 Mar 2017 03:26:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 23D36375; Thu, 16 Mar 2017 11:26:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lfTJuq-Gj5rM; Thu, 16 Mar 2017 11:26:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 11:26:13 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E10920035; Thu, 16 Mar 2017 11:26:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L6EpQ7W0lbYc; Thu, 16 Mar 2017 11:26:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AA4A20038; Thu, 16 Mar 2017 11:26:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2C063EDBDBE; Thu, 16 Mar 2017 11:26:16 +0100 (CET) Date: Thu, 16 Mar 2017 11:26:16 +0100 From: Juergen Schoenwaelder To: Benoit Claise Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com Message-ID: <20170316102616.GC59698@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com References: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 10:26:17 -0000 On Thu, Mar 16, 2017 at 02:27:31AM -0700, Benoit Claise wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - No objection to the publication, but the following phrasing puzzles > me. > > It aims to be consistent with the > LMAP Information Model [I-D.ietf-lmap-information-model]. > > Actually, the data model is based on information model, right? I changed this to "It is based on the LMAP Information Model []" in my sources. > >From the charter: > 5. The Report protocol and the associated data model: The definition of > > how the Report is delivered from a MA to a Collector; this includes a > Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). > > This is reason why the information model is standard track in the > charter. > Therefore the information model must be a normative reference, right? I don't quite understand the logic above. That said, I can go either way (means I do not really care whether the reference is in the normative of informative section). > - one question about the typedefs naming. > It would nice to be able to reuse YANG constructs, typedefs being of > them > We created http://www.yangcatalog.org/yang-search/yang-search.php with > that goal in mind. > => insert "identifier" > => select typedef > Some of the typedefs are so generically named in LMAP YANG module: > identifier, tag, cycle-number, wildcard, etc. > Do you expect YANG designers to reuse them outside of LMAP? Some of them, > I guess so > Should the other ones be renamed with LMAP in mind. Ex: > lmap-identifier? > In other words, are all the ietf-lmap-common.yang typedef common? When you reuse definitions from ietf-lmap-common, they will appear in your YANG module as: type lmap:identifier; Adding lmap to the type name just makes things look unnecessarily ugly: type lmap:lmap-identifier; I am not sure it is useful to speculate who might be reusing what in the future. I would rather keep an eye on things and if we observe that definitions get reused or duplicated, consider moving these definitions into a common place (ietf-yang-types, ietf-inet-types) since I do understand that people prefer to not depend on definitions contained in some arbitrary YANG modules where maintenance may be less clear over time. It may not be bad to spin the common yang types document every ~3 years. (But then I also recall that last time the nitpicking during the approval process was on types that already existed in the first revision and not on the stuff that was added, which makes this at times a bit painful.) > Editorial: > - figure 1 > OLD: ietf-lmap-comman.yang > NEW: ietf-lmap-common.yang Already fixed in my sources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 16 03:41:25 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 079F512704B; Thu, 16 Mar 2017 03:41:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148966088402.14237.8125728085301219492.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 03:41:24 -0700 Archived-At: Subject: [lmap] Alexey Melnikov's No Objection on draft-ietf-lmap-information-model-17: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:41:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lmap-information-model-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only skimmed the document. ma-log-description: A human readable description of the event. As per Section 4 of BCP 18 , human readable text should be associated with language tags. You should consider adding this functionality to the information model. From nobody Thu Mar 16 04:47:24 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C6312941C; Thu, 16 Mar 2017 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yHrmZ6L6tgR; Thu, 16 Mar 2017 04:47:16 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2381293E4; Thu, 16 Mar 2017 04:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3457; q=dns/txt; s=iport; t=1489664835; x=1490874435; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=gRuAQlMNFzMd22TIj6o1TOvTdRS8MI4E9GYXxa6JIoc=; b=RKwvyZrIsIW81jCR03IRPU/Kx+6pV4xaR3b5+jeynsbx3G1wUL3JikrX 69vvE0Z/mocYxtUbgGoCQdqxmownJv7Ztg41vc987P2xQHiuzIAthy3oy So2wDtqqB0n7n+Ma2esgSMMaHhotwrdgk8acqBpDEjcpXQ0uIC1poOT09 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDeecpY/xbLJq1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcHOQZZMwgg+CDiqFeAKDQBgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBOFELGC5XBgEMCAEBBYlvCA4xsi6KUAEBAQEBAQEBAQEBAQEBAQEBASCGT?= =?us-ascii?q?oIFgmqCcIdJBYkbhkCMapI+ilaGU4oVgSmIDx84gQQjFggXFYUYHYFkPzUBiUc?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="scan'208";a="651489906" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 11:47:12 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2GBlCat022625; Thu, 16 Mar 2017 11:47:12 GMT To: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com References: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> <20170316102616.GC59698@elstar.local> From: Benoit Claise Message-ID: <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com> Date: Thu, 16 Mar 2017 12:47:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316102616.GC59698@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 11:47:18 -0000 On 3/16/2017 11:26 AM, Juergen Schoenwaelder wrote: > On Thu, Mar 16, 2017 at 02:27:31AM -0700, Benoit Claise wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - No objection to the publication, but the following phrasing puzzles >> me. >> >> It aims to be consistent with the >> LMAP Information Model [I-D.ietf-lmap-information-model]. >> >> Actually, the data model is based on information model, right? > I changed this to "It is based on the LMAP Information Model []" in > my sources. > >> >From the charter: >> 5. The Report protocol and the associated data model: The definition of >> >> how the Report is delivered from a MA to a Collector; this includes a >> Data Model consistent with the Information Model plus a transport >> protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >> >> This is reason why the information model is standard track in the >> charter. >> Therefore the information model must be a normative reference, right? > I don't quite understand the logic above. That said, I can go either > way (means I do not really care whether the reference is in the > normative of informative section). The question is: which one is the source of truth? The IM or the DM? > >> - one question about the typedefs naming. >> It would nice to be able to reuse YANG constructs, typedefs being of >> them >> We created http://www.yangcatalog.org/yang-search/yang-search.php with >> that goal in mind. >> => insert "identifier" >> => select typedef >> Some of the typedefs are so generically named in LMAP YANG module: >> identifier, tag, cycle-number, wildcard, etc. >> Do you expect YANG designers to reuse them outside of LMAP? Some of them, >> I guess so >> Should the other ones be renamed with LMAP in mind. Ex: >> lmap-identifier? >> In other words, are all the ietf-lmap-common.yang typedef common? > When you reuse definitions from ietf-lmap-common, they will appear in > your YANG module as: > > type lmap:identifier; Sure. > > Adding lmap to the type name just makes things look unnecessarily > ugly: ... from a LMAP point of view. > > type lmap:lmap-identifier; I come from this angle: http://www.yangcatalog.org/yang-search/yang-search.php And I search for any identifier typedef I could reuse. I would prefer to have typedefs called LMAP-xxx is they're not really common. > > I am not sure it is useful to speculate who might be reusing what in > the future. I would rather keep an eye on things and if we observe > that definitions get reused or duplicated, consider moving these > definitions into a common place (ietf-yang-types, ietf-inet-types) > since I do understand that people prefer to not depend on definitions > contained in some arbitrary YANG modules where maintenance may be less > clear over time. It may not be bad to spin the common yang types > document every ~3 years. (But then I also recall that last time the > nitpicking during the approval process was on types that already > existed in the first revision and not on the stuff that was added, > which makes this at times a bit painful.) You're maybe right. Regards, B. > >> Editorial: >> - figure 1 >> OLD: ietf-lmap-comman.yang >> NEW: ietf-lmap-common.yang > Already fixed in my sources. > > /js > From nobody Thu Mar 16 05:20:53 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C095129471; Thu, 16 Mar 2017 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDmQ4jfCI6XD; Thu, 16 Mar 2017 05:20:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11060129456; Thu, 16 Mar 2017 05:20:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 92DD711D1; Thu, 16 Mar 2017 13:20:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kNNig6BvLGsr; Thu, 16 Mar 2017 13:20:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 13:20:44 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2D4E20038; Thu, 16 Mar 2017 13:20:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T152CE6nnhCX; Thu, 16 Mar 2017 13:20:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87E1820035; Thu, 16 Mar 2017 13:20:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 92A353EE7993; Thu, 16 Mar 2017 13:20:47 +0100 (CET) Date: Thu, 16 Mar 2017 13:20:46 +0100 From: Juergen Schoenwaelder To: Benoit Claise Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com Message-ID: <20170316122046.GD59698@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com References: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> <20170316102616.GC59698@elstar.local> <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 12:20:49 -0000 On Thu, Mar 16, 2017 at 12:47:09PM +0100, Benoit Claise wrote: > On 3/16/2017 11:26 AM, Juergen Schoenwaelder wrote: > > On Thu, Mar 16, 2017 at 02:27:31AM -0700, Benoit Claise wrote: > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > - No objection to the publication, but the following phrasing puzzles > > > me. > > > > > > It aims to be consistent with the > > > LMAP Information Model [I-D.ietf-lmap-information-model]. > > > > > > Actually, the data model is based on information model, right? > > I changed this to "It is based on the LMAP Information Model []" in > > my sources. > > > >From the charter: > > > 5. The Report protocol and the associated data model: The definition of > > > > > > how the Report is delivered from a MA to a Collector; this includes a > > > Data Model consistent with the Information Model plus a transport > > > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). > > > > > > This is reason why the information model is standard track in the > > > charter. > > > Therefore the information model must be a normative reference, right? > > I don't quite understand the logic above. That said, I can go either > > way (means I do not really care whether the reference is in the > > normative of informative section). > The question is: which one is the source of truth? The IM or the DM? When it comes to implementation, I think it is the YANG model you have to conform to. If the YANG model has a conflict with the information model somewhere, we need to discuss and resolve this. I do not think we can state one of them is automatically right. > > > - one question about the typedefs naming. > > > It would nice to be able to reuse YANG constructs, typedefs being of > > > them > > > We created http://www.yangcatalog.org/yang-search/yang-search.php with > > > that goal in mind. > > > => insert "identifier" > > > => select typedef > > > Some of the typedefs are so generically named in LMAP YANG module: > > > identifier, tag, cycle-number, wildcard, etc. > > > Do you expect YANG designers to reuse them outside of LMAP? Some of them, > > > I guess so > > > Should the other ones be renamed with LMAP in mind. Ex: > > > lmap-identifier? > > > In other words, are all the ietf-lmap-common.yang typedef common? I do not care. I leave it up to whoever wants to reuse them to decide. The definitions are clearly common for the LMAP modules, everything beyond that is up in the air. Recall the SnmpAdminString where the name indicates it is for SNMP adminitrative names but then later it got used in many places as a common string type supporting UTF-8. Prediction of future use and encoding that into names is difficult. > > When you reuse definitions from ietf-lmap-common, they will appear in > > your YANG module as: > > > > type lmap:identifier; > Sure. > > > > Adding lmap to the type name just makes things look unnecessarily > > ugly: > ... from a LMAP point of view. > > > > type lmap:lmap-identifier; > > I come from this angle: > http://www.yangcatalog.org/yang-search/yang-search.php > And I search for any identifier typedef I could reuse. > I would prefer to have typedefs called LMAP-xxx is they're not really > common. Obviously, the typedefs were written primarily for LMAP purposes. However, for all typedefs, I can imagine situations where they may be reused outside LMAP. The groupings are more likely LMAP specific but even then I can also imagine that perhaps some future IPPM modules may want to use them. Predicting future is difficult. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 16 05:54:36 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3C12948A; Thu, 16 Mar 2017 05:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtcrkLu0p9lX; Thu, 16 Mar 2017 05:54:28 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DA8129464; Thu, 16 Mar 2017 05:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4075; q=dns/txt; s=iport; t=1489668868; x=1490878468; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=FYCOrSrPlxL/KqBC8aY2N8T6eiP57ZmnEDhfp299QcY=; b=Ttq0id2HjsUC3zG2RRaXXjEdHGHQ98+dQc8lMtG1sD9SCJwkRSggKm/1 cKrOgyZsuisQSFezDJuhQ267bYB6Ywd51QekPI8etx9fqk4r6WAIQPUFn feQW+my30ghoDSbSRymZzaB2Mpy18/1gS8Uqe5vwlpKYdq9HKkOPd3LWJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQBQispY/xbLJq1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcHOQZZMwgg+CDiqFeAKDQRgBAgEBAQEBAQFrKIUWAQU?= =?us-ascii?q?yAQVRCxguVwYBDAgBAQWJdw4xskSKUgEBAQEBAQEBAQEBAQEBAQEBASCGToIFg?= =?us-ascii?q?mqCcIdJBYkbhkCMapI+ilaGU4oVgSmIDx84gQQjFggXFYUYHYFkPzUBiUcBAQE?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="scan'208";a="650469769" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 12:54:25 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2GCsONc009189; Thu, 16 Mar 2017 12:54:25 GMT To: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com References: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> <20170316102616.GC59698@elstar.local> <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com> <20170316122046.GD59698@elstar.local> From: Benoit Claise Message-ID: <9dc3768b-a059-af33-6d3b-199a741de100@cisco.com> Date: Thu, 16 Mar 2017 13:54:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316122046.GD59698@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 12:54:30 -0000 Hi Jürgen, > On Thu, Mar 16, 2017 at 12:47:09PM +0100, Benoit Claise wrote: >> On 3/16/2017 11:26 AM, Juergen Schoenwaelder wrote: >>> On Thu, Mar 16, 2017 at 02:27:31AM -0700, Benoit Claise wrote: >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> - No objection to the publication, but the following phrasing puzzles >>>> me. >>>> >>>> It aims to be consistent with the >>>> LMAP Information Model [I-D.ietf-lmap-information-model]. >>>> >>>> Actually, the data model is based on information model, right? >>> I changed this to "It is based on the LMAP Information Model []" in >>> my sources. >>>> >From the charter: >>>> 5. The Report protocol and the associated data model: The definition of >>>> >>>> how the Report is delivered from a MA to a Collector; this includes a >>>> Data Model consistent with the Information Model plus a transport >>>> protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >>>> >>>> This is reason why the information model is standard track in the >>>> charter. >>>> Therefore the information model must be a normative reference, right? >>> I don't quite understand the logic above. That said, I can go either >>> way (means I do not really care whether the reference is in the >>> normative of informative section). >> The question is: which one is the source of truth? The IM or the DM? > When it comes to implementation, I think it is the YANG model you have > to conform to. If the YANG model has a conflict with the information > model somewhere, we need to discuss and resolve this. I do not think > we can state one of them is automatically right. You're not helping :-) "It is based on the LMAP Information Model []" is already good change. Informative versus normative is a smaller issue IMO. A small preference for normative, but I'll leave it to the responsible AD to decide. The rest below was discussed. Let's move on. Regards, Benoit > >>>> - one question about the typedefs naming. >>>> It would nice to be able to reuse YANG constructs, typedefs being of >>>> them >>>> We created http://www.yangcatalog.org/yang-search/yang-search.php with >>>> that goal in mind. >>>> => insert "identifier" >>>> => select typedef >>>> Some of the typedefs are so generically named in LMAP YANG module: >>>> identifier, tag, cycle-number, wildcard, etc. >>>> Do you expect YANG designers to reuse them outside of LMAP? Some of them, >>>> I guess so >>>> Should the other ones be renamed with LMAP in mind. Ex: >>>> lmap-identifier? >>>> In other words, are all the ietf-lmap-common.yang typedef common? > I do not care. I leave it up to whoever wants to reuse them to decide. > The definitions are clearly common for the LMAP modules, everything > beyond that is up in the air. > > Recall the SnmpAdminString where the name indicates it is for SNMP > adminitrative names but then later it got used in many places as a > common string type supporting UTF-8. Prediction of future use and > encoding that into names is difficult. > >>> When you reuse definitions from ietf-lmap-common, they will appear in >>> your YANG module as: >>> >>> type lmap:identifier; >> Sure. >>> Adding lmap to the type name just makes things look unnecessarily >>> ugly: >> ... from a LMAP point of view. >>> type lmap:lmap-identifier; >> I come from this angle: >> http://www.yangcatalog.org/yang-search/yang-search.php >> And I search for any identifier typedef I could reuse. >> I would prefer to have typedefs called LMAP-xxx is they're not really >> common. > Obviously, the typedefs were written primarily for LMAP > purposes. However, for all typedefs, I can imagine situations where > they may be reused outside LMAP. The groupings are more likely LMAP > specific but even then I can also imagine that perhaps some future > IPPM modules may want to use them. Predicting future is difficult. > > /js > From nobody Thu Mar 16 06:27:52 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5041294E0; Thu, 16 Mar 2017 06:27:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani To: Cc: lmap@ietf.org, ietf@ietf.org, draft-ietf-lmap-yang.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148967086350.14253.11599284040763992866@ietfa.amsl.com> Date: Thu, 16 Mar 2017 06:27:43 -0700 Archived-At: Subject: [lmap] Review of draft-ietf-lmap-yang-11 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:27:44 -0000 Reviewer: Vijay Gurbani Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lmap-yang-?? Reviewer: Vijay Gurbani Review Date: 2017-03-16 IETF LC End Date: 2017-03-08 IESG Telechat date: 2017-03-16 Summary: Ready as a Proposed Standard. Major issues: 0 Minor issues: 0 Nits/editorial comments: 1 Nits: - S3: s/devided/divided/ From nobody Thu Mar 16 06:33:17 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B21294EC; Thu, 16 Mar 2017 06:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6JiFv9Bt2yg; Thu, 16 Mar 2017 06:33:09 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419B81294F0; Thu, 16 Mar 2017 06:33:07 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id o126so24517640pfb.3; Thu, 16 Mar 2017 06:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sBDrU+aCK6dDchi6MGjGUtEoUbn+Vjq8FDa6E1JEZgc=; b=TBY7oCMIkcGVHM4etpo51+XwJe2V0cpGEIq6TRcXxN7XquSXwHPoa/5vwh7xPohWZz EgPj3MXNr5icaVkZ9iuzRb8bQOijyINdYUt/8izg1e2m6BDoOim7/KUiz8uscAQXbXkr E3Nf6u1ug9RBVH7vZ6/Bx7j3aCGWs87MF2+JhbVPOnJc8htlTyrh0AGV0hcR1TaMeaL4 DP68eMHUtkfq2uxQWg5kvV7mQEpEXyAU0+Gm1IJ66G6JU5rBFFj428f7xFlSDvooshcA hlu1HuzHApxzE0PmSCSyV96TsrL0PHluxf76VRb+O2nKgqJ4g4fH7Zv1G1f0PGwPxlod ybxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sBDrU+aCK6dDchi6MGjGUtEoUbn+Vjq8FDa6E1JEZgc=; b=hhxY6VHlxTek/TccmhpCS9ny/qKP79pdyQhMgBGQf1alowigDO+ji6feTNmilG9pHX gMZ0z6Xt3AqHGdLSQy2+uFa+UFtg137+73DfPCy2ROVtDHwYzbFqgKBjw5kdU9tIDWhY IR3UIvk+OpuTx95yrqzo6mSPEeDvw27JKmpTAHqzGhR2soL6zeXqkUG4z5YbU8ofmBSy SPXmoLqk5lYmI4ia7yhLgy71JvwMH0crzIQ44PprproaZtEEfj7dLtTENM/3cC63HBOT uP9mViZfYzIgKRBXYlCRTvAL4hDkIMmE8ccRL4mk+hT1WXTfXCIOmO7H+8JJq8n12cpT TbEA== X-Gm-Message-State: AFeK/H3UZaw+Pj48tiWZIxxDe+E4gxGo9PLY8QUWPYOBG2QgqX/vUMlSPRXbqU68ea7ZKi6Np3YLYZ97ax9Diw== X-Received: by 10.84.229.73 with SMTP id d9mr5204042pln.177.1489671186877; Thu, 16 Mar 2017 06:33:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Thu, 16 Mar 2017 06:33:03 -0700 (PDT) In-Reply-To: <6756d540-e497-a983-0c30-ff46c712eecc@cisco.com> References: <148943934250.20338.17609730068139281956.idtracker@ietfa.amsl.com> <20170313211835.GA53972@elstar.local> <6756d540-e497-a983-0c30-ff46c712eecc@cisco.com> From: Kathleen Moriarty Date: Thu, 16 Mar 2017 09:33:03 -0400 Message-ID: To: Benoit Claise Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [lmap] YANG/RESTCONF security considerations: Kathleen Moriarty's No Objection on draft-ietf-lmap-yang-11: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 13:33:11 -0000 Hi Benoit, On Wed, Mar 15, 2017 at 1:01 PM, Benoit Claise wrote: > Dear all, >> >> On Mon, Mar 13, 2017 at 02:09:02PM -0700, Kathleen Moriarty wrote: >>> >>> The security considerations looks good, but can't YANG also be accessed >>> via RESTCONF? What considerations are needed for that? I thunk we went >>> through this for I2RS, do considerations for RESTCONF apply to this YANG >>> module? >>> >> Yes, the document is using the old template. Looking at >> draft-ietf-netmod-rfc6087bis-12.txt (posted March 5th) and >> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines I do not >> see a new template either. I think I recall having seen some >> discussion somewhere (probably related to I2RS) but then I do not see >> new text in draft-ietf-i2rs-yang-network-topo-12.txt. While I can make >> up my own text, I think I prefer following a new template. Benoit? > > Yes, a new template is better. > Note that the I2RS discussion is a different one, because they want the > ability to have yet another protocol (different that NETCONF and RESTCONF), > an insecure protocol. I believe it is the same discussion. I2RS is using NETCONF and RESTCONF only for transports. The other considerations for their document was bout markings in a data model that allow for an approach that is the reverse of what we normally see/recommend. > > The discussion regarding the new template with a RESTCONF reference started > on the NETMOD mailing list. The SEC ADs are copied. We want to make sure > that you guys are fine with it. I'll see if I can find this to help wrap it up. Thanks. > > Regards, Benoit >> >> >> /js >> > -- Best regards, Kathleen From nobody Thu Mar 16 06:50:01 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8F1294FF; Thu, 16 Mar 2017 06:49:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" Cc: draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148967219441.14225.10948316175746480722.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 06:49:54 -0700 Archived-At: Subject: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-information-model-17: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:49:54 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lmap-information-model-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I suspect Leif and Russ are right that credential handling needs a bit more work. (IOW, I agree with Jari's comment.) From nobody Thu Mar 16 06:54:57 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299FD12950B; Thu, 16 Mar 2017 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkiCGCCXbe9A; Thu, 16 Mar 2017 06:54:54 -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 A15A5129511; Thu, 16 Mar 2017 06:54:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6D47F6BB; Thu, 16 Mar 2017 14:54:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UV4AcAgDAxsb; Thu, 16 Mar 2017 14:54:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 14:54:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D84020035; Thu, 16 Mar 2017 14:54:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9HmsP0IK00qE; Thu, 16 Mar 2017 14:54:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E433120033; Thu, 16 Mar 2017 14:54:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 253FA3EE857E; Thu, 16 Mar 2017 14:54:58 +0100 (CET) Date: Thu, 16 Mar 2017 14:54:58 +0100 From: Juergen Schoenwaelder To: Stephen Farrell Cc: The IESG , draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Message-ID: <20170316135458.GC23450@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Stephen Farrell , The IESG , draft-ietf-lmap-information-model@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148967219441.14225.10948316175746480722.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148967219441.14225.10948316175746480722.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-information-model-17: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 13:54:56 -0000 On Thu, Mar 16, 2017 at 06:49:54AM -0700, Stephen Farrell wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I suspect Leif and Russ are right that credential handling > needs a bit more work. (IOW, I agree with Jari's comment.) > I do not understand the edits. A secure channel needs credentials. What these credentials are we can't really say at the information model level. Obviously, if the controller wants to configure a new reporting channel, it needs to be able to configure the approriate credentials to make the channel work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 16 07:53:16 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2163129544; Thu, 16 Mar 2017 07:53:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148967599467.14149.3188235856151065534.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 07:53:14 -0700 Archived-At: Subject: [lmap] Benoit Claise's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:53:15 -0000 Benoit Claise has entered the following ballot position for draft-ietf-lmap-yang-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As agreed during the IESG telechat, holding a DISCUSS until the new YANG security considerations template including RESTCONF is agreed upon. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - No objection to the publication, but the following phrasing puzzles me. It aims to be consistent with the LMAP Information Model [I-D.ietf-lmap-information-model]. Actually, the data model is based on information model, right? >From the charter: 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). This is reason why the information model is standard track in the charter. Therefore the information model must be a normative reference, right? - one question about the typedefs naming. It would nice to be able to reuse YANG constructs, typedefs being of them We created http://www.yangcatalog.org/yang-search/yang-search.php with that goal in mind. => insert "identifier" => select typedef Some of the typedefs are so generically named in LMAP YANG module: identifier, tag, cycle-number, wildcard, etc. Do you expect YANG designers to reuse them outside of LMAP? Some of them, I guess so Should the other ones be renamed with LMAP in mind. Ex: lmap-identifier? In other words, are all the ietf-lmap-common.yang typedef common? Editorial: - figure 1 OLD: ietf-lmap-comman.yang NEW: ietf-lmap-common.yang From nobody Mon Mar 20 09:01:30 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A158127B5A; Mon, 20 Mar 2017 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=tKJzsUKe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e57W2fKD 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 4GAaMkMDtthP; Mon, 20 Mar 2017 09:01:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FC81314BA; Mon, 20 Mar 2017 09:01:23 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 84F1B20AF4; Mon, 20 Mar 2017 12:01:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 20 Mar 2017 12:01:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=QMAhmwPRWWW2PaOHp2 WBKUppbfi2XbCRGkY4n1i3kQc=; b=tKJzsUKepBBzM29SzNQKUgGPbEpEPshI1o RABB91bEUY3l/yi/YxgbMCwbyvONBv0G8vo8PM3BP7kEX90XkB99+2OiX00dRB4n V5PIWtHlLM9722cd6EqFI0PznM+haSL3Tz6ITqYItHVjyAmfDQeAGdYFLOZA1o5X YKriToKNcPW6XbJRFzQKMvGZOnZuvJLvcsKoMr/vqHUMXZmOkXJuZV1LlLHlfTr+ jQi5hDbHNoLcguHq8VO7IKWuteBldI0mYvnIMITinZpbFm1KzBMlil5vSh0Yif/C boWUmInuynAEgq/K3twVCjW4AKZgFccxYq+SEVw73SsI/8kEyamw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=QMAhmwPRWWW2PaOHp2WBKUppbfi2XbCRGkY4n1i3kQc=; b=e57W2fKD fQa6bIL0MJ5waabDeFEpDuyHOKT+kr2SGU4S7gGx1YnEbmTVqcX9M9pMdEZayLku mcAUHyDvGSr6hyDAxvZCX3VJFdRQ/5GO5fApFbNU7TY9ARF1kefCseINzRneJzU2 z1zoouaXQr/Vq0Y0I9ugVtOU6bo7tP1DCpyZ4MchM+mWy6Hv/PjSSSAgkrS76/4h ro/SuiWL5F6HHMjmHlMgIbVYTRR6rMHCkvq3PVZ2rC+5dHj+6hggzno9rGz5mIEw VPDmk8nnvpz2J0CdDuJVLTxyW31dsV1WaOObH/THHN/wELh7o5P7XWVsUMXF3fmW plwl5P+1gVQfUQ== X-ME-Sender: X-Sasl-enc: uNEB6ryJGAR8lsoS6FZD+mV9b4TgwH+cin5Kbh6kb71Z 1490025682 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id DE884240A5; Mon, 20 Mar 2017 12:01:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170314090649.GB54939@elstar.local> Date: Mon, 20 Mar 2017 12:01:19 -0400 Cc: Dan Romascanu , lmap-chairs@ietf.org, IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org, Juergen Schoenwaelder Content-Transfer-Encoding: quoted-printable Message-Id: <19B46632-5DD0-434B-8393-84C97B30B702@cooperw.in> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 16:01:29 -0000 Hi Mirja, Per our telechat discussion, could you provide clarification about what = further information you need to be able to clear? Thanks, Alissa > On Mar 14, 2017, at 5:06 AM, Juergen Schoenwaelder = wrote: >=20 > On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja K=FChlewind wrote: >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This draft does not specify a bootstrapping process (see RFC 7594 = 5.1.=20 >> Bootstrapping Process) and says: >> "Pre-Configuration Information: This is not modeled explicitly since >> bootstrapping information is outside the scope of this data model." >> So when and where and how will this be specified? >=20 > There is work ongoing in NETCONF to provide different pieces for > bootstrapping. >=20 > - draft-ietf-netconf-keystore >=20 > a model for managing keys >=20 > - draft-ietf-netconf-netconf-client-server >=20 > a model for managing NETCONF client and server config >=20 > - draft-ietf-netconf-restconf-client-server >=20 > a model for managing RESTCONF client and server config >=20 > - draft-ietf-netconf-ssh-client-server >=20 > a model providing NETCONF over SSH config details >=20 > - draft-ietf-netconf-tls-client-server >=20 > a model providing NETCONF over TLS config details >=20 > - draft-ietf-netconf-zerotouch >=20 > a mechanism for loading bootstrapping information >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Also it is not clear when and how to perform configuration actions. = To be >> a fully function protocol more guidance is needed. Not sure if that = is >> even the intention of this document but I don't see any other = documents >> that serves this purpose in the lmap queue. (And the milesstones are = not >> up to date and don't indicate with document maps to which milestone.) >=20 > When and how is up to the controller design. The fully functioning > protocol falls out of the YANG data model - once you have YANG data > model, you are ready to go. That said, there is a currently expired > WG document providing more details. >=20 > https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 >=20 > The idea here was just provide an explanation how the LMAP data model > works together with RESTCONF. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Mar 20 09:49:57 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690251314C1 for ; Mon, 20 Mar 2017 09:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db0KX1rh_uVG for ; Mon, 20 Mar 2017 09:49:54 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DA81314C0 for ; Mon, 20 Mar 2017 09:49:53 -0700 (PDT) Received: (qmail 1897 invoked from network); 20 Mar 2017 17:43:10 +0100 Received: from p5dec2f87.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.135) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Mar 2017 17:43:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20170314090649.GB54939@elstar.local> Date: Mon, 20 Mar 2017 17:43:09 +0100 Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 16:49:56 -0000 Hi J=C3=BCrgen, I=E2=80=99ve read draft-ietf-lmap-information-model first and then this = draft, and I was just left with a number of open questions. The simple = case where a controller sends a config, the MA does the measurement and = send the results to a collector is clear but = draft-ietf-lmap-information-model indicates that this is supposed to = cover more complex scenarios including more feedback to the controller = and things like requesting capabilities. Starting from draft-ietf-lmap-information-model: maybe you can further = comment on how the following parts of the information model is covered = by the yang model? Thanks! Section 3.9 of draft-ietf-lmap-information-model: "Tasks can be Measurement Tasks (i.e., those Tasks actually performing some type of passive or active measurement) or any other scheduled activity performed by the MA such as transferring information to or from the Controller and Collectors. Other examples of Tasks may include data manipulation or processing Tasks conducted on the MA.=E2=80=9C What =E2=80=9Eother scheduled activities=E2=80=9C? Where are those = defined, which information should be transferred, when should they be = performed, who decides that, and what=E2=80=99s the purpose here? Also = which data should be manipulated or what other processing tasks do you = need? Also "The Task Configuration will include a local short name for reference by a Schedule. Task Configurations may also refer to registry entries as described above. In addition the Task can be configured through a set of configuration Options. The nature and number of these Options will depend upon the Task. =E2=80=9E Can you give an example for an configuration task? Why is an = configuration option not sufficient? To be honest, I also not fully clear why you need a reporting task = because what you need is to configure when the reporting should be done. = If that is implemented in the same scheduler than the measurement tasks = is an implementation detail and does not need to part of the information = model. If it would not be part of the information model than it of = course would also not need to be discussed in the yang model. However, = as it is I think it would need more guidance when those task should be = generated and added to the schedule. In section 3.11.7 " The ma-controller-lost-obj indicates that connectivity to the controller has been lost. This is determined by a timer started after each successful contact with a controller. When the timer reaches the controller-timeout (measured in seconds), an ma- controller-lost-obj event is generated.=E2=80=9C Is there an assumption that the controller should frequently contact the = MA, even if there is no config data to send? What=E2=80=99s the right = time frame here? In section 3.11.8 "The ma-controller-connected-obj indicates that connectivity to the controller has been established again after it was lost.=E2=80=9C How is connectivity (re-)established? By the MA or by the controller? = What does connectivity even mean here? I guess the controller and MA = will not have a standing transport connection. It=E2=80=99s rather the = controller opens a connection pushes a config and closes the connection, = no? An then MA does whatever is configured to do. Why do you need to = maintain connectivity? And 3.5: "The MA will hold Capability Information that can be retrieved by a Controller. Capabilities include the device interface details available to Measurement Tasks as well as the set of Measurement Tasks/Roles (specified by registry entries) that are actually installed or available on the MA. Status information includes the times that operations were last performed such as contacting the Controller or producing Reports.=E2=80=9C When and why will they be retrieved by the controller? How can the = controller indicate to the MA to send this information and which? What = will the controller do with this information? Also note that Status = information is not the same than capabilities. This sounds more like an = interactive protocol and not just pushing a config onto a new device. These are all comments on draft-ietf-lmap-information-model but I was = hoping to find answers to these question in the yang model because that = the actual implementation of the protocol. Now I also looked at draft-ietf-lmap-restconf-03 which doesn=E2=80=99t = not provide a whole lot of additional information and the part I was = actually interested in says the following: "5. RESTCONF Configuration for LMAP XXX: This section should explain how an LMAP implementation needs to be configured to make use of the call-home mechanism and how report tasks refer to the configuration (if any standardized) needed to obtain the necessary credentials to report results. This needs to be worked through in detail.=E2=80=9C Mirja > Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder = : >=20 > On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja K=C3=BChlewind wrote: >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This draft does not specify a bootstrapping process (see RFC 7594 = 5.1.=20 >> Bootstrapping Process) and says: >> "Pre-Configuration Information: This is not modeled explicitly since >> bootstrapping information is outside the scope of this data model." >> So when and where and how will this be specified? >=20 > There is work ongoing in NETCONF to provide different pieces for > bootstrapping. >=20 > - draft-ietf-netconf-keystore >=20 > a model for managing keys >=20 > - draft-ietf-netconf-netconf-client-server >=20 > a model for managing NETCONF client and server config >=20 > - draft-ietf-netconf-restconf-client-server >=20 > a model for managing RESTCONF client and server config >=20 > - draft-ietf-netconf-ssh-client-server >=20 > a model providing NETCONF over SSH config details >=20 > - draft-ietf-netconf-tls-client-server >=20 > a model providing NETCONF over TLS config details >=20 > - draft-ietf-netconf-zerotouch >=20 > a mechanism for loading bootstrapping information >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Also it is not clear when and how to perform configuration actions. = To be >> a fully function protocol more guidance is needed. Not sure if that = is >> even the intention of this document but I don't see any other = documents >> that serves this purpose in the lmap queue. (And the milesstones are = not >> up to date and don't indicate with document maps to which milestone.) >=20 > When and how is up to the controller design. The fully functioning > protocol falls out of the YANG data model - once you have YANG data > model, you are ready to go. That said, there is a currently expired > WG document providing more details. >=20 > https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 >=20 > The idea here was just provide an explanation how the LMAP data model > works together with RESTCONF. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Mar 20 10:28:41 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80AF1315AF; Mon, 20 Mar 2017 10:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQBv0hIXoFpO; Mon, 20 Mar 2017 10:28:35 -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 6F149131504; Mon, 20 Mar 2017 10:27:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 461AC699; Mon, 20 Mar 2017 18:27:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N15EN_s9vR8a; Mon, 20 Mar 2017 18:27:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Mar 2017 18:27:28 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B5BB20035; Mon, 20 Mar 2017 18:27:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6-aCLQuVQRE5; Mon, 20 Mar 2017 18:27:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B267F20033; Mon, 20 Mar 2017 18:27:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D12B53EEFA09; Mon, 20 Mar 2017 18:27:31 +0100 (CET) Date: Mon, 20 Mar 2017 18:27:31 +0100 From: Juergen Schoenwaelder To: "Mirja Kuehlewind (IETF)" Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Message-ID: <20170320172731.GA33917@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Mirja Kuehlewind (IETF)" , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 17:28:39 -0000 On Mon, Mar 20, 2017 at 05:43:09PM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Jürgen, > > I’ve read draft-ietf-lmap-information-model first and then this draft, and I was just left with a number of open questions. The simple case where a controller sends a config, the MA does the measurement and send the results to a collector is clear but draft-ietf-lmap-information-model indicates that this is supposed to cover more complex scenarios including more feedback to the controller and things like requesting capabilities. > > Starting from draft-ietf-lmap-information-model: maybe you can further comment on how the following parts of the information model is covered by the yang model? Thanks! > > Section 3.9 of draft-ietf-lmap-information-model: > "Tasks can be > Measurement Tasks (i.e., those Tasks actually performing some type of > passive or active measurement) or any other scheduled activity > performed by the MA such as transferring information to or from the > Controller and Collectors. Other examples of Tasks may include data > manipulation or processing Tasks conducted on the MA.“ > What „other scheduled activities“? Where are those defined, which information should be transferred, when should they be performed, who decides that, and what’s the purpose here? Also which data should be manipulated or what other processing tasks do you need? Schedules invoke Actions that execute Tasks. Some tasks may be measurement tasks, other tasks may do other things - neither the information model nor the data model defines the tasks. The mapping of the information model to the data model is explained in the list in section 3. I do not see what really is missing or what could be unclear. Implementations may use tasks for reporting, implementations may use tasks for house keeping, implementations may use tasks for aggregation. > Also > "The Task Configuration will include a local short name for reference > by a Schedule. Task Configurations may also refer to registry > entries as described above. In addition the Task can be configured > through a set of configuration Options. The nature and number of > these Options will depend upon the Task. „ > Can you give an example for an configuration task? Why is an configuration option not sufficient? There are no configuration tasks. Task Configuration refers to the configuration of a task, i.e., a configured task. > To be honest, I also not fully clear why you need a reporting task because what you need is to configure when the reporting should be done. If that is implemented in the same scheduler than the measurement tasks is an implementation detail and does not need to part of the information model. If it would not be part of the information model than it of course would also not need to be discussed in the yang model. However, as it is I think it would need more guidance when those task should be generated and added to the schedule. The WG went through a long process to arrive at this solution. I don't see what is wrong with it. You want to schedule measurements, you also want to schedule the reporting. Treating both as scheduled tasks makes the model simpler. Which tasks you want to configure and schedule surely depends on the capabilities of an implementation and the measurement objectives. I do not think we can provide much guidance on this in the information model. > In section 3.11.7 > " The ma-controller-lost-obj indicates that connectivity to > the controller has been lost. This is determined by a timer started > after each successful contact with a controller. When the timer > reaches the controller-timeout (measured in seconds), an ma- > controller-lost-obj event is generated.“ > Is there an assumption that the controller should frequently contact the MA, even if there is no config data to send? What’s the right time frame here? The requirement was to ensure that an MA that is getting disconnected from its controller should at some time have a chance to stop its activities. This seems reasonable to me. In case the MA is behind a NAT (not that unusal), you typically have to call home to let the controller update the instructions. How frequently this happens is a deployment decision. > In section 3.11.8 > "The ma-controller-connected-obj indicates that > connectivity to the controller has been established again after it > was lost.“ > How is connectivity (re-)established? By the MA or by the controller? What does connectivity even mean here? I guess the controller and MA will not have a standing transport connection. It’s rather the controller opens a connection pushes a config and closes the connection, no? An then MA does whatever is configured to do. Why do you need to maintain connectivity? See above. We want to be able to shutdown MAs when their controller disappears. Furthermore, MAs may be behind NATs and in this case they have to initiate the connection, not the controller. > And 3.5: > "The MA will hold Capability Information that can be retrieved by a > Controller. Capabilities include the device interface details > available to Measurement Tasks as well as the set of Measurement > Tasks/Roles (specified by registry entries) that are actually > installed or available on the MA. Status information includes the > times that operations were last performed such as contacting the > Controller or producing Reports.“ > When and why will they be retrieved by the controller? How can the controller indicate to the MA to send this information and which? What will the controller do with this information? Also note that Status information is not the same than capabilities. This sounds more like an interactive protocol and not just pushing a config onto a new device. > The controller retrieves this information when he likes to retrieve this information. Typically, upon first contact, you like to figure out what an MA can do before sending down configuration. Status information may help the controller to debug problems or to keep basic statistics (percentage of failed measurement execution over time). I do not know what makes an 'interactive protocol' for you. But yes, you access the YANG model either via RESTCONF (with the usual HTTP methods) or via NETCONF (with the usual NETCONF operations). > These are all comments on draft-ietf-lmap-information-model but I was hoping to find answers to these question in the yang model because that the actual implementation of the protocol. It is a data model. The protocol primitives are in the RESTCONF / NETCONF protocols. There is a separation of protocol aspects from the data modeling aspects which seems to be confusing to you (but which we have done for decades in the network management space). > Now I also looked at draft-ietf-lmap-restconf-03 which doesn’t not provide a whole lot of additional information and the part I was actually interested in says the following: > > "5. RESTCONF Configuration for LMAP > > > XXX: This section should explain how an LMAP implementation needs to > be configured to make use of the call-home mechanism and how report > tasks refer to the configuration (if any standardized) needed to > obtain the necessary credentials to report results. This needs to be > worked through in detail.“ > This section was supposed to describe how you configure RESTCONF such that it works for an MA. This section was not intended to explain how you may use RESTCONF to read/write configuration and reports. The way we abstract protocol operations from data models seems to be new to you. You seem to be searching for a concrete protocol document saying if you are in state X send Y and if you receive Z do A. We do not have this. With RESTCONF, everything translates into a collection of resources you can GET/POST/PUT/PATCH/DELETE and the order in which a controller manipulates the resources is up to the implementation of the controller. (Slightly simplifying here, there is a notion of validity that YANG requires but lets not go there.) /js > > > > > > Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder : > > > > On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja Kühlewind wrote: > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> This draft does not specify a bootstrapping process (see RFC 7594 5.1. > >> Bootstrapping Process) and says: > >> "Pre-Configuration Information: This is not modeled explicitly since > >> bootstrapping information is outside the scope of this data model." > >> So when and where and how will this be specified? > > > > There is work ongoing in NETCONF to provide different pieces for > > bootstrapping. > > > > - draft-ietf-netconf-keystore > > > > a model for managing keys > > > > - draft-ietf-netconf-netconf-client-server > > > > a model for managing NETCONF client and server config > > > > - draft-ietf-netconf-restconf-client-server > > > > a model for managing RESTCONF client and server config > > > > - draft-ietf-netconf-ssh-client-server > > > > a model providing NETCONF over SSH config details > > > > - draft-ietf-netconf-tls-client-server > > > > a model providing NETCONF over TLS config details > > > > - draft-ietf-netconf-zerotouch > > > > a mechanism for loading bootstrapping information > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Also it is not clear when and how to perform configuration actions. To be > >> a fully function protocol more guidance is needed. Not sure if that is > >> even the intention of this document but I don't see any other documents > >> that serves this purpose in the lmap queue. (And the milesstones are not > >> up to date and don't indicate with document maps to which milestone.) > > > > When and how is up to the controller design. The fully functioning > > protocol falls out of the YANG data model - once you have YANG data > > model, you are ready to go. That said, there is a currently expired > > WG document providing more details. > > > > https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 > > > > The idea here was just provide an explanation how the LMAP data model > > works together with RESTCONF. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 20 13:18:33 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A512951E for ; Mon, 20 Mar 2017 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95FKDf45i-Td for ; Mon, 20 Mar 2017 13:18:29 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635B412951B for ; Mon, 20 Mar 2017 13:18:27 -0700 (PDT) Received: (qmail 11331 invoked from network); 20 Mar 2017 21:11:43 +0100 Received: from p5dec2f87.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.135) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Mar 2017 21:11:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20170320172731.GA33917@elstar.local> Date: Mon, 20 Mar 2017 21:11:06 +0100 Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 20:18:31 -0000 Hi! > Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder = : >=20 > On Mon, Mar 20, 2017 at 05:43:09PM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi J=C3=BCrgen, >>=20 >> I=E2=80=99ve read draft-ietf-lmap-information-model first and then = this draft, and I was just left with a number of open questions. The = simple case where a controller sends a config, the MA does the = measurement and send the results to a collector is clear but = draft-ietf-lmap-information-model indicates that this is supposed to = cover more complex scenarios including more feedback to the controller = and things like requesting capabilities. >>=20 >> Starting from draft-ietf-lmap-information-model: maybe you can = further comment on how the following parts of the information model is = covered by the yang model? Thanks! >>=20 >> Section 3.9 of draft-ietf-lmap-information-model: >> "Tasks can be >> Measurement Tasks (i.e., those Tasks actually performing some type = of >> passive or active measurement) or any other scheduled activity >> performed by the MA such as transferring information to or from the >> Controller and Collectors. Other examples of Tasks may include data >> manipulation or processing Tasks conducted on the MA.=E2=80=9C >> What =E2=80=9Eother scheduled activities=E2=80=9C? Where are those = defined, which information should be transferred, when should they be = performed, who decides that, and what=E2=80=99s the purpose here? Also = which data should be manipulated or what other processing tasks do you = need? >=20 > Schedules invoke Actions that execute Tasks. Some tasks may be > measurement tasks, other tasks may do other things - neither the > information model nor the data model defines the tasks. The mapping of > the information model to the data model is explained in the list in > section 3. I do not see what really is missing or what could be > unclear. Implementations may use tasks for reporting, implementations > may use tasks for house keeping, implementations may use tasks for > aggregation. >=20 >> Also >> "The Task Configuration will include a local short name for reference >> by a Schedule. Task Configurations may also refer to registry >> entries as described above. In addition the Task can be configured >> through a set of configuration Options. The nature and number of >> these Options will depend upon the Task. =E2=80=9E >> Can you give an example for an configuration task? Why is an = configuration option not sufficient? >=20 > There are no configuration tasks. Task Configuration refers to the > configuration of a task, i.e., a configured task. >=20 >> To be honest, I also not fully clear why you need a reporting task = because what you need is to configure when the reporting should be done. = If that is implemented in the same scheduler than the measurement tasks = is an implementation detail and does not need to part of the information = model. If it would not be part of the information model than it of = course would also not need to be discussed in the yang model. However, = as it is I think it would need more guidance when those task should be = generated and added to the schedule. >=20 > The WG went through a long process to arrive at this solution. I don't > see what is wrong with it. You want to schedule measurements, you also > want to schedule the reporting. Treating both as scheduled tasks makes > the model simpler. Which tasks you want to configure and schedule > surely depends on the capabilities of an implementation and the > measurement objectives. I do not think we can provide much guidance on > this in the information model. So I guess all the magic is now hidden in the capabilities. I saw = capabilities only as something that describes a measurement, but you say = you can also describe other tasks like reporting here. However, = including reporting and =E2=80=9Eother tasks=E2=80=9C in the = capabilities, makes it even harder to implement a controller, especially = when the controller controls multiple different MAs. Anyway, this = connection was missing for me. Maybe that could be make clearer. >=20 >> In section 3.11.7 >> " The ma-controller-lost-obj indicates that connectivity to >> the controller has been lost. This is determined by a timer started >> after each successful contact with a controller. When the timer >> reaches the controller-timeout (measured in seconds), an ma- >> controller-lost-obj event is generated.=E2=80=9C >> Is there an assumption that the controller should frequently contact = the MA, even if there is no config data to send? What=E2=80=99s the = right time frame here? >=20 > The requirement was to ensure that an MA that is getting disconnected > from its controller should at some time have a chance to stop its > activities. This seems reasonable to me. In case the MA is behind a > NAT (not that unusal), you typically have to call home to let the > controller update the instructions. How frequently this happens is a > deployment decision. If the MA is behind a NAT, the MA needs to know this and the MA anyway = has to connect to the controller. I guess that can be an initial = configuration but I guess the MA would also need to expose this to the = controller, as a capability=E2=80=A6? >=20 >> In section 3.11.8 >> "The ma-controller-connected-obj indicates that >> connectivity to the controller has been established again after it >> was lost.=E2=80=9C >> How is connectivity (re-)established? By the MA or by the controller? = What does connectivity even mean here? I guess the controller and MA = will not have a standing transport connection. It=E2=80=99s rather the = controller opens a connection pushes a config and closes the connection, = no? An then MA does whatever is configured to do. Why do you need to = maintain connectivity? >=20 > See above. We want to be able to shutdown MAs when their controller > disappears. Furthermore, MAs may be behind NATs and in this case they > have to initiate the connection, not the controller. The question was here more, how does the controller know that and how = often is has to connect to the client? Capabilities? >=20 >> And 3.5: >> "The MA will hold Capability Information that can be retrieved by a >> Controller. Capabilities include the device interface details >> available to Measurement Tasks as well as the set of Measurement >> Tasks/Roles (specified by registry entries) that are actually >> installed or available on the MA. Status information includes the >> times that operations were last performed such as contacting the >> Controller or producing Reports.=E2=80=9C >> When and why will they be retrieved by the controller? How can the = controller indicate to the MA to send this information and which? What = will the controller do with this information? Also note that Status = information is not the same than capabilities. This sounds more like an = interactive protocol and not just pushing a config onto a new device. >>=20 >=20 > The controller retrieves this information when he likes to retrieve > this information. Typically, upon first contact, you like to figure > out what an MA can do before sending down configuration. Status > information may help the controller to debug problems or to keep basic > statistics (percentage of failed measurement execution over time). >=20 > I do not know what makes an 'interactive protocol' for you. I was thinking about an interactive protocol because if all the magic is = hidden in the capabilities, than there seem to be a fixed pattern, where = the controller first has to request the capabilities, then the MA sends = them, and then the controller sends the actual measurement config. If = that=E2=80=99s the envisioned workflow, it would be good to say it = somewhere. > But yes, you > access the YANG model either via RESTCONF (with the usual HTTP = methods) > or via NETCONF (with the usual NETCONF operations). >=20 >> These are all comments on draft-ietf-lmap-information-model but I was = hoping to find answers to these question in the yang model because that = the actual implementation of the protocol. >=20 > It is a data model. The protocol primitives are in the RESTCONF / > NETCONF protocols. There is a separation of protocol aspects from the > data modeling aspects which seems to be confusing to you (but which we > have done for decades in the network management space). I unterstand this separation but the way you implemented this with = having everything as a task in a scheduler blurs the line. With this = patter you can in theory describe every (interactive) protocol without = actually describing the interactions. >=20 >> Now I also looked at draft-ietf-lmap-restconf-03 which doesn=E2=80=99t = not provide a whole lot of additional information and the part I was = actually interested in says the following: >>=20 >> "5. RESTCONF Configuration for LMAP >>=20 >>=20 >> XXX: This section should explain how an LMAP implementation needs to >> be configured to make use of the call-home mechanism and how report >> tasks refer to the configuration (if any standardized) needed to >> obtain the necessary credentials to report results. This needs to = be >> worked through in detail.=E2=80=9C >>=20 >=20 > This section was supposed to describe how you configure RESTCONF such > that it works for an MA. This section was not intended to explain how > you may use RESTCONF to read/write configuration and reports. The way > we abstract protocol operations from data models seems to be new to > you. You seem to be searching for a concrete protocol document saying > if you are in state X send Y and if you receive Z do A. We do not have > this. With RESTCONF, everything translates into a collection of > resources you can GET/POST/PUT/PATCH/DELETE and the order in which a > controller manipulates the resources is up to the implementation of > the controller. (Slightly simplifying here, there is a notion of > validity that YANG requires but lets not go there.) As said above, I understand the pattern restconf is using but you seem = to go slightly beyond this, e.g. assuming a certain pattern where = capabilities are retrieved first without every talking about this = assumption. I think further clarifying what capabilities are, could help; not sure = in which document that should actually be done. Mirja >=20 > /js >=20 >>=20 >>=20 >>=20 >>=20 >>> Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder = : >>>=20 >>> On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> This draft does not specify a bootstrapping process (see RFC 7594 = 5.1.=20 >>>> Bootstrapping Process) and says: >>>> "Pre-Configuration Information: This is not modeled explicitly = since >>>> bootstrapping information is outside the scope of this data model." >>>> So when and where and how will this be specified? >>>=20 >>> There is work ongoing in NETCONF to provide different pieces for >>> bootstrapping. >>>=20 >>> - draft-ietf-netconf-keystore >>>=20 >>> a model for managing keys >>>=20 >>> - draft-ietf-netconf-netconf-client-server >>>=20 >>> a model for managing NETCONF client and server config >>>=20 >>> - draft-ietf-netconf-restconf-client-server >>>=20 >>> a model for managing RESTCONF client and server config >>>=20 >>> - draft-ietf-netconf-ssh-client-server >>>=20 >>> a model providing NETCONF over SSH config details >>>=20 >>> - draft-ietf-netconf-tls-client-server >>>=20 >>> a model providing NETCONF over TLS config details >>>=20 >>> - draft-ietf-netconf-zerotouch >>>=20 >>> a mechanism for loading bootstrapping information >>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Also it is not clear when and how to perform configuration actions. = To be >>>> a fully function protocol more guidance is needed. Not sure if that = is >>>> even the intention of this document but I don't see any other = documents >>>> that serves this purpose in the lmap queue. (And the milesstones = are not >>>> up to date and don't indicate with document maps to which = milestone.) >>>=20 >>> When and how is up to the controller design. The fully functioning >>> protocol falls out of the YANG data model - once you have YANG data >>> model, you are ready to go. That said, there is a currently expired >>> WG document providing more details. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 >>>=20 >>> The idea here was just provide an explanation how the LMAP data = model >>> works together with RESTCONF. >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Mar 20 23:46:51 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B66129556; Mon, 20 Mar 2017 23:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB5H5KFSCP1c; Mon, 20 Mar 2017 23:46:39 -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 1FB63129551; Mon, 20 Mar 2017 23:46:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C6E1714; Tue, 21 Mar 2017 07:46:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5yCIXATJ7JVF; Tue, 21 Mar 2017 07:46:34 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 07:46:34 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B42020038; Tue, 21 Mar 2017 07:46:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18rUJ8HjIlS1; Tue, 21 Mar 2017 07:46:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D954920036; Tue, 21 Mar 2017 07:46:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 13CC03EF0388; Tue, 21 Mar 2017 07:46:36 +0100 (CET) Date: Tue, 21 Mar 2017 07:46:36 +0100 From: Juergen Schoenwaelder To: "Mirja Kuehlewind (IETF)" Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Message-ID: <20170321064636.GA34900@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Mirja Kuehlewind (IETF)" , Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 06:46:43 -0000 On Mon, Mar 20, 2017 at 09:11:06PM +0100, Mirja Kuehlewind (IETF) wrote: > Hi! > > > Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder : > > > > On Mon, Mar 20, 2017 at 05:43:09PM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Jürgen, > >> > >> I’ve read draft-ietf-lmap-information-model first and then this draft, and I was just left with a number of open questions. The simple case where a controller sends a config, the MA does the measurement and send the results to a collector is clear but draft-ietf-lmap-information-model indicates that this is supposed to cover more complex scenarios including more feedback to the controller and things like requesting capabilities. > >> > >> Starting from draft-ietf-lmap-information-model: maybe you can further comment on how the following parts of the information model is covered by the yang model? Thanks! > >> > >> Section 3.9 of draft-ietf-lmap-information-model: > >> "Tasks can be > >> Measurement Tasks (i.e., those Tasks actually performing some type of > >> passive or active measurement) or any other scheduled activity > >> performed by the MA such as transferring information to or from the > >> Controller and Collectors. Other examples of Tasks may include data > >> manipulation or processing Tasks conducted on the MA.“ > >> What „other scheduled activities“? Where are those defined, which information should be transferred, when should they be performed, who decides that, and what’s the purpose here? Also which data should be manipulated or what other processing tasks do you need? > > > > Schedules invoke Actions that execute Tasks. Some tasks may be > > measurement tasks, other tasks may do other things - neither the > > information model nor the data model defines the tasks. The mapping of > > the information model to the data model is explained in the list in > > section 3. I do not see what really is missing or what could be > > unclear. Implementations may use tasks for reporting, implementations > > may use tasks for house keeping, implementations may use tasks for > > aggregation. > > > >> Also > >> "The Task Configuration will include a local short name for reference > >> by a Schedule. Task Configurations may also refer to registry > >> entries as described above. In addition the Task can be configured > >> through a set of configuration Options. The nature and number of > >> these Options will depend upon the Task. „ > >> Can you give an example for an configuration task? Why is an configuration option not sufficient? > > > > There are no configuration tasks. Task Configuration refers to the > > configuration of a task, i.e., a configured task. > > > >> To be honest, I also not fully clear why you need a reporting task because what you need is to configure when the reporting should be done. If that is implemented in the same scheduler than the measurement tasks is an implementation detail and does not need to part of the information model. If it would not be part of the information model than it of course would also not need to be discussed in the yang model. However, as it is I think it would need more guidance when those task should be generated and added to the schedule. > > > > The WG went through a long process to arrive at this solution. I don't > > see what is wrong with it. You want to schedule measurements, you also > > want to schedule the reporting. Treating both as scheduled tasks makes > > the model simpler. Which tasks you want to configure and schedule > > surely depends on the capabilities of an implementation and the > > measurement objectives. I do not think we can provide much guidance on > > this in the information model. > > So I guess all the magic is now hidden in the capabilities. I saw capabilities only as something that describes a measurement, but you say you can also describe other tasks like reporting here. However, including reporting and „other tasks“ in the capabilities, makes it even harder to implement a controller, especially when the controller controls multiple different MAs. Anyway, this connection was missing for me. Maybe that could be make clearer. > The I-D says: 5. Capability and Status Information. Information on the general status and capabilities of the MA. For example, the set of measurements that are supported on the device. And then it says a bit further down in the document: Tasks can implement a variety of different functions. While in terms of the Information Model, all Tasks have the same structure, it can help conceptually to think of different Task categories: 1. Measurement Tasks measure some aspect of network performance or traffic. They may also capture contextual information from the MA device or network interfaces such as the device type or interface speed. 2. Data Transfer Tasks support the communication with a Controller and Collectors: A. Reporting Tasks report the results of Measurement Tasks to Collectors B. Control Task(s) implement the Control Protocol and communicate with the Controller. 3. Data Analysis Tasks can exist to analyse data from other Measurement Tasks locally on the MA 4. Data Management Tasks may exist to clean-up, filter or compress data on the MA such as Measurement Task results > >> In section 3.11.7 > >> " The ma-controller-lost-obj indicates that connectivity to > >> the controller has been lost. This is determined by a timer started > >> after each successful contact with a controller. When the timer > >> reaches the controller-timeout (measured in seconds), an ma- > >> controller-lost-obj event is generated.“ > >> Is there an assumption that the controller should frequently contact the MA, even if there is no config data to send? What’s the right time frame here? > > > > The requirement was to ensure that an MA that is getting disconnected > > from its controller should at some time have a chance to stop its > > activities. This seems reasonable to me. In case the MA is behind a > > NAT (not that unusal), you typically have to call home to let the > > controller update the instructions. How frequently this happens is a > > deployment decision. > > If the MA is behind a NAT, the MA needs to know this and the MA anyway has to connect to the controller. I guess that can be an initial configuration but I guess the MA would also need to expose this to the controller, as a capability…? > I do not understand your question. And I am not sure what you trying to get at with this. > >> In section 3.11.8 > >> "The ma-controller-connected-obj indicates that > >> connectivity to the controller has been established again after it > >> was lost.“ > >> How is connectivity (re-)established? By the MA or by the controller? What does connectivity even mean here? I guess the controller and MA will not have a standing transport connection. It’s rather the controller opens a connection pushes a config and closes the connection, no? An then MA does whatever is configured to do. Why do you need to maintain connectivity? > > > > See above. We want to be able to shutdown MAs when their controller > > disappears. Furthermore, MAs may be behind NATs and in this case they > > have to initiate the connection, not the controller. > > The question was here more, how does the controller know that and how often is has to connect to the client? Capabilities? > ma-config-controller-timeout: A timer is started after each successful contact with a controller. When the timer reaches the controller-timeout (measured in seconds), an event is raised indicating that connectivity to the controller has been lost (see ma-controller- lost-obj). Obvisouly, if you do not want to generate a controller-timeout event, the controller should make sure the value of this object and the connection strategy are reasonably aligned. > >> And 3.5: > >> "The MA will hold Capability Information that can be retrieved by a > >> Controller. Capabilities include the device interface details > >> available to Measurement Tasks as well as the set of Measurement > >> Tasks/Roles (specified by registry entries) that are actually > >> installed or available on the MA. Status information includes the > >> times that operations were last performed such as contacting the > >> Controller or producing Reports.“ > >> When and why will they be retrieved by the controller? How can the controller indicate to the MA to send this information and which? What will the controller do with this information? Also note that Status information is not the same than capabilities. This sounds more like an interactive protocol and not just pushing a config onto a new device. > >> > > > > The controller retrieves this information when he likes to retrieve > > this information. Typically, upon first contact, you like to figure > > out what an MA can do before sending down configuration. Status > > information may help the controller to debug problems or to keep basic > > statistics (percentage of failed measurement execution over time). > > > > I do not know what makes an 'interactive protocol' for you. > > I was thinking about an interactive protocol because if all the magic is hidden in the capabilities, than there seem to be a fixed pattern, where the controller first has to request the capabilities, then the MA sends them, and then the controller sends the actual measurement config. If that’s the envisioned workflow, it would be good to say it somewhere. > Perhaps you want to read of RFC 7594 which has more details about the overall framework. In general, I find reading capabilities first before you attempt to use functionality a pretty common concept. > > But yes, you > > access the YANG model either via RESTCONF (with the usual HTTP methods) > > or via NETCONF (with the usual NETCONF operations). > > > >> These are all comments on draft-ietf-lmap-information-model but I was hoping to find answers to these question in the yang model because that the actual implementation of the protocol. > > > > It is a data model. The protocol primitives are in the RESTCONF / > > NETCONF protocols. There is a separation of protocol aspects from the > > data modeling aspects which seems to be confusing to you (but which we > > have done for decades in the network management space). > > I unterstand this separation but the way you implemented this with having everything as a task in a scheduler blurs the line. With this patter you can in theory describe every (interactive) protocol without actually describing the interactions. > Sorry, I do not understand your comment. > >> Now I also looked at draft-ietf-lmap-restconf-03 which doesn’t not provide a whole lot of additional information and the part I was actually interested in says the following: > >> > >> "5. RESTCONF Configuration for LMAP > >> > >> > >> XXX: This section should explain how an LMAP implementation needs to > >> be configured to make use of the call-home mechanism and how report > >> tasks refer to the configuration (if any standardized) needed to > >> obtain the necessary credentials to report results. This needs to be > >> worked through in detail.“ > >> > > > > This section was supposed to describe how you configure RESTCONF such > > that it works for an MA. This section was not intended to explain how > > you may use RESTCONF to read/write configuration and reports. The way > > we abstract protocol operations from data models seems to be new to > > you. You seem to be searching for a concrete protocol document saying > > if you are in state X send Y and if you receive Z do A. We do not have > > this. With RESTCONF, everything translates into a collection of > > resources you can GET/POST/PUT/PATCH/DELETE and the order in which a > > controller manipulates the resources is up to the implementation of > > the controller. (Slightly simplifying here, there is a notion of > > validity that YANG requires but lets not go there.) > > As said above, I understand the pattern restconf is using but you seem to go slightly beyond this, e.g. assuming a certain pattern where capabilities are retrieved first without every talking about this assumption. If you want, you can write a controller that does not care about capabilities but then it will likely often have to deal with failures. > I think further clarifying what capabilities are, could help; not sure in which document that should actually be done. I do not see this need. I do not understand what your concern is. /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 Mar 21 01:15:30 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2FD129680; Tue, 21 Mar 2017 01:15:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149008412875.25070.13347458064665806770.idtracker@ietfa.amsl.com> Date: Tue, 21 Mar 2017 01:15:28 -0700 Archived-At: Subject: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-lmap-yang-11=3A_=28with_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:15:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lmap-yang-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the feedback! Still some comments: - Maybe make RFC7594 a normative reference. - It could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make sure that it reconnects frequently based on the timeout configuration of the MA. If the MA e.g. is behind a NAT, the MA must establish the initial connection and try to reconnect when the timeout expires. Btw. is it enough to open a transport connection or do you mean by checking connectivity that there also should be some data transmitted to ensure that the controller is no only reachable but also active? - I still think there might be further information needed on bootstrapping. This draft only says: "Pre-Configuration Information: This is not modeled explicitly since bootstrapping information is outside the scope of this data model." From nobody Tue Mar 21 01:18:05 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030B12965D for ; Tue, 21 Mar 2017 01:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0MoC3F-Rq_E for ; Tue, 21 Mar 2017 01:17:57 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56065129687 for ; Tue, 21 Mar 2017 01:17:54 -0700 (PDT) Received: (qmail 11370 invoked from network); 21 Mar 2017 09:11:11 +0100 Received: from p5dec295b.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.41.91) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 21 Mar 2017 09:11:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20170321064636.GA34900@elstar.local> Date: Tue, 21 Mar 2017 09:11:09 +0100 Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 08:17:59 -0000 Hi J=C3=BCrgen, thanks for you replies. I went back an had another look at the framework = document which answered some of my questions. I guess the minimum you = can do is to make the reference to RFC7594 normative (as well as the = reference to I-D.ietf-lmap-information-model as Benoit mentioned in this = comment). I guess without trying to implement it, I will not be able to = figure out if there is anything missing or if I=E2=80=99m missing = something and as such I will clear my discuss now. I still think that it could be good to give some further guidance on how = connectivity is established. Something like, in most cases the = controller will connect the MA and the controller should make sure that = it reconnects frequently based on the timeout configuration of the MA. = If the MA e.g. is behind a NAT, the MA must establish the initial = connection and try to reconnect when the timeout expires. Btw. is it = enough to open a transport connection or do you mean by checking = connectivity that there also should be some data transmitted to ensure = that the controller is no only reachable but also active? Mirja > Am 21.03.2017 um 07:46 schrieb Juergen Schoenwaelder = : >=20 > On Mon, Mar 20, 2017 at 09:11:06PM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi! >>=20 >>> Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder = : >>>=20 >>> On Mon, Mar 20, 2017 at 05:43:09PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>> Hi J=C3=BCrgen, >>>>=20 >>>> I=E2=80=99ve read draft-ietf-lmap-information-model first and then = this draft, and I was just left with a number of open questions. The = simple case where a controller sends a config, the MA does the = measurement and send the results to a collector is clear but = draft-ietf-lmap-information-model indicates that this is supposed to = cover more complex scenarios including more feedback to the controller = and things like requesting capabilities. >>>>=20 >>>> Starting from draft-ietf-lmap-information-model: maybe you can = further comment on how the following parts of the information model is = covered by the yang model? Thanks! >>>>=20 >>>> Section 3.9 of draft-ietf-lmap-information-model: >>>> "Tasks can be >>>> Measurement Tasks (i.e., those Tasks actually performing some type = of >>>> passive or active measurement) or any other scheduled activity >>>> performed by the MA such as transferring information to or from the >>>> Controller and Collectors. Other examples of Tasks may include = data >>>> manipulation or processing Tasks conducted on the MA.=E2=80=9C >>>> What =E2=80=9Eother scheduled activities=E2=80=9C? Where are those = defined, which information should be transferred, when should they be = performed, who decides that, and what=E2=80=99s the purpose here? Also = which data should be manipulated or what other processing tasks do you = need? >>>=20 >>> Schedules invoke Actions that execute Tasks. Some tasks may be >>> measurement tasks, other tasks may do other things - neither the >>> information model nor the data model defines the tasks. The mapping = of >>> the information model to the data model is explained in the list in >>> section 3. I do not see what really is missing or what could be >>> unclear. Implementations may use tasks for reporting, = implementations >>> may use tasks for house keeping, implementations may use tasks for >>> aggregation. >>>=20 >>>> Also >>>> "The Task Configuration will include a local short name for = reference >>>> by a Schedule. Task Configurations may also refer to registry >>>> entries as described above. In addition the Task can be configured >>>> through a set of configuration Options. The nature and number of >>>> these Options will depend upon the Task. =E2=80=9E >>>> Can you give an example for an configuration task? Why is an = configuration option not sufficient? >>>=20 >>> There are no configuration tasks. Task Configuration refers to the >>> configuration of a task, i.e., a configured task. >>>=20 >>>> To be honest, I also not fully clear why you need a reporting task = because what you need is to configure when the reporting should be done. = If that is implemented in the same scheduler than the measurement tasks = is an implementation detail and does not need to part of the information = model. If it would not be part of the information model than it of = course would also not need to be discussed in the yang model. However, = as it is I think it would need more guidance when those task should be = generated and added to the schedule. >>>=20 >>> The WG went through a long process to arrive at this solution. I = don't >>> see what is wrong with it. You want to schedule measurements, you = also >>> want to schedule the reporting. Treating both as scheduled tasks = makes >>> the model simpler. Which tasks you want to configure and schedule >>> surely depends on the capabilities of an implementation and the >>> measurement objectives. I do not think we can provide much guidance = on >>> this in the information model. >>=20 >> So I guess all the magic is now hidden in the capabilities. I saw = capabilities only as something that describes a measurement, but you say = you can also describe other tasks like reporting here. However, = including reporting and =E2=80=9Eother tasks=E2=80=9C in the = capabilities, makes it even harder to implement a controller, especially = when the controller controls multiple different MAs. Anyway, this = connection was missing for me. Maybe that could be make clearer. >>=20 >=20 > The I-D says: >=20 > 5. Capability and Status Information. Information on the general > status and capabilities of the MA. For example, the set of > measurements that are supported on the device. >=20 > And then it says a bit further down in the document: >=20 > Tasks can implement a variety of different functions. While in = terms > of the Information Model, all Tasks have the same structure, it can > help conceptually to think of different Task categories: >=20 > 1. Measurement Tasks measure some aspect of network performance or > traffic. They may also capture contextual information from the > MA device or network interfaces such as the device type or > interface speed. >=20 > 2. Data Transfer Tasks support the communication with a Controller > and Collectors: >=20 > A. Reporting Tasks report the results of Measurement Tasks to > Collectors >=20 > B. Control Task(s) implement the Control Protocol and > communicate with the Controller. >=20 > 3. Data Analysis Tasks can exist to analyse data from other > Measurement Tasks locally on the MA >=20 > 4. Data Management Tasks may exist to clean-up, filter or compress > data on the MA such as Measurement Task results >=20 >>>> In section 3.11.7 >>>> " The ma-controller-lost-obj indicates that connectivity to >>>> the controller has been lost. This is determined by a timer = started >>>> after each successful contact with a controller. When the timer >>>> reaches the controller-timeout (measured in seconds), an ma- >>>> controller-lost-obj event is generated.=E2=80=9C >>>> Is there an assumption that the controller should frequently = contact the MA, even if there is no config data to send? What=E2=80=99s = the right time frame here? >>>=20 >>> The requirement was to ensure that an MA that is getting = disconnected >>> from its controller should at some time have a chance to stop its >>> activities. This seems reasonable to me. In case the MA is behind a >>> NAT (not that unusal), you typically have to call home to let the >>> controller update the instructions. How frequently this happens is a >>> deployment decision. >>=20 >> If the MA is behind a NAT, the MA needs to know this and the MA = anyway has to connect to the controller. I guess that can be an initial = configuration but I guess the MA would also need to expose this to the = controller, as a capability=E2=80=A6? >>=20 >=20 > I do not understand your question. And I am not sure what you trying > to get at with this. >=20 >>>> In section 3.11.8 >>>> "The ma-controller-connected-obj indicates that >>>> connectivity to the controller has been established again after it >>>> was lost.=E2=80=9C >>>> How is connectivity (re-)established? By the MA or by the = controller? What does connectivity even mean here? I guess the = controller and MA will not have a standing transport connection. It=E2=80=99= s rather the controller opens a connection pushes a config and closes = the connection, no? An then MA does whatever is configured to do. Why do = you need to maintain connectivity? >>>=20 >>> See above. We want to be able to shutdown MAs when their controller >>> disappears. Furthermore, MAs may be behind NATs and in this case = they >>> have to initiate the connection, not the controller. >>=20 >> The question was here more, how does the controller know that and how = often is has to connect to the client? Capabilities? >>=20 >=20 > ma-config-controller-timeout: A timer is started after each > successful contact with a > controller. When the timer > reaches the controller-timeout > (measured in seconds), an event > is raised indicating that > connectivity to the controller > has been lost (see = ma-controller- > lost-obj). >=20 > Obvisouly, if you do not want to generate a controller-timeout event, > the controller should make sure the value of this object and the > connection strategy are reasonably aligned. >=20 >>>> And 3.5: >>>> "The MA will hold Capability Information that can be retrieved by a >>>> Controller. Capabilities include the device interface details >>>> available to Measurement Tasks as well as the set of Measurement >>>> Tasks/Roles (specified by registry entries) that are actually >>>> installed or available on the MA. Status information includes the >>>> times that operations were last performed such as contacting the >>>> Controller or producing Reports.=E2=80=9C >>>> When and why will they be retrieved by the controller? How can the = controller indicate to the MA to send this information and which? What = will the controller do with this information? Also note that Status = information is not the same than capabilities. This sounds more like an = interactive protocol and not just pushing a config onto a new device. >>>>=20 >>>=20 >>> The controller retrieves this information when he likes to retrieve >>> this information. Typically, upon first contact, you like to figure >>> out what an MA can do before sending down configuration. Status >>> information may help the controller to debug problems or to keep = basic >>> statistics (percentage of failed measurement execution over time). >>>=20 >>> I do not know what makes an 'interactive protocol' for you. >>=20 >> I was thinking about an interactive protocol because if all the magic = is hidden in the capabilities, than there seem to be a fixed pattern, = where the controller first has to request the capabilities, then the MA = sends them, and then the controller sends the actual measurement config. = If that=E2=80=99s the envisioned workflow, it would be good to say it = somewhere. >>=20 >=20 > Perhaps you want to read of RFC 7594 which has more details about the > overall framework. In general, I find reading capabilities first > before you attempt to use functionality a pretty common concept. >=20 >>> But yes, you >>> access the YANG model either via RESTCONF (with the usual HTTP = methods) >>> or via NETCONF (with the usual NETCONF operations). >>>=20 >>>> These are all comments on draft-ietf-lmap-information-model but I = was hoping to find answers to these question in the yang model because = that the actual implementation of the protocol. >>>=20 >>> It is a data model. The protocol primitives are in the RESTCONF / >>> NETCONF protocols. There is a separation of protocol aspects from = the >>> data modeling aspects which seems to be confusing to you (but which = we >>> have done for decades in the network management space). >>=20 >> I unterstand this separation but the way you implemented this with = having everything as a task in a scheduler blurs the line. With this = patter you can in theory describe every (interactive) protocol without = actually describing the interactions. >>=20 >=20 > Sorry, I do not understand your comment. >=20 >>>> Now I also looked at draft-ietf-lmap-restconf-03 which doesn=E2=80=99= t not provide a whole lot of additional information and the part I was = actually interested in says the following: >>>>=20 >>>> "5. RESTCONF Configuration for LMAP >>>>=20 >>>>=20 >>>> XXX: This section should explain how an LMAP implementation needs = to >>>> be configured to make use of the call-home mechanism and how report >>>> tasks refer to the configuration (if any standardized) needed to >>>> obtain the necessary credentials to report results. This needs to = be >>>> worked through in detail.=E2=80=9C >>>>=20 >>>=20 >>> This section was supposed to describe how you configure RESTCONF = such >>> that it works for an MA. This section was not intended to explain = how >>> you may use RESTCONF to read/write configuration and reports. The = way >>> we abstract protocol operations from data models seems to be new to >>> you. You seem to be searching for a concrete protocol document = saying >>> if you are in state X send Y and if you receive Z do A. We do not = have >>> this. With RESTCONF, everything translates into a collection of >>> resources you can GET/POST/PUT/PATCH/DELETE and the order in which a >>> controller manipulates the resources is up to the implementation of >>> the controller. (Slightly simplifying here, there is a notion of >>> validity that YANG requires but lets not go there.) >>=20 >> As said above, I understand the pattern restconf is using but you = seem to go slightly beyond this, e.g. assuming a certain pattern where = capabilities are retrieved first without every talking about this = assumption. >=20 > If you want, you can write a controller that does not care about > capabilities but then it will likely often have to deal with > failures. >=20 >> I think further clarifying what capabilities are, could help; not = sure in which document that should actually be done. >=20 > I do not see this need. I do not understand what your concern is. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Tue Mar 21 04:55:29 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9D1297BE; Tue, 21 Mar 2017 04:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SoPczLcXgza; Tue, 21 Mar 2017 04:55: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 DBEE71297A5; Tue, 21 Mar 2017 04:55: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 A981C6BA; Tue, 21 Mar 2017 12:55:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a_XFRkgiGZP2; Tue, 21 Mar 2017 12:55:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 12:55:18 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FF5520038; Tue, 21 Mar 2017 12:55:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M3WtSYLILZrl; Tue, 21 Mar 2017 12:55:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B35D720036; Tue, 21 Mar 2017 12:55:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59EAA3EF125C; Tue, 21 Mar 2017 12:55:22 +0100 (CET) Date: Tue, 21 Mar 2017 12:55:22 +0100 From: Juergen Schoenwaelder To: "Mirja Kuehlewind (IETF)" Cc: Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Message-ID: <20170321115522.GA35872@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Mirja Kuehlewind (IETF)" , Dan Romascanu , lmap-chairs@ietf.org, The IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 11:55:22 -0000 On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Jürgen, > > thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (as well as the reference to I-D.ietf-lmap-information-model as Benoit mentioned in this comment). I guess without trying to implement it, I will not be able to figure out if there is anything missing or if I’m missing something and as such I will clear my discuss now. To me, it feels a bit strange to make RFC 7594 normative but if there is IESG consensus that RFC 7594 should be normative I will implement the change and hold my breath. > I still think that it could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make sure that it reconnects frequently based on the timeout configuration of the MA. If the MA e.g. is behind a NAT, the MA must establish the initial connection and try to reconnect when the timeout expires. Btw. is it enough to open a transport connection or do you mean by checking connectivity that there also should be some data transmitted to ensure that the controller is no only reachable but also active? Depends to some extend on the protocol used. I think it is more than a TCP connection, you also need to successfully authenticate (I think). And then some protocols immediately become chatty - NETCONF has a exchange, with RESTCONF things could be silent but I would assume a controller will likely fetch some status information. (When you kid returns home, you likely ask how it is doing. ;-) /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 Mar 21 06:05:39 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255012984B; Tue, 21 Mar 2017 06:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Mc8CEWX2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c5crFF/l 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 be28tGK2qeMD; Tue, 21 Mar 2017 06:05:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF9A129445; Tue, 21 Mar 2017 06:05:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 482F120C55; Tue, 21 Mar 2017 09:05:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 21 Mar 2017 09:05:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=bQcf2ZM9hSYWVbaiu8 0RpwTq/Bfxq/lTFj8tJA/76+k=; b=Mc8CEWX2Nl8aNAjr8X/iEXmYeQL+IsYFoL yUAl+G+YuAve6jspey6fNAugKWxed8XjcKPkULd1CnaQG4fDx5ad+npEFD7Z+ZEl 6JuoreLG3JO6sMZ4FxWl2Z1KTplW5o8Ec27VIGck8VOa4CxdkLjCmMnp7wu6ZbIr bE8/sPzbKpecRxor/iIvRpytd3PF1dbepZ9ub93p6HQlbS6uaX2hn/BqIN/0KlVt uLjtK7sjBz2j9VoFoKLAOY+Lgp5oZbvYcDEr+zefZqyzjL9dWzIN4SNgklWV5tql 29J+WthBGLXwltFDFWeWnAfGpqp5BU2Pzl9TsgwPDK67IvSshoUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=bQcf2ZM9hSYWVbaiu80RpwTq/Bfxq/lTFj8tJA/76+k=; b=c5crFF/l VWiqNNzFq7coysUutCDz7oJ2ioGHAkN+1NL+DiX22Q7UQsf3U+H0iVM1XT5/pqpz OoCr0suRaMGkCb66JdiWyB2S6Hk8b2HPmo9lunP8QKJ3O+yIPZVuPp9qWW/GlS8j YItyhwpLRGdUbXMOYUK4IiZUfBrNMQR+XMsNALxISk5p+Y7FTTL9mecGmPgdiIuQ xSioKxJEaK2sWKMUy5jIhIuI+Y9NNgRxVr/KmVZXbZxRETWvWw46vZIa28xDquks 2cEIQTWvsu4tj0gQUeIDT1Kr73fjgCPfvg4n04oOnPyxcBfUshcuN1bzq1AOl/qU 2ol3L880Xi7Law== X-ME-Sender: X-Sasl-enc: 13MzOQvfv8WBCBiAn8MqNVOZdcBNTr7BN6Eln084Su7d 1490101531 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.164]) by mail.messagingengine.com (Postfix) with ESMTPA id DEEA07E334; Tue, 21 Mar 2017 09:05:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170321115522.GA35872@elstar.local> Date: Tue, 21 Mar 2017 09:05:29 -0400 Cc: "Mirja Kuehlewind (IETF)" , Dan Romascanu , lmap-chairs@ietf.org, IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> <20170321115522.GA35872@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 13:05:37 -0000 > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi J=C3=BCrgen, >>=20 >> thanks for you replies. I went back an had another look at the = framework document which answered some of my questions. I guess the = minimum you can do is to make the reference to RFC7594 normative (as = well as the reference to I-D.ietf-lmap-information-model as Benoit = mentioned in this comment). I guess without trying to implement it, I = will not be able to figure out if there is anything missing or if I=E2=80=99= m missing something and as such I will clear my discuss now. >=20 > To me, it feels a bit strange to make RFC 7594 normative I agree, there is nothing specified in RFC 7594 that needs to be = implemented in order for the YANG model to be implementable. Alissa > but if there > is IESG consensus that RFC 7594 should be normative I will implement > the change and hold my breath. >=20 >> I still think that it could be good to give some further guidance on = how connectivity is established. Something like, in most cases the = controller will connect the MA and the controller should make sure that = it reconnects frequently based on the timeout configuration of the MA. = If the MA e.g. is behind a NAT, the MA must establish the initial = connection and try to reconnect when the timeout expires. Btw. is it = enough to open a transport connection or do you mean by checking = connectivity that there also should be some data transmitted to ensure = that the controller is no only reachable but also active? >=20 > Depends to some extend on the protocol used. I think it is more than a > TCP connection, you also need to successfully authenticate (I > think). And then some protocols immediately become chatty - NETCONF > has a exchange, with RESTCONF things could be silent but I > would assume a controller will likely fetch some status information. > (When you kid returns home, you likely ask how it is doing. ;-) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Tue Mar 21 07:50:39 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471FF12995B; Tue, 21 Mar 2017 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo4x9mcnFpaO; Tue, 21 Mar 2017 07:50:32 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8EE12949B; Tue, 21 Mar 2017 07:50:32 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id i34so132797118qtc.0; Tue, 21 Mar 2017 07:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t7L8Y0WdrrnAehv/Fo5azPyk5iSYddbylljlCHeLcdM=; b=CoT1xrkZIHqpREjVopqX+EqXg4PyoooKpccgfG4YrxUdGrBPC+MNcROi6YRV+vt8Jl rbddDAtPKpY0FGG064XxVI07jB6rEXdzLrm7kF8H22Xwe2XN79ZJP5OublN1+Jei05cw NUTFli02gzMFvm8rK9dyTzWQ+yrmARl9kCdO8YQoX9mesIJWc6X3oB/ByYD+5pT2LkrB dBqqZG2wnFLMjnSYmM1942TJSs8k1c1ynhnoAfDcmuKxyztwCBj7pMZBq9Dlivt52v7W vBUhIkcnOWHvFoJaJgqUfD/8GkMRWo3/O23DnQgCtNZ5ySwIywqSz4I5+Vis5xUWINjr jIBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t7L8Y0WdrrnAehv/Fo5azPyk5iSYddbylljlCHeLcdM=; b=RWjcjRf1FbDHBivYaFjCR+obLXWGEUGREVuZ7xDlzxZnwH1LF6ECx9PElg5IZ7lTB9 LOKHJPDjNe7P59SsNkGuUlEdUvoN1F0fGT8qUibubyzI9GqrHL3LRfdl5q4vm9FatOVD 1OG5Jb0EpcOlsbiJgD2TOzrwg6TTdTUceBrwQ3UCAKSiblwCRl+JKJHPRf3abtQ/iiiS +lhLp9uUcm4NUpde0c8HBMnutNyH6Y/yBinXjZqdwQQgvTu3ft/ClzH9IeddGeRCqPUe AczZ0hxiLsUOiWk7A2X6+CAFaPhTwY/g/OE410HuG5edNr/KXAtgHxGmHJOEp8XVERrt cMVA== X-Gm-Message-State: AFeK/H0Adg+0+c9f8DhvywnS7Aw2bB9OYUIEDCncAKF0YjNWW1dyzgMTnTKIxO1RvD+qaOnzNaNgnPe5oKj1EQ== X-Received: by 10.200.44.235 with SMTP id 40mr31799022qtx.178.1490107831505; Tue, 21 Mar 2017 07:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.41.170 with HTTP; Tue, 21 Mar 2017 07:50:31 -0700 (PDT) In-Reply-To: <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> <20170321115522.GA35872@elstar.local> <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in> From: Dan Romascanu Date: Tue, 21 Mar 2017 16:50:31 +0200 Message-ID: To: Alissa Cooper Cc: Juergen Schoenwaelder , "Mirja Kuehlewind (IETF)" , lmap-chairs@ietf.org, IESG , draft-ietf-lmap-yang@ietf.org, lmap@ietf.org Content-Type: multipart/alternative; boundary=001a1135aaacf95a15054b3ec363 Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 14:50:34 -0000 --001a1135aaacf95a15054b3ec363 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper wrote: > > > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) wrote= : > >> Hi J=C3=BCrgen, > >> > >> thanks for you replies. I went back an had another look at the > framework document which answered some of my questions. I guess the minim= um > you can do is to make the reference to RFC7594 normative (as well as the > reference to I-D.ietf-lmap-information-model as Benoit mentioned in this > comment). I guess without trying to implement it, I will not be able to > figure out if there is anything missing or if I=E2=80=99m missing somethi= ng and as > such I will clear my discuss now. > > > > To me, it feels a bit strange to make RFC 7594 normative > > I agree, there is nothing specified in RFC 7594 that needs to be > implemented in order for the YANG model to be implementable. > > Alissa > > > but if there > > is IESG consensus that RFC 7594 should be normative I will implement > > the change and hold my breath. > > > My 2 agorot as WG co-chair: Making 7594 normative looks to me different that our usual practice for normative references, however, if this is the last obstacle between this document and its approval I would hold my breath as well. Regards, Dan --001a1135aaacf95a15054b3ec363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper <alissa@cooperw.in&= gt; wrote:

> On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univer= sity.de> wrote:
>
> On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) wrot= e:
>> Hi J=C3=BCrgen,
>>
>> thanks for you replies. I went back an had another look at the fra= mework document which answered some of my questions. I guess the minimum yo= u can do is to make the reference to RFC7594 normative (as well as the refe= rence to I-D.ietf-lmap-information-model as Benoit mentioned in this c= omment). I guess without trying to implement it, I will not be able to figu= re out if there is anything missing or if I=E2=80=99m missing something and= as such I will clear my discuss now.
>
> To me, it feels a bit strange to make RFC 7594 normative

I agree, there is nothing specified in RFC 7594 that needs to be imp= lemented in order for the YANG model to be implementable.

Alissa

> but if there
> is IESG consensus that RFC 7594 should be normative I will implement > the change and hold my breath.
>

My 2 agorot as WG co-c= hair: Making 7594 normative looks to me different that our usual practice f= or normative references, however, if this is the last obstacle between this= document and its approval I would hold my breath as well.

Regards,

Dan
=C2=A0
--001a1135aaacf95a15054b3ec363-- From nobody Tue Mar 21 08:11:23 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3191296FA for ; Tue, 21 Mar 2017 08:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVm9dLZnBQ67 for ; Tue, 21 Mar 2017 08:11:20 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA4129A0F for ; Tue, 21 Mar 2017 08:11:17 -0700 (PDT) Received: (qmail 32364 invoked from network); 21 Mar 2017 16:04:33 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 21 Mar 2017 16:04:33 +0100 To: Dan Romascanu , Alissa Cooper References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> <20170321115522.GA35872@elstar.local> <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in> Cc: lmap-chairs@ietf.org, lmap@ietf.org, Juergen Schoenwaelder , "Mirja Kuehlewind (IETF)" , IESG , draft-ietf-lmap-yang@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <7f7361e1-7ce5-d7fb-74c3-b73b5ca964d6@kuehlewind.net> Date: Tue, 21 Mar 2017 16:04:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 15:11:22 -0000 I cleared my discuss, so there is no obstacle here that blocks publication. I strongly agree with Benoit that this draft needs at least a normative reference to I-D.ietf-lmap-information-model. And similar as the reference to the information model, I had the feeling that you also need to read at least parts of RFC7594 to understand the terms, processes and goals in this document correctly. It's on you to decide. This is only my recommendation as a potential consumer. Not sure what your usual practice is but for normative reference the only question that relevant is: does the reader need to read the referenced document to fully understand the content of this document? Mirja On 21.03.2017 15:50, Dan Romascanu wrote: > > > On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper > wrote: > > > > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder > wrote: > > > > On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Jürgen, > >> > >> thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (as well as the reference to I-D.ietf-lmap-information-model as Benoit mentioned in this comment). I guess without trying to > implement it, I will not be able to figure out if there is anything > missing or if I’m missing something and as such I will clear my discuss now. > > > > To me, it feels a bit strange to make RFC 7594 normative > > I agree, there is nothing specified in RFC 7594 that needs to be > implemented in order for the YANG model to be implementable. > > Alissa > > > but if there > > is IESG consensus that RFC 7594 should be normative I will implement > > the change and hold my breath. > > > > > My 2 agorot as WG co-chair: Making 7594 normative looks to me different that > our usual practice for normative references, however, if this is the last > obstacle between this document and its approval I would hold my breath as well. > > Regards, > > Dan > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Tue Mar 21 08:16:14 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17820129A30; Tue, 21 Mar 2017 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT5DxFK5MFL0; Tue, 21 Mar 2017 08:16:01 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD99129A23; Tue, 21 Mar 2017 08:16:00 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x35so133064959qtc.2; Tue, 21 Mar 2017 08:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z9D8/V7kCDnp67XrsfbwWaSCQiah0yFealhKqErqvKE=; b=krcdxMYGxUhtVjfz3BzOEOE+p6523hcfAvWza/VgPfLvjVEqBsFn5a46VMAL06lfMF ahq3NDQ1k5EUS7M+1yG7rosxgB0bBShslVHV0e0V8ZIiZokXpNJq9Rkg9gPlRBev1z4T UKd4tRZRsfkm90EGIPRSIJ0wsEIX08Wl5M/9exZDUT00pgMGS5k9F5DiIY3zwlDudBLc RuX8E6H8/6lU3zFBBmK4lCt7tt+3lfYrKK2zxxheefowz8+GUUZU2EaQrvTPqgYwJGON lcNvvjX9AWJXSSuINbG6YN39oyNsuPTOeyQyEf8MRs4PQx715bAUAoEQ0WW39ZqnTIg+ DScw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z9D8/V7kCDnp67XrsfbwWaSCQiah0yFealhKqErqvKE=; b=PI8zBX3Oxuqa9aQBi0HINvvXp0R4wdCMGlEw1kQ0DjT9rzKGAVGYYTC/Yg5SmtEqVg 0XgWvBVOlIOTygRxkZIGaAz2h3IBKE/n+FhLrALoFCUI9SVCJsHBmxgxiKi0aiPct7GT Atclvpwjzr7w8gT48/IboGbjcVihD2zljiV9M1CtjkX4CEm6H7fCq1hW9e59us1DDN61 vpt3Ym7XaBQV0Q38uQL0WlCiAl1lFUUhsF+s/wjYMB7/Uj5dv056RZbtXIJde32ftGx0 v4UokjlfSOjWhCVyzjXf5/y+FmT4MHP0OXVLXIWmkPk8Q74JxhYixNZmRVMegig+eG78 QTxg== X-Gm-Message-State: AFeK/H0JYsW/y9FMlAUNP0SsttbF9ZK7xi4Hyc9Ef7cZjm+rsTbMmnXoi5YPM55buO/R5pykrzr5fVk8lyw6uQ== X-Received: by 10.200.51.199 with SMTP id d7mr31633450qtb.94.1490109359581; Tue, 21 Mar 2017 08:15:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.41.170 with HTTP; Tue, 21 Mar 2017 08:15:58 -0700 (PDT) In-Reply-To: <7f7361e1-7ce5-d7fb-74c3-b73b5ca964d6@kuehlewind.net> References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> <20170321115522.GA35872@elstar.local> <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in> <7f7361e1-7ce5-d7fb-74c3-b73b5ca964d6@kuehlewind.net> From: Dan Romascanu Date: Tue, 21 Mar 2017 17:15:58 +0200 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Alissa Cooper , lmap-chairs@ietf.org, lmap@ietf.org, Juergen Schoenwaelder , IESG , draft-ietf-lmap-yang@ietf.org Content-Type: multipart/alternative; boundary=001a114541de0e1abf054b3f1f09 Archived-At: Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 15:16:04 -0000 --001a114541de0e1abf054b3f1f09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for clearing, Mirja. I actually agree with your statement about normative references, but I believe that the relationship of this document with the informational framework RFC is different than the relationship with the information model mentioned in Benoit's comment. Regards, Dan On Tue, Mar 21, 2017 at 5:04 PM, Mirja K=C3=BChlewind wrote: > I cleared my discuss, so there is no obstacle here that blocks > publication. I strongly agree with Benoit that this draft needs at least = a > normative reference to I-D.ietf-lmap-information-model. And similar as > the reference to the information model, I had the feeling that you also > need to read at least parts of RFC7594 to understand the terms, processes > and goals in this document correctly. It's on you to decide. This is only > my recommendation as a potential consumer. Not sure what your usual > practice is but for normative reference the only question that relevant i= s: > does the reader need to read the referenced document to fully understand > the content of this document? > > Mirja > > > On 21.03.2017 15:50, Dan Romascanu wrote: > >> >> >> On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper > > wrote: >> >> >> > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de >> > wrote: >> > >> > On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) >> wrote: >> >> Hi J=C3=BCrgen, >> >> >> >> thanks for you replies. I went back an had another look at the >> framework document which answered some of my questions. I guess the mini= mum >> you can do is to make the reference to RFC7594 normative (as well as the >> reference to I-D.ietf-lmap-information-model as Benoit mentioned in this >> comment). I guess without trying to >> implement it, I will not be able to figure out if there is anything >> missing or if I=E2=80=99m missing something and as such I will clear= my >> discuss now. >> > >> > To me, it feels a bit strange to make RFC 7594 normative >> >> I agree, there is nothing specified in RFC 7594 that needs to be >> implemented in order for the YANG model to be implementable. >> >> Alissa >> >> > but if there >> > is IESG consensus that RFC 7594 should be normative I will impleme= nt >> > the change and hold my breath. >> > >> >> >> My 2 agorot as WG co-chair: Making 7594 normative looks to me different >> that >> our usual practice for normative references, however, if this is the las= t >> obstacle between this document and its approval I would hold my breath a= s >> well. >> >> Regards, >> >> Dan >> >> >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >> >> --001a114541de0e1abf054b3f1f09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for clearing, Mirja.

I = actually agree with your statement about normative references, but I believ= e that the relationship of this document with the informational framework R= FC is different than the relationship with the information model mentioned = in Benoit's comment.

Regards,

Dan


On Tue, Ma= r 21, 2017 at 5:04 PM, Mirja K=C3=BChlewind <ietf@kuehlewind.net&g= t; wrote:
I cleared my discuss, so= there is no obstacle here that blocks publication. I strongly agree with B= enoit that this draft needs at least a normative reference to I-D.ietf-lmap= -information-model. And similar as the reference to the information mo= del, I had the feeling that you also need to read at least parts of RFC7594= to understand the terms, processes and goals in this document correctly. I= t's on you to decide. This is only my recommendation as a potential con= sumer. Not sure what your usual practice is but for normative reference the= only question that relevant is: does the reader need to read the reference= d document to fully understand the content of this document?

Mirja


On 21.03.2017 15:50, Dan Romascanu wrote:


On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper <alissa@cooperw.in
 <mailto:alissa@co= operw.in>> wrote:


=C2=A0 =C2=A0 > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <<= a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D"_blank">j.= schoenwaelder@jacobs-university.de
 =C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-university.de>&g= t; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewi= nd (IETF) wrote:
=C2=A0 =C2=A0 >> Hi J=C3=BCrgen,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> thanks for you replies. I went back an had another l= ook at the framework document which answered some of my questions. I guess = the minimum you can do is to make the reference to RFC7594 normative (as we= ll as the reference to I-D.ietf-lmap-information-model as Benoit menti= oned in this comment). I guess without trying to
=C2=A0 =C2=A0 implement it, I will not be able to figure out if there is an= ything
=C2=A0 =C2=A0 missing or if I=E2=80=99m missing something and as such I wil= l clear my discuss now.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > To me, it feels a bit strange to make RFC 7594 normative=

=C2=A0 =C2=A0 I agree, there is nothing specified in RFC 7594 that needs to= be
=C2=A0 =C2=A0 implemented in order for the YANG model to be implementable.<= br>
=C2=A0 =C2=A0 Alissa

=C2=A0 =C2=A0 > but if there
=C2=A0 =C2=A0 > is IESG consensus that RFC 7594 should be normative I wi= ll implement
=C2=A0 =C2=A0 > the change and hold my breath.
=C2=A0 =C2=A0 >


My 2 agorot as WG co-chair: Making 7594 normative looks to me different tha= t
our usual practice for normative references, however, if this is the last obstacle between this document and its approval I would hold my breath as w= ell.

Regards,

Dan



 _______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap


--001a114541de0e1abf054b3f1f09-- From nobody Thu Mar 23 12:11:01 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0EB129BEF; Thu, 23 Mar 2017 12:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o15LKZL4QzlK; Thu, 23 Mar 2017 12:10:51 -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 55310131620; Thu, 23 Mar 2017 12:10:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C957151F; Thu, 23 Mar 2017 20:10:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WJksmzY_41jj; Thu, 23 Mar 2017 20:10:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Mar 2017 20:10:48 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE1E72002B; Thu, 23 Mar 2017 20:10:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l8YDMcGxiO39; Thu, 23 Mar 2017 20:10:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79CB720014; Thu, 23 Mar 2017 20:10:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 75DAC3EF789D; Thu, 23 Mar 2017 20:10:53 +0100 (CET) Date: Thu, 23 Mar 2017 20:10:53 +0100 From: Juergen Schoenwaelder To: Benoit Claise Cc: The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org Message-ID: <20170323191053.GA41468@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , The IESG , draft-ietf-lmap-yang@ietf.org, Dan Romascanu , lmap-chairs@ietf.org, lmap@ietf.org References: <148967599467.14149.3188235856151065534.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148967599467.14149.3188235856151065534.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Benoit Claise's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 19:10:53 -0000 On Thu, Mar 16, 2017 at 07:53:14AM -0700, Benoit Claise wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As agreed during the IESG telechat, holding a DISCUSS until the new YANG > security considerations template including RESTCONF is agreed upon. > I have updated the document to use the wording posted by Benoit to the NETMOD list on March 16: https://www.ietf.org/mail-archive/web/netmod/current/msg17890.html Benoit, does this resolve the issue? The updated I-Ds and the diffs can be found here: http://beadg.de/lmap/ /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 Mar 28 15:00:02 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE67D12955A for ; Tue, 28 Mar 2017 15:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=aPuq893W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qRtjHROC 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 NytJCyMO_iKa for ; Tue, 28 Mar 2017 14:59:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13495129674 for ; Tue, 28 Mar 2017 14:59:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 82FEA20C26; Tue, 28 Mar 2017 17:59:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 28 Mar 2017 17:59:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=6kWZL08XCTuaBvJb4dBTHcbQB4G8RUxINRA4vKgbo zI=; b=aPuq893WAX6cqkOES6hZUYzG7XEIURQpSUOjpNDLfYJ7mVt949wwiIuci 6b9sp/5J8HYzrFk9H6E81VEDwqr7AeHxBx/n2UQdcAhk5kutC7kvrdOQswIWtY2Z Pe/xQ9YxhmKDBe3JpmHR1FJRYATfx4BdJHy6L+cdROpf68wAZJOjGvwlFo2X9RxN TzxxtfeLjfhEnYiJh6eqAGLtpbdf9G/KyljpVAS7bsKHeezv532kkyhok771woCA 4zZQfiGYZxCU3aFVLCXw5hrBOJw25TYs2XDPx2zjczcUpHkeqKShgc7/AaI+2/a4 8V6V/O0/ainkDBGBXRNFHYdkdTzxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=6kWZL08XCTuaBvJb4d BTHcbQB4G8RUxINRA4vKgbozI=; b=qRtjHROCsMLANwspsU2LS1g3jD+nIcqsLy 2J43hqcZHG/qkvtMSIuqtBujToSHIQKAR3O7/j5Ct/vVvWFvpByXFh9e/rI9Y5yo zIJ6kmddBUAltrVd26D9oYYycUvSYl8Zqa6WYHEWmeQ6bra+DTRbVAUdHhO8WT0t LXgJN3FjbtPU3LPF7IR5C8lP9kAxkrGheAkOAkuGKdL6h6+waSuyU3p30on2WZC9 OmYMj02FNpApiulZ901FdvQjutOeXqP0MvwHpcfvFCAltl8dmyX0YxlULYnxdzeS vbmWlwNNQHQY/4Nz+39cbnDWfMU8bbAX/eiDv2rBKmEvrrXbtqpg== X-ME-Sender: X-Sasl-enc: AOhBFc/2F4otex52vMLf1JFtisXgpP6L1GYVtoIqgbhJ 1490738398 Received: from dhcp-8d8b.meeting.ietf.org (dhcp-8d8b.meeting.ietf.org [31.133.141.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 309D8244DA; Tue, 28 Mar 2017 17:59:58 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Mar 2017 16:59:58 -0500 Message-Id: <01B96E1C-29E8-439C-A84C-54B58E8FC69E@cooperw.in> Cc: Benoit Claise To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lmap] AD transition X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:00:01 -0000 All, Since I will be transitioning to the GEN AD position, Beno=C3=AEt has = agreed to become the responsible AD for LMAP. Thanks, Beno=C3=AEt! Alissa=