From nobody Tue May 2 15:01:00 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 7A74D12DFDB for ; Tue, 2 May 2017 15:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 QHU4tp_Zg6ix for ; Tue, 2 May 2017 15:00:56 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1894112EA98 for ; Tue, 2 May 2017 14:57:51 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id m36so123994099qtb.0 for ; Tue, 02 May 2017 14:57:51 -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; bh=7PAXt+quDJXCWswgy/sha+bqJt/t+6mLLBdr2XbGwOE=; b=qlq7T/kCNRnjDhGC9+6pFk9qkEls3k9h8su2MgOiRLMm0PYwK9kIK/ZOusgbUEXSwz ahi8tUJjRJs97hWK2uDsS7oVzP/jxM69KzHWH7Mhy7tH3rST80ul83sGcUiQ80/bkhKH mRnr4HgMPNdxxflAEjw4OPWY+OjeYW54a7BAIrqSKbpA32j7tOqtuVuJ+GvskNnLxi06 Cnx2kQKTEUjrxFb+WbG0rS/UhTW+SNTGB90KCx4NKn3QLo6JxODkSCYUrQspG+Hs50EX ilV7ZcjuEjnvQVxHzcToVgnRHZq+JFQo2q0wOgYutoghTuTAPr4JBeGDMFkvWNxSxNhG wVFg== 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; bh=7PAXt+quDJXCWswgy/sha+bqJt/t+6mLLBdr2XbGwOE=; b=aqHJKlDkMd3PyQOihe2U4cJMfTeEh1fA6xgc1X2HTx64CZYySGxrn/8gAnHYqoJLgM iCyZusR21mkYMqBTIrJWjrudrROeXcEywyWpGakxsas3+33kkKyVaDYe+5e2P4CuVaDx v2w8YyO5JuEblm1AeRQanOgIJvZHSwtl+VWMIDhoHkAQM4BqDK3o4IWEseLjabnr1ChG hR/lLpahf7GDa/GBY5krpymYPv0X2WO3zu8Z2TYT5iLBRfHkkjEiaSGOgDh6fJrFls3Z 8GdPjrsOUbaH3U2zkj4t4liM1CjyY1se2dSsQWV7nhWCtTdHrdU14iOyYbKo1lA1Wkzk ZDgA== X-Gm-Message-State: AN3rC/6S/gaBkrUWj+5IGQb87u7WFP5SZUPv6o44xus93EcK0uPf3kq1 1+NLzYCUb5Dqq7r8VqUlYeyb2U3B7Q== X-Received: by 10.200.50.183 with SMTP id z52mr31609880qta.272.1493762270058; Tue, 02 May 2017 14:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.39 with HTTP; Tue, 2 May 2017 14:57:49 -0700 (PDT) In-Reply-To: <149360623576.9872.11058299144278349335.idtracker@ietfa.amsl.com> References: <149360623576.9872.11058299144278349335.idtracker@ietfa.amsl.com> From: Dan Romascanu Date: Wed, 3 May 2017 00:57:49 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a113a1dfa7c9ff1054e91a171 Archived-At: Subject: [lmap] Fwd: Protocol Action: 'Information Model for Large-Scale Measurement Platforms (LMAP)' to Proposed Standard (draft-ietf-lmap-information-model-18.txt) 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, 02 May 2017 22:00:58 -0000 --001a113a1dfa7c9ff1054e91a171 Content-Type: text/plain; charset=UTF-8 Thanks to Juergen and the authors and contributors team. Congratulations to the whole WG for meeting this significant milestone. Regards, Dan ---------- Forwarded message ---------- From: The IESG Date: Mon, May 1, 2017 at 5:37 AM Subject: Protocol Action: 'Information Model for Large-Scale Measurement Platforms (LMAP)' to Proposed Standard (draft-ietf-lmap-information-model-18.txt) To: IETF-Announce Cc: The IESG , lmap-chairs@ietf.org, Dan Romascanu < dromasca@gmail.com>, lmap@ietf.org, alissa@cooperw.in, draft-ietf-lmap-information-model@ietf.org, rfc-editor@rfc-editor.org The IESG has approved the following document: - 'Information Model for Large-Scale Measurement Platforms (LMAP)' (draft-ietf-lmap-information-model-18.txt) as Proposed Standard This document is the product of the Large-Scale Measurement of Broadband Performance Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ Technical Summary This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. Working Group Summary The Working Group debated the need for an Information Model and how it should be written. The consensus was that an IM is needed and the current format was adopted. Document Quality There is one active implementation of a DM based on this IM which was presented, discussed and is available openly. There is information about at least one more implementation in progress. During the development of the document the WG communicated and received inputs from other SDOs (as the Broadband Forum and IEEE 802) as well as from the EC projects. Personnel Dan Romascanu is the Document Shepherd. Alissa Cooper is the Responsible Area Director. --001a113a1dfa7c9ff1054e91a171 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks to Juergen and the a= uthors and contributors team. Congratulations to the whole WG for meeting t= his significant milestone.

Regards= ,

Dan


---------- Forwarded message ----------
From: The IESG <iesg-secretary@ietf.org>
Date: Mon, = May 1, 2017 at 5:37 AM
Subject: Protocol Action: 'Information Model = for Large-Scale Measurement Platforms (LMAP)' to Proposed Standard (dra= ft-ietf-lmap-information-model-18.txt)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IE= SG <iesg@ietf.org>, lmap-chairs@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap@ietf.org, alissa@cooperw.in, draft-ietf-lmap-information-model@ietf.org, rfc-editor@rfc-editor.org


The = IESG has approved the following document:
- 'Information Model for Large-Scale Measurement Platforms (LMAP)'<= br> =C2=A0 (draft-ietf-lmap-information-model-18.txt) as Proposed Standard=

This document is the product of the Large-Scale Measurement of Broadband Performance Working Group.

The IESG contact persons are Warren Kumari, Benoit Claise and Alissa
Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/





Technical Summary

=C2=A0 =C2=A0This Information Model applies to the Measurement Agent within= a
=C2=A0 =C2=A0Large-Scale Measurement Platform.=C2=A0 As such it outlines th= e
=C2=A0 =C2=A0information that is (pre-)configured on the Measurement Agent = or
=C2=A0 =C2=A0exists in communications with a Controller or Collector within= an
=C2=A0 =C2=A0LMAP framework.=C2=A0 The purpose of such an Information Model= is to
=C2=A0 =C2=A0provide a protocol and device independent view of the Measurem= ent
=C2=A0 =C2=A0Agent that can be implemented via one or more Control and Repo= rt
=C2=A0 =C2=A0protocols.

Working Group Summary

=C2=A0 =C2=A0The Working Group debated the need for an Information Model an= d how
=C2=A0 =C2=A0it should be written.=C2=A0 The consensus was that an IM is ne= eded and the
=C2=A0 =C2=A0current format was adopted.

Document Quality

=C2=A0 =C2=A0There is one active implementation of a DM based on this IM wh= ich was
=C2=A0 =C2=A0presented, discussed and is available openly. There is informa= tion
=C2=A0 =C2=A0about at least one more implementation in progress. During the=
=C2=A0 =C2=A0development of the document the WG communicated and received i= nputs
=C2=A0 =C2=A0from other SDOs (as the Broadband Forum and IEEE 802) as well = as from
=C2=A0 =C2=A0the EC projects.

Personnel

=C2=A0 =C2=A0Dan Romascanu is the Document Shepherd. Alissa Cooper is the =C2=A0 =C2=A0Responsible Area Director.


--001a113a1dfa7c9ff1054e91a171-- From nobody Tue May 2 15:02: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 8DBDF1250B8 for ; Tue, 2 May 2017 15:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 9saqm07OTBfw for ; Tue, 2 May 2017 15:02:10 -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 2ECCA129BA8 for ; Tue, 2 May 2017 14:58:54 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id n4so25819716qte.2 for ; Tue, 02 May 2017 14:58:54 -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; bh=OgYEqjo29VsrdRzhOLwDCUBrSKTxRi4t1xG4mvr+3BM=; b=PYMdJ2b63aF4mEqnvI3FJ8BVhu03SpYq7rQIODtjlBMyIyaSqOPwrxQ20hjKuJLHau NuZZ7GOwTOlfMLr0Xc9ms/+sqMNrPTqt+E/JylQELrR0i/C1IHYOe0kFXCbusOJ9xmDE bmoacIduxk0/xXKsYe+oVyoGNolGO9wxAkSzTr6QSB4tkcBBf/qE6/LYg3aCBYuf10iO agekgsXWxp3KHmWjimhqRzE+ltyic2RLIMiOcA8XpUQIgpHmLzqbGXYsaZNVov0R6cpn ePCwUcgbxalg4FkQbqhsxrVBuuB9CA5vFabLAUQKOpflYSprndEmXvf/r4ySoueArkFo ZzXA== 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; bh=OgYEqjo29VsrdRzhOLwDCUBrSKTxRi4t1xG4mvr+3BM=; b=rkXCeUPT6oIPLeOZ98kearhHHgMdLuPIBcJRhakFtT+hURUcUd+s2h2DXN36xmpkvV kAw5XQ6ENmxYA1rot2jdOY33VBEADG9X4FC5KpKicKMvEs4m+hynUMM7V6Qkb6nXNedu O3jGW33dPxoQ0RFHzDKeOLWgtRsS/82hPRniMfZPFoBJ2M2kBAIWzmysMJSeeYznT6I2 M/NiA1W98kc6y56OIkyKBSppZKfGQrbff9kS2Sl9mznXrCh4GKICz3htc7jJjCZhDGvq lmTbB65Nh6y6Xi/QBoBCfI8hck+FpwsHnH5kwvemfgkY6XVjpZHVXgYZq0rNBJrszL8M 88hA== X-Gm-Message-State: AN3rC/7Vy8w/2FDzJxhu8dVTD/xa/MRsH/2SD/SJ8Z9gQeDRzh/b45hh ZDxn8Eo+HEUzS5ZXaGHWb1LyR6m1c7Ew X-Received: by 10.237.41.101 with SMTP id s92mr28289607qtd.175.1493762333051; Tue, 02 May 2017 14:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.39 with HTTP; Tue, 2 May 2017 14:58:52 -0700 (PDT) In-Reply-To: <149360611165.9788.12151640399872316250.idtracker@ietfa.amsl.com> References: <149360611165.9788.12151640399872316250.idtracker@ietfa.amsl.com> From: Dan Romascanu Date: Wed, 3 May 2017 00:58:52 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a114d78c63d8fca054e91a5fa Archived-At: Subject: [lmap] Fwd: Protocol Action: 'A YANG Data Model for LMAP Measurement Agents' to Proposed Standard (draft-ietf-lmap-yang-12.txt) 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, 02 May 2017 22:02:12 -0000 --001a114d78c63d8fca054e91a5fa Content-Type: text/plain; charset=UTF-8 Thanks to Juergen and the authors and contributors team. Congratulations to the whole WG for meeting this significant milestone. Regards, Dan ---------- Forwarded message ---------- From: The IESG Date: Mon, May 1, 2017 at 5:35 AM Subject: Protocol Action: 'A YANG Data Model for LMAP Measurement Agents' to Proposed Standard (draft-ietf-lmap-yang-12.txt) To: IETF-Announce Cc: The IESG , lmap-chairs@ietf.org, Dan Romascanu < dromasca@gmail.com>, lmap@ietf.org, alissa@cooperw.in, draft-ietf-lmap-yang@ietf.org, rfc-editor@rfc-editor.org The IESG has approved the following document: - 'A YANG Data Model for LMAP Measurement Agents' (draft-ietf-lmap-yang-12.txt) as Proposed Standard This document is the product of the Large-Scale Measurement of Broadband Performance Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ Technical Summary This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. Working Group Summary The Working Group debated what Data Modeling Language should be used for LMAP and the consensus was to use YANG. Document Quality There is one active implementation of the DM which was presented, discussed and is available openly. There is information about at least one more implementation in progress. A YANG Doctor review was performed and comments were incorporated. During the development of the document the WG communicated and received inputs from other SDOs (as the Broadband Forum and IEEE 802) as well as from the EC projects. Personnel Dan Romascanu is the Document Shepherd. Alissa Cooper is the Responsible Area Director. --001a114d78c63d8fca054e91a5fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= Thanks to Juergen and the authors and=20 contributors team. Congratulations to the whole WG for meeting this=20 significant milestone.

Regards,
Dan


---------- Forwarded message ----------
From: = The IESG <iesg-secretary@ietf.org>
= Date: Mon, May 1, 2017 at 5:35 AM
Subject: Protocol Action: 'A YANG = Data Model for LMAP Measurement Agents' to Proposed Standard (draft-iet= f-lmap-yang-12.txt)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, lmap-chairs@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap@ietf.org, alissa@cooperw.in= , draft-ietf-lmap-yang= @ietf.org, rfc-editor@rfc-= editor.org


The IESG has approved the following document:
- 'A YANG Data Model for LMAP Measurement Agents'
=C2=A0 (draft-ietf-lmap-yang-12.txt) as Proposed Standard

This document is the product of the Large-Scale Measurement of Broadband Performance Working Group.

The IESG contact persons are Warren Kumari, Benoit Claise and Alissa
Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-lmap-yang/





Technical Summary

=C2=A0 This document defines a data model for Large-Scale Measurement
=C2=A0 =C2=A0Platforms (LMAP).=C2=A0 The data model is defined using the YA= NG data
=C2=A0 =C2=A0modeling language.

Working Group Summary

=C2=A0 The Working Group debated what Data Modeling Language should be used=
=C2=A0 for LMAP and the consensus was to use YANG.

Document Quality

=C2=A0 There is one active implementation of the DM which was presented, =C2=A0 discussed and is available openly. There is information about at lea= st
=C2=A0 one more implementation in progress. A YANG Doctor review was
=C2=A0 performed and comments were incorporated. During the development of<= br> =C2=A0 the document the WG communicated and received inputs from other SDOs=
=C2=A0 (as the Broadband Forum and IEEE 802) as well as from the EC project= s.

Personnel

=C2=A0 Dan Romascanu is the Document Shepherd. Alissa Cooper is the
=C2=A0 Responsible Area Director.

--001a114d78c63d8fca054e91a5fa-- From nobody Wed May 3 02:53:13 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 D96BD1294B8 for ; Wed, 3 May 2017 02:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 YOZKs8JQroUu for ; Wed, 3 May 2017 02:53:07 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 D87F912894A for ; Wed, 3 May 2017 02:50:36 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r190so51217828wme.1 for ; Wed, 03 May 2017 02:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RX0I9OZthwM5uLpyQL05Sb6s9YdGm7i0V2HH8UmPjx0=; b=F9nBoTprVMpiRVhqyUfU8B1RyBA7mVto4HSFWxCVsjpypLqQz5otN/NsCtCMVAYgE8 SXy+GKfGr+otNmgo8b0vMgm8OUxlW+9JclPVtwVIsEugWaCfIHB3HMwYAkD4sawAQA1s pnwa66TGKezZGkQIJ8Xl3oPoyYmhbtz2xHwOKWnPS/6x4q/6X4BrWBKwtEF5QeMXpHMX bocduxDZSmXQVv6dWDJS6d++q9kQ6RIOMdwnaNaS6SrvA/AxWq4zfCaIzn8j5mAzAYS7 /vAGp3ucVOgG+9wVxDiVV/hRKlguTF+yVvVrr98J0LtAVeUwAf8A6azBg2Kjc4gQ+YOe XnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RX0I9OZthwM5uLpyQL05Sb6s9YdGm7i0V2HH8UmPjx0=; b=Yt3G4fR2OLDkZC+GtrAt/KCL7ugRIEc+PD9uMjVsZj7kGVifGrpM1559+Tq0N93cro 1XPDZZNxhoF0oFOCKxaot5p2xu+pNTclj5zii11Dtt1WhjD7y6Kda1cpw8+s/KB8PI/Z 9gm3cxBqQwCLHe70qljBcAXiwSp+C4EZFo59rB9j0qwypYibs4efoq2bUU0L9hQKlJWq XfrOFVIRTlmYIS1ObKrjTA2fHIVB1pft5ofZsXxsTBrLp3sQet6GrUYb5P7OcUZ2M8by YiMOue7zNwlyoIcL9KcscALLPDxJavfkAG613tvX4iu0qUt/CkaIHkGuM79Kgdj8ZyaE k/bQ== X-Gm-Message-State: AN3rC/4D4t1XUSKftV8/XLX9QtDEkb7G7FkPsSzIGRWfj036TOxixtk3 SL5i8z8c01O/iDsehOjhwJOZ9SHG31Kg X-Received: by 10.28.213.132 with SMTP id m126mr1391590wmg.28.1493805035046; Wed, 03 May 2017 02:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Wed, 3 May 2017 02:50:34 -0700 (PDT) From: Fredrik Kers Date: Wed, 3 May 2017 11:50:34 +0200 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a114695aa7a701e054e9b96a1 Archived-At: Subject: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 03 May 2017 09:53:12 -0000 --001a114695aa7a701e054e9b96a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I'm looking at aligning a project with the LMAP data model ( https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and YANG model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have some questions and comments. First, some comments on the information model. 1) Normally a task in computer terms means a process or a "unit of execution" as it is described on Wikipedia ( https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means a program/executable, or a function in more abstract terms. I was confused for quite some time until I understood that a task in LMAP actually meant. I would suggest using a more common terminology, but I understand that it might be a bit too late to change the name of such a central concept. 2) The information model describes the concept of Measurement Task, Reporting Task, Control Task, etc. ( https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9), and that Control Tasks can be used to configure the Schedules, Tasks etc. on the MA. However it's not described what mechanism a Control Task uses to configure the MA. The normal task input/output model only describes how data flows between instances of tasks and schedules, but does not give any way to communicate with the MA itself. How is this supposed to work? 3) Related to this the Control Tasks, the information model in one place states that "in terms of the Information Model, all Tasks have the same structure", but in another place states that "Suppression has no effect on either Controller Tasks or Controller Schedules". So the question is, is a Control Task (and Schedule) handled differently by the MA compared to other types of Tasks (and Schedules)? And now some comments on the YANG model. 4) In the YANG model, a task can be listed in three places; /lmap/capabilities/tasks/task, /lmap/tasks/task and /lmap/schedules/schedule/action/task. Let's see if I understand this correctly... * /lmap/capabilities/tasks/task lists the available tasks that the MA can execute, which is not configurable from a controller but is configured locally at the MA, for example in a config file or even at compile time. * /lmap/tasks/task is the tasks that has been configured with some default options and are available to be executed. * /lmap/schedules/schedule/action/task pints at what task to start when an action is fired, and provides additional options to it. To me it's not clear why the middle step (/lmap/tasks/task) is required since all the properties at that level (options and tags) can also be configured in the action, except the functions list which seems weird to be able to configure anyways (see next comment). 5) In /lmap/tasks/task you can configure a list of functions for a task, which might or might not be the same functions listed in /lmap/capabilities/tasks/task. The purpose of this functions lists is not crystal clear to me, but it seems wrong that you can configure functions that are not included in the capabilities. 6) To keep the structure of the YANG model consistent all lists should be wrapped in a container, e.g. move /lmap/schedules/schedule/action to /lmap/schedules/schedule/actions/action. Other lists that would be affected are "function", "option", "result", "conflict", "table" and "row". Is there a reason for the different structure of some lists? Regards, Fredrik --=20 *Fredrik Kers* | CTO | linkedin.com/company/netrounds *Netrounds* | Storgatan 9 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --001a114695aa7a701e054e9b96a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!
I'm looking at aligning a project with the= LMAP data model (https://tools.ietf.org/html/draft-ietf-lmap-information= -model-18) and YANG model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12= ) and have some questions and comments.

First, some comme= nts on the information model.

1)
Normally a task = in computer terms means a process or a "unit of execution" as it is described on Wikipedia=20 (https://en.wiki= pedia.org/wiki/Task_(computing)), while in LMAP it means a program/executable, or a function in more abstract terms. I was=20 confused for quite some time until I understood that a task in LMAP=20 actually meant. I would suggest using a more common terminology, but I=20 understand that it might be a bit too late to change the name of such a=20 central concept.

2)
The information model describes the concept of Measurement Task, Reporting Task, Control Task, etc.=20 (https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#= page-9), and that Control Tasks can be used to configure the Schedules, Tasks=20 etc. on the MA. However it's not described what mechanism a Control Tas= k uses to configure the MA. The normal task input/output model only=20 describes how data flows between instances of tasks and schedules, but does= not give=20 any way to communicate with the MA itself. How is this supposed to work?
3)
Related to this the Control Tasks, the information model in one place states=20 that "in terms of the Information Model, all Tasks have the same=20 structure", but in another place states that "Suppression has no = effect=20 on either Controller Tasks or Controller Schedules".

So the question is, is a Control Task (and Schedule) handled differently=20 by the MA compared to other types of Tasks (and Schedules)?


And now some comments on the YANG model.
4)
In the YANG model, a task can be listed in three places; /lmap/capab= ilities/tasks/task, /lmap/tasks/task and /lmap/schedules/schedule/action/ta= sk. Let's see if I understand this correctly...

* /lmap/capabili= ties/tasks/task lists the available tasks that the MA can execute, which is= not configurable from a controller but is configured locally at the MA, fo= r example in a config file or even at compile time.
* /lmap/tasks/task i= s the tasks that has been configured with some default options and are avai= lable to be executed.
* /lmap/schedules/schedule/action/task pints at wh= at task to start when an action is fired, and provides additional options t= o it.

To me it's not clear why the middle step (/lmap= /tasks/task) is required since all the properties at that level (options an= d tags) can also be configured in the action, except the functions list whi= ch seems weird to be able to configure anyways (see next comment).

5)
In /lmap/tasks/task you can configure a list of = functions for a task, which might or might not be the same functions listed= in /lmap/capabilities/tasks/task. The purpose of th= is functions lists is not crystal clear to me, but it seems wrong that you = can configure functions that are not included in the capabilities.

6)
To keep the structure of the YANG model consist= ent all lists=20 should be wrapped in a container, e.g. move=20 /lmap/schedules/schedule/action to=20 /lmap/schedules/schedule/actions/action. Other lists that would be=20 affected are "function", "option", "result", = "conflict", "table" and=20 "row". Is there a reason for the different structure of some list= s?

Regards,
Fredrik

--

Fredrik Kers | CTO | linkedin.= com/company/netrounds

Netrounds=C2=A0|=C2=A0S= torgatan 9 | 972 38 Lule=C3=A5 | Sweden=C2=A0|=C2=A0www.n= etrounds.com

--001a114695aa7a701e054e9b96a1-- From nobody Wed May 3 03:27: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 1761D1201F8 for ; Wed, 3 May 2017 03:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbIQOqTqdwMQ for ; Wed, 3 May 2017 03:26:59 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7E5126E01 for ; Wed, 3 May 2017 03:24:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A457677; Wed, 3 May 2017 12:24:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id A0Ju6xKbF2Zd; Wed, 3 May 2017 12:24:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 May 2017 12:24:08 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8262A2005E; Wed, 3 May 2017 12:24:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id arsO-wwwva5d; Wed, 3 May 2017 12:24:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7444B20053; Wed, 3 May 2017 12:24:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15BB83F36526; Wed, 3 May 2017 12:24:06 +0200 (CEST) Date: Wed, 3 May 2017 12:24:06 +0200 From: Juergen Schoenwaelder To: Fredrik Kers Cc: lmap@ietf.org Message-ID: <20170503102406.GC6642@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Fredrik Kers , lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 03 May 2017 10:27:01 -0000 On Wed, May 03, 2017 at 11:50:34AM +0200, Fredrik Kers wrote: > Hi! > I'm looking at aligning a project with the LMAP data model ( > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and YANG > model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have some > questions and comments. Note that the two documents have just been moved to the RFC editor queue (after ~3 years of development within the WG). While comments and questions are welcome, there likely won't be any technical changes soon. > First, some comments on the information model. > > 1) > Normally a task in computer terms means a process or a "unit of execution" > as it is described on Wikipedia ( > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means a > program/executable, or a function in more abstract terms. I was confused > for quite some time until I understood that a task in LMAP actually meant. > I would suggest using a more common terminology, but I understand that it > might be a bit too late to change the name of such a central concept. I do not think task necessarily means executable in LMAP. The term task is used in order to stay away to some extend from implementation specifics. > 2) > The information model describes the concept of Measurement Task, Reporting > Task, Control Task, etc. ( > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9), > and that Control Tasks can be used to configure the Schedules, Tasks etc. > on the MA. However it's not described what mechanism a Control Task uses to > configure the MA. The normal task input/output model only describes how > data flows between instances of tasks and schedules, but does not give any > way to communicate with the MA itself. How is this supposed to work? It is (a) not required to implement things via control tasks and (b) how control tasks do their work is and implementation detail. > 3) > Related to this the Control Tasks, the information model in one place > states that "in terms of the Information Model, all Tasks have the same > structure", but in another place states that "Suppression has no effect on > either Controller Tasks or Controller Schedules". > > So the question is, is a Control Task (and Schedule) handled differently by > the MA compared to other types of Tasks (and Schedules)? In this particular aspect, they may be handled differently. If you, for example, implement an LMAP agent running behind a NAT, then there needs to be something that calls home to the controller. This something might be implemented as a control task or it might be implemented as part of the LMAP agent itself. If this would be implemented as a control task, then attempts to suppress call home would likely be rejected (since this would essentially mean the LMAP agent becomes disconnected and hence useless). There may be additional control tasks, e.g., a control task that clears buffered data in case an LMAP agent is running low on memory. Again, an implementation may not support suppression of such a house keeping control task. > And now some comments on the YANG model. > > 4) > In the YANG model, a task can be listed in three places; > /lmap/capabilities/tasks/task, /lmap/tasks/task and > /lmap/schedules/schedule/action/task. Let's see if I understand this > correctly... > > * /lmap/capabilities/tasks/task lists the available tasks that the MA can > execute, which is not configurable from a controller but is configured > locally at the MA, for example in a config file or even at compile time. > * /lmap/tasks/task is the tasks that has been configured with some default > options and are available to be executed. > * /lmap/schedules/schedule/action/task pints at what task to start when an > action is fired, and provides additional options to it. Correct. > To me it's not clear why the middle step (/lmap/tasks/task) is required > since all the properties at that level (options and tags) can also be > configured in the action, except the functions list which seems weird to be > able to configure anyways (see next comment). The 'middle step' is an optimization for situations when you have many actions that want to share common task parameters. > 5) > In /lmap/tasks/task you can configure a list of functions for a task, which > might or might not be the same functions listed in > /lmap/capabilities/tasks/task. The purpose of this functions lists is not > crystal clear to me, but it seems wrong that you can configure functions > that are not included in the capabilities. I assume an implementation would reject an attempt to configure a function that does not apply. What is your proposal? To have this spelled out more clearly in the YANG model? To have some sort of a must constraint to express this? (I would have to think about how to write this.) > 6) > To keep the structure of the YANG model consistent all lists should be > wrapped in a container, e.g. move /lmap/schedules/schedule/action to > /lmap/schedules/schedule/actions/action. Other lists that would be affected > are "function", "option", "result", "conflict", "table" and "row". Is there > a reason for the different structure of some lists? YANG generally does not have nodes representing lists and some people believe such additional containers just add additional noise to the data encodings with little value. The reason why we have the top-level containers is because people found it useful to have some top-level structure (similar to the way we have structured the information model into several aspects); so these top-levels provide structure, they do not represent lists. For example, /lmap/agent is just a container for scalars and /lmap/capabilities is a container with scalars and a list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed May 3 07:00:42 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 26053127077 for ; Wed, 3 May 2017 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 SUm3K2yhdTkS for ; Wed, 3 May 2017 07:00:30 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 EBB75129B52 for ; Wed, 3 May 2017 06:56:45 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r190so59436986wme.1 for ; Wed, 03 May 2017 06:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hBLq4n87t/989qN1a1irr6Tw7rleeXqX2cGdUF6a15Y=; b=KyXlGOFMcaqXjng8nhAYhm2kTYNrdHxI6vfotctTXoecVJQAIFT9p0SRW2GjMDcQFn wdJloekXkZEkUnu77b9kZ3u/5mfsPa6X65d77GJm1KFrt0l+E/qjpyg+JgRDbgLEUEQL etLNmnJBhXRjlCowGv4v27BIoxgHAbmbpph0Af4jJY1scJ9xHmBh/s5AudFyn2u9MlgE 1uhuno3ddg5XeEDTroophCnufvxsQ/V13ALbG753N/UDWaqmkuzP6iueseIKlbRXmX0L ElRikjw0Ty4cHn6XbNKEO/CDuQAg0rBkYyILe7/Bu9s/6dVt0S7fRXNa3SgcugBe28q1 bQMw== 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; bh=hBLq4n87t/989qN1a1irr6Tw7rleeXqX2cGdUF6a15Y=; b=G6v3vvMAsOO8U7K/lwYhmPmzsWVJUrcUUKidRpra5yTQlqVAFqnyUMRHzfitoXeaS4 5UduviNdFXmXuN7cNKnje2YX7fbXmhHj3TgS1b2/XGt6mxg7X2BZyGE3cLGbtXIMj8ay oHwV+T1t9/K9YsmswwVJs5hw5+NyeivWQsrr0/Brwek7AIoGXcrD47X2HebCzUypRTCF qtnaVG5Oc28WjIQTpat4TU2pSqRaVPkpEhIUMRo0QNgp5p3o0gXZKASIi3dNPljLnJK8 gZXQ1Yb0GKW2N0POuXR3UJDpr8iHB6+G0RydmPXPTlk+5hhlNTFxrpPYLLoQeSOL5E0b yAMg== X-Gm-Message-State: AODbwcCmR6dPyj/uhfOOjylXR/KSMDkpjdRX3oNTHY7HxKq3Fu4IQ4ww zl/BvzXveDmZ2/NkCjw4qWFKrJvctw== X-Received: by 10.28.26.82 with SMTP id a79mr270761wma.119.1493819804400; Wed, 03 May 2017 06:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Wed, 3 May 2017 06:56:43 -0700 (PDT) In-Reply-To: <20170503102406.GC6642@elstar.local> References: <20170503102406.GC6642@elstar.local> From: Fredrik Kers Date: Wed, 3 May 2017 15:56:43 +0200 Message-ID: To: Juergen Schoenwaelder , Fredrik Kers , lmap@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05be0eccd73a054e9f06d6 Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 03 May 2017 14:00:41 -0000 --94eb2c05be0eccd73a054e9f06d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 12:24 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, May 03, 2017 at 11:50:34AM +0200, Fredrik Kers wrote: > > Hi! > > I'm looking at aligning a project with the LMAP data model ( > > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and > YANG > > model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have > some > > questions and comments. > > Note that the two documents have just been moved to the RFC editor > queue (after ~3 years of development within the WG). While comments > and questions are welcome, there likely won't be any technical changes > soon. > I just saw that. Congratulations! I hope I don't ruin your day with all these questions :) > > First, some comments on the information model. > > > > 1) > > Normally a task in computer terms means a process or a "unit of > execution" > > as it is described on Wikipedia ( > > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means > a > > program/executable, or a function in more abstract terms. I was confuse= d > > for quite some time until I understood that a task in LMAP actually > meant. > > I would suggest using a more common terminology, but I understand that = it > > might be a bit too late to change the name of such a central concept. > > I do not think task necessarily means executable in LMAP. The term > task is used in order to stay away to some extend from implementation > specifics. > No, the information model does not mention how a Task should be implemented, so it could be in any form. However, in the YANG model the task is actually assumed to be an executable because of the "program" leaf with the description "The (local) program to invoke in order to execute the task." Anyway, my comment was not about whether a Task is realized as an executable or not but that the term "task" in LMAP doesn't mean what you would expect. But I understand that it's too late to change this. > > 2) > > The information model describes the concept of Measurement Task, > Reporting > > Task, Control Task, etc. ( > > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9 > ), > > and that Control Tasks can be used to configure the Schedules, Tasks et= c. > > on the MA. However it's not described what mechanism a Control Task use= s > to > > configure the MA. The normal task input/output model only describes how > > data flows between instances of tasks and schedules, but does not give > any > > way to communicate with the MA itself. How is this supposed to work? > > It is (a) not required to implement things via control tasks and (b) > how control tasks do their work is and implementation detail. > OK. Since the concept of Control Tasks is covered in the RFC, it would be good to clarify that the communication interface between the Control Task and the MA is outside of the scope of the RFC. > 3) > > Related to this the Control Tasks, the information model in one place > > states that "in terms of the Information Model, all Tasks have the same > > structure", but in another place states that "Suppression has no effect > on > > either Controller Tasks or Controller Schedules". > > > > So the question is, is a Control Task (and Schedule) handled differentl= y > by > > the MA compared to other types of Tasks (and Schedules)? > > In this particular aspect, they may be handled differently. If you, > for example, implement an LMAP agent running behind a NAT, then there > needs to be something that calls home to the controller. This > something might be implemented as a control task or it might be > implemented as part of the LMAP agent itself. If this would be > implemented as a control task, then attempts to suppress call home > would likely be rejected (since this would essentially mean the LMAP > agent becomes disconnected and hence useless). There may be additional > control tasks, e.g., a control task that clears buffered data in case > an LMAP agent is running low on memory. Again, an implementation may > not support suppression of such a house keeping control task. > I understand the reason one might want to prevent suppression of certain Tasks, but stating that some Tasks should be treated differently without additional information on how to identify those Tasks leaves the reader wondering. If you think that it's up to the implementation to decide how to identify the task, I think than it should be mentioned. > > And now some comments on the YANG model. > > > > 4) > > In the YANG model, a task can be listed in three places; > > /lmap/capabilities/tasks/task, /lmap/tasks/task and > > /lmap/schedules/schedule/action/task. Let's see if I understand this > > correctly... > > > > * /lmap/capabilities/tasks/task lists the available tasks that the MA c= an > > execute, which is not configurable from a controller but is configured > > locally at the MA, for example in a config file or even at compile time= . > > * /lmap/tasks/task is the tasks that has been configured with some > default > > options and are available to be executed. > > * /lmap/schedules/schedule/action/task pints at what task to start when > an > > action is fired, and provides additional options to it. > > Correct. > > > To me it's not clear why the middle step (/lmap/tasks/task) is required > > since all the properties at that level (options and tags) can also be > > configured in the action, except the functions list which seems weird t= o > be > > able to configure anyways (see next comment). > > The 'middle step' is an optimization for situations when you have many > actions that want to share common task parameters. > OK. > > > 5) > > In /lmap/tasks/task you can configure a list of functions for a task, > which > > might or might not be the same functions listed in > > /lmap/capabilities/tasks/task. The purpose of this functions lists is n= ot > > crystal clear to me, but it seems wrong that you can configure function= s > > that are not included in the capabilities. > > I assume an implementation would reject an attempt to configure a > function that does not apply. What is your proposal? To have this > spelled out more clearly in the YANG model? To have some sort of a > must constraint to express this? (I would have to think about how to > write this.) > Of course you could solve it at the implementation level, but as a user of an interface based on the YANG model I would wonder what to configure in /lmap/tasks/task/function and why. The /lmap/tasks/task/program leaf, which will have the same issue, has a "nacm:default-deny-write" statement, that I assume is to prevent configuration of it. Could something similar be done? An alternative is to remove the "program" and "function" (registry-grouping) completely from the /lmap/tasks/task since they already exist in the task in the capabilities which is referenced by name. > 6) > > To keep the structure of the YANG model consistent all lists should be > > wrapped in a container, e.g. move /lmap/schedules/schedule/action to > > /lmap/schedules/schedule/actions/action. Other lists that would be > affected > > are "function", "option", "result", "conflict", "table" and "row". Is > there > > a reason for the different structure of some lists? > > YANG generally does not have nodes representing lists and some people > believe such additional containers just add additional noise to the > data encodings with little value. > > The reason why we have the top-level containers is because people > found it useful to have some top-level structure (similar to the way > we have structured the information model into several aspects); so > these top-levels provide structure, they do not represent lists. For > example, /lmap/agent is just a container for scalars and > /lmap/capabilities is a container with scalars and a list. > OK Regards, Fredrik --=20 *Fredrik Kers* | CTO *Netrounds* | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --94eb2c05be0eccd73a054e9f06d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, May 3, 2017 at 12:24 PM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Wed, May 03= , 2017 at 11:50:34AM +0200, Fredrik Kers wrote:
> Hi!
> I'm looking at aligning a project with the LMAP data model (
> https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and YANG
> model (https://tools.ietf.org/html/draf= t-ietf-lmap-yang-12) and have some
> questions and comments.

Note that the two documents have just been moved to the RFC editor queue (after ~3 years of development within the WG). While comments
and questions are welcome, there likely won't be any technical changes<= br> soon.

I just saw that. Congratulations!= I hope I don't ruin your day with all these questions :)
=C2=A0
> First, some comments on the information model.
>
> 1)
> Normally a task in computer terms means a process or a "unit of e= xecution"
> as it is described on Wikipedia (
> https://en.wikipedia.org/wiki/Task_(comp= uting)), while in LMAP it means a
> program/executable, or a function in more abstract terms. I was confus= ed
> for quite some time until I understood that a task in LMAP actually me= ant.
> I would suggest using a more common terminology, but I understand that= it
> might be a bit too late to change the name of such a central concept.<= br>
I do not think task necessarily means executable in LMAP. The term task is used in order to stay away to some extend from implementation
specifics.

No, the information model do= es not mention how a Task should be implemented, so it could be in any form= . However, in the YANG model the task is actually assumed to be an executab= le because of the "program" leaf with the description "The (= local) program to invoke in order to execute the task."

<= div>Anyway, my comment was not about whether a Task is realized as an execu= table or not but that the term "task" in LMAP doesn't mean wh= at you would expect. But I understand that it's too late to change this= .
=C2=A0
> 2)
> The information model describes the concept of Measurement Task, Repor= ting
> Task, Control Task, etc. (
> https://tools.ietf.org/h= tml/draft-ietf-lmap-information-model-18#page-9),
> and that Control Tasks can be used to configure the Schedules, Tasks e= tc.
> on the MA. However it's not described what mechanism a Control Tas= k uses to
> configure the MA. The normal task input/output model only describes ho= w
> data flows between instances of tasks and schedules, but does not give= any
> way to communicate with the MA itself. How is this supposed to work?
It is (a) not required to implement things via control tasks and (b)=
how control tasks do their work is and implementation detail.

OK. Since the concept of Control Tasks is covered in= the RFC, it would be good to clarify that the communication interface betw= een the Control Task and the MA is outside of the scope of the RFC.

> 3)
> Related to this the Control Tasks, the information model in one place<= br> > states that "in terms of the Information Model, all Tasks have th= e same
> structure", but in another place states that "Suppression ha= s no effect on
> either Controller Tasks or Controller Schedules".
>
> So the question is, is a Control Task (and Schedule) handled different= ly by
> the MA compared to other types of Tasks (and Schedules)?

In this particular aspect, they may be handled differently. If you,<= br> for example, implement an LMAP agent running behind a NAT, then there
needs to be something that calls home to the controller. This
something might be implemented as a control task or it might be
implemented as part of the LMAP agent itself. If this would be
implemented as a control task, then attempts to suppress call home
would likely be rejected (since this would essentially mean the LMAP
agent becomes disconnected and hence useless). There may be additional
control tasks, e.g., a control task that clears buffered data in case
an LMAP agent is running low on memory. Again, an implementation may
not support suppression of such a house keeping control task.

I understand the reason one might want to prevent su= ppression of certain Tasks, but stating that some Tasks should be treated d= ifferently without additional information on how to identify those Tasks le= aves the reader wondering. If you think that it's up to the implementat= ion to decide how to identify the task, I think than it should be mentioned= .


> And now some comments on the YANG model.
>
> 4)
> In the YANG model, a task can be listed in three places;
> /lmap/capabilities/tasks/task, /lmap/tasks/task and
> /lmap/schedules/schedule/action/task. Let's see if I understa= nd this
> correctly...
>
> * /lmap/capabilities/tasks/task lists the available tasks that the MA = can
> execute, which is not configurable from a controller but is configured=
> locally at the MA, for example in a config file or even at compile tim= e.
> * /lmap/tasks/task is the tasks that has been configured with some def= ault
> options and are available to be executed.
> * /lmap/schedules/schedule/action/task pints at what task to star= t when an
> action is fired, and provides additional options to it.

Correct.

> To me it's not clear why the middle step (/lmap/tasks/task) is req= uired
> since all the properties at that level (options and tags) can also be<= br> > configured in the action, except the functions list which seems weird = to be
> able to configure anyways (see next comment).

The 'middle step' is an optimization for situations when you= have many
actions that want to share common task parameters.
OK.
=C2=A0

> 5)
> In /lmap/tasks/task you can configure a list of functions for a task, = which
> might or might not be the same functions listed in
> /lmap/capabilities/tasks/task. The purpose of this functions lists is = not
> crystal clear to me, but it seems wrong that you can configure functio= ns
> that are not included in the capabilities.

I assume an implementation would reject an attempt to configure a function that does not apply. What is your proposal? To have this
spelled out more clearly in the YANG model? To have some sort of a
must constraint to express this? (I would have to think about how to
write this.)

Of course= you could solve it at the implementation level, but as a user of an interf= ace based on the YANG model I would wonder what to configure in /lmap/tasks/task/function and why= .

The /lmap/tasks/task/program leaf, which will have the same issue, has = a "nacm:default-deny-write" statement, that I assume is to preven= t configuration of it. Could something similar be done?

An alternative is to remove the "program" an= d "function" (registry-grouping) completely from the /lmap/tasks/task since they already exist in the task in the ca= pabilities which is referenced by name.
> 6)
> To keep the structure of the YANG model consistent all lists should be=
> wrapped in a container, e.g. move /lmap/schedules/schedule/action= to
> /lmap/schedules/schedule/actions/action. Other lists that would b= e affected
> are "function", "option", "result", &quo= t;conflict", "table" and "row". Is there
> a reason for the different structure of some lists?

YANG generally does not have nodes representing lists and some peopl= e
believe such additional containers just add additional noise to the
data encodings with little value.

The reason why we have the top-level containers is because people
found it useful to have some top-level structure (similar to the way
we have structured the information model into several aspects); so
these top-levels provide structure, they do not represent lists. For
example, /lmap/agent is just a container for scalars and
/lmap/capabilities is a container with scalars and a list.
=

OK

Regards,
= Fredrik
=C2=A0
--
Fredrik Kers | CTO
Netrounds | Storgatan 7 | 972 38 Lule= =C3=A5 | Sweden | www.netrounds.com
--94eb2c05be0eccd73a054e9f06d6-- From nobody Wed May 3 07:50: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 2F2D1129B16 for ; Wed, 3 May 2017 07:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe0rSAhGYLDM for ; Wed, 3 May 2017 07:50:02 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BBD129B40 for ; Wed, 3 May 2017 07:47:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 40BD0EE0; Wed, 3 May 2017 16:47:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YndBxhzY6ucX; Wed, 3 May 2017 16:47:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 May 2017 16:47:34 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C0C72005E; Wed, 3 May 2017 16:47:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9mhJ4h-Esmx8; Wed, 3 May 2017 16:47:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3208820053; Wed, 3 May 2017 16:47:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 124483F36DAE; Wed, 3 May 2017 16:47:32 +0200 (CEST) Date: Wed, 3 May 2017 16:47:32 +0200 From: Juergen Schoenwaelder To: Fredrik Kers Cc: lmap@ietf.org Message-ID: <20170503144732.GA7170@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Fredrik Kers , lmap@ietf.org References: <20170503102406.GC6642@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 03 May 2017 14:50:05 -0000 On Wed, May 03, 2017 at 03:56:43PM +0200, Fredrik Kers wrote: > > I just saw that. Congratulations! I hope I don't ruin your day with all > these questions :) > People reading the documents are always welcome! > > > First, some comments on the information model. > > > > > > 1) > > > Normally a task in computer terms means a process or a "unit of > > execution" > > > as it is described on Wikipedia ( > > > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means > > a > > > program/executable, or a function in more abstract terms. I was confused > > > for quite some time until I understood that a task in LMAP actually > > meant. > > > I would suggest using a more common terminology, but I understand that it > > > might be a bit too late to change the name of such a central concept. > > > > I do not think task necessarily means executable in LMAP. The term > > task is used in order to stay away to some extend from implementation > > specifics. > > > > No, the information model does not mention how a Task should be > implemented, so it could be in any form. However, in the YANG model the > task is actually assumed to be an executable because of the "program" leaf > with the description "The (local) program to invoke in order to execute the > task." > > Anyway, my comment was not about whether a Task is realized as an > executable or not but that the term "task" in LMAP doesn't mean what you > would expect. But I understand that it's too late to change this. The question always is: Is there anything unclear impacting implementations and interoperability? > > > 2) > > > The information model describes the concept of Measurement Task, > > Reporting > > > Task, Control Task, etc. ( > > > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9 > > ), > > > and that Control Tasks can be used to configure the Schedules, Tasks etc. > > > on the MA. However it's not described what mechanism a Control Task uses > > to > > > configure the MA. The normal task input/output model only describes how > > > data flows between instances of tasks and schedules, but does not give > > any > > > way to communicate with the MA itself. How is this supposed to work? > > > > It is (a) not required to implement things via control tasks and (b) > > how control tasks do their work is and implementation detail. > > > > OK. Since the concept of Control Tasks is covered in the RFC, it would be > good to clarify that the communication interface between the Control Task > and the MA is outside of the scope of the RFC. I would not disagree with such a statement but I do not find it essential and well it is too late for the first version of the model. > > 3) > > > Related to this the Control Tasks, the information model in one place > > > states that "in terms of the Information Model, all Tasks have the same > > > structure", but in another place states that "Suppression has no effect > > on > > > either Controller Tasks or Controller Schedules". > > > > > > So the question is, is a Control Task (and Schedule) handled differently > > by > > > the MA compared to other types of Tasks (and Schedules)? > > > > In this particular aspect, they may be handled differently. If you, > > for example, implement an LMAP agent running behind a NAT, then there > > needs to be something that calls home to the controller. This > > something might be implemented as a control task or it might be > > implemented as part of the LMAP agent itself. If this would be > > implemented as a control task, then attempts to suppress call home > > would likely be rejected (since this would essentially mean the LMAP > > agent becomes disconnected and hence useless). There may be additional > > control tasks, e.g., a control task that clears buffered data in case > > an LMAP agent is running low on memory. Again, an implementation may > > not support suppression of such a house keeping control task. > > > > I understand the reason one might want to prevent suppression of certain > Tasks, but stating that some Tasks should be treated differently without > additional information on how to identify those Tasks leaves the reader > wondering. If you think that it's up to the implementation to decide how to > identify the task, I think than it should be mentioned. A controller does not configure which tasks are control tasks. The MA implementation knows them. > > > 5) > > > In /lmap/tasks/task you can configure a list of functions for a task, > > which > > > might or might not be the same functions listed in > > > /lmap/capabilities/tasks/task. The purpose of this functions lists is not > > > crystal clear to me, but it seems wrong that you can configure functions > > > that are not included in the capabilities. > > > > I assume an implementation would reject an attempt to configure a > > function that does not apply. What is your proposal? To have this > > spelled out more clearly in the YANG model? To have some sort of a > > must constraint to express this? (I would have to think about how to > > write this.) > > > > Of course you could solve it at the implementation level, but as a user of > an interface based on the YANG model I would wonder what to configure in > /lmap/tasks/task/function and why. The function ties into a registry. Until we have such a registry, this remains somewhat vague. > The /lmap/tasks/task/program leaf, which will have the same issue, has a > "nacm:default-deny-write" statement, that I assume is to prevent > configuration of it. Could something similar be done? The registry proponents would never configure a program; they would identify a function via a registy entry and the system would have to resolve how that maps to a program. Note that it is not mandatory to have a program configured. > An alternative is to remove the "program" and "function" > (registry-grouping) completely from the /lmap/tasks/task since they already > exist in the task in the capabilities which is referenced by name. An entry in the task list says which functions a task can provide. In the configured task, you might subset that. /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 May 4 01:32:45 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 53F2D128796 for ; Thu, 4 May 2017 01:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 AIFHT_XU0XHa for ; Thu, 4 May 2017 01:32:42 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 E3406126CD8 for ; Thu, 4 May 2017 01:32:41 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u65so10996000wmu.1 for ; Thu, 04 May 2017 01:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3W8FV2erleqpKCPmqkvHXQrIe3+xSzRymtFJltEgzqs=; b=UMHZ4n4ZKm9bCPwg69Ponk6ieKdF8D8X4Hl4sBJ548hDEXLH6nEjFmSdYKbzWYOZq1 sUlZXPsVO6P7Mu7M8QeEd2SiGyrZSBjTbv/vXLWhhN1ZjJsxb7vWAIOGZxDGyUw5JuTl XH7TFdeW2F4hgK6hkaPiOpp9gMLni1hvg9qPuBjrqJL8h26DSFU5aglerAlxTSWrAqjw mDQD37i3tZVlsL7ynhcEKrXw/G/Bttw/aKYPbQ/KLuXIWYBxdgO095lbyI6fNPrbSOfh Kvk1XhXW+Qssm2BQXk4b65bxQW0S2D8+osDlKpT/Eu8BbJ9MdwXYHCtenZ7SMajd/otR umWg== 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; bh=3W8FV2erleqpKCPmqkvHXQrIe3+xSzRymtFJltEgzqs=; b=FVBxIBLUBcGbWZ/x46DWIpjlH3VSEhW+MEgyrnpyyYL+FnNfikzCgX0Nd3x3iL4qFI fWjVs2BNjWKFXQG9HmSPxAe1HCwZWsDahh34mvyQk5JPFYrkQqpL8RvNfcvSsVyJF2SZ Be1pqXMDOn5JXG2Cn1z7aPR0PCh00elvslWBRxy2Klw7anUAHlF6HJtADJFIALzVLJdF nvRMMimpuqWhTWsPCuiFl7axp4aVuJ3gUKj9lsZ8s3wjQGEqx0W85bq2uaKru22vIcI9 79cXf1agpJLNVrgWmgZ8ecYzaVzQV76d0kLI59vqRSwKjp/j6NepjVh5A71H15eUdoRs ryYQ== X-Gm-Message-State: AN3rC/6Na2+bURecg53HOpnekw8Se3Ln8sGfUuxXerhMwN85YRWXjBgX s2NAxKOq8PaWhifVPIiKKKqGU/F0Ow== X-Received: by 10.28.26.82 with SMTP id a79mr881517wma.119.1493886760028; Thu, 04 May 2017 01:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Thu, 4 May 2017 01:32:39 -0700 (PDT) In-Reply-To: <20170503144732.GA7170@elstar.local> References: <20170503102406.GC6642@elstar.local> <20170503144732.GA7170@elstar.local> From: Fredrik Kers Date: Thu, 4 May 2017 10:32:39 +0200 Message-ID: To: Juergen Schoenwaelder , Fredrik Kers , lmap@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05be0eaac1f5054eae9d40 Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 04 May 2017 08:32:44 -0000 --94eb2c05be0eaac1f5054eae9d40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 4:47 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > > > > First, some comments on the information model. > > > > > > > > 1) > > > > Normally a task in computer terms means a process or a "unit of > > > execution" > > > > as it is described on Wikipedia ( > > > > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it > means > > > a > > > > program/executable, or a function in more abstract terms. I was > confused > > > > for quite some time until I understood that a task in LMAP actually > > > meant. > > > > I would suggest using a more common terminology, but I understand > that it > > > > might be a bit too late to change the name of such a central concep= t. > > > > > > I do not think task necessarily means executable in LMAP. The term > > > task is used in order to stay away to some extend from implementation > > > specifics. > > > > > > > No, the information model does not mention how a Task should be > > implemented, so it could be in any form. However, in the YANG model the > > task is actually assumed to be an executable because of the "program" > leaf > > with the description "The (local) program to invoke in order to execute > the > > task." > > > > Anyway, my comment was not about whether a Task is realized as an > > executable or not but that the term "task" in LMAP doesn't mean what yo= u > > would expect. But I understand that it's too late to change this. > > The question always is: Is there anything unclear impacting > implementations and interoperability? > No, the RFC is clear. > > > 5) > > > > In /lmap/tasks/task you can configure a list of functions for a tas= k, > > > which > > > > might or might not be the same functions listed in > > > > /lmap/capabilities/tasks/task. The purpose of this functions lists > is not > > > > crystal clear to me, but it seems wrong that you can configure > functions > > > > that are not included in the capabilities. > > > > > > I assume an implementation would reject an attempt to configure a > > > function that does not apply. What is your proposal? To have this > > > spelled out more clearly in the YANG model? To have some sort of a > > > must constraint to express this? (I would have to think about how to > > > write this.) > > > > > > > Of course you could solve it at the implementation level, but as a user > of > > an interface based on the YANG model I would wonder what to configure i= n > > /lmap/tasks/task/function and why. > > The function ties into a registry. Until we have such a registry, this > remains somewhat vague. > > > The /lmap/tasks/task/program leaf, which will have the same issue, has = a > > "nacm:default-deny-write" statement, that I assume is to prevent > > configuration of it. Could something similar be done? > > The registry proponents would never configure a program; they would > identify a function via a registy entry and the system would have to > resolve how that maps to a program. Note that it is not mandatory to > have a program configured. > > > An alternative is to remove the "program" and "function" > > (registry-grouping) completely from the /lmap/tasks/task since they > already > > exist in the task in the capabilities which is referenced by name. > > An entry in the task list says which functions a task can provide. In > the configured task, you might subset that. > So the purpose of the functions in /lmap/tasks/task is to configure what functions (metrics) a task should produce? That makes sense. Would also make sense if those functions could be configured at the action level, just like like the options. Another question. What is the purpose of /schedules/schedule/action/parameters? Is it only to provide configuration to the "task instance" that is not feasible to describe as an option? Regards, Fredrik --=20 *Fredrik Kers* | CTO *Netrounds* | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --94eb2c05be0eaac1f5054eae9d40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, May 3, 2017 at 4:47 PM, Juergen Schoenwaelder <= ;= j.schoenwaelder@jacobs-university.de> wrote:
> > > First, some comments on the information model.
> > >
> > > 1)
> > > Normally a task in computer terms means a process or a "= ;unit of
> > execution"
> > > as it is described on Wikipedia (
> > > https://en.wikipedia.org/wiki/= Task_(computing)), while in LMAP it means
> > a
> > > program/executable, or a function in more abstract terms. I = was confused
> > > for quite some time until I understood that a task in LMAP a= ctually
> > meant.
> > > I would suggest using a more common terminology, but I under= stand that it
> > > might be a bit too late to change the name of such a central= concept.
> >
> > I do not think task necessarily means executable in LMAP. The ter= m
> > task is used in order to stay away to some extend from implementa= tion
> > specifics.
> >
>
> No, the information model does not mention how a Task should be
> implemented, so it could be in any form. However, in the YANG model th= e
> task is actually assumed to be an executable because of the "prog= ram" leaf
> with the description "The (local) program to invoke in order to e= xecute the
> task."
>
> Anyway, my comment was not about whether a Task is realized as an
> executable or not but that the term "task" in LMAP doesn'= ;t mean what you
> would expect. But I understand that it's too late to change this.<= br>
The question always is: Is there anything unclear impacting
implementations and interoperability?

N= o, the RFC is clear.

> > > 5)
> > > In /lmap/tasks/task you can configure a list of functions fo= r a task,
> > which
> > > might or might not be the same functions listed in
> > > /lmap/capabilities/tasks/task. The purpose of this functions= lists is not
> > > crystal clear to me, but it seems wrong that you can configu= re functions
> > > that are not included in the capabilities.
> >
> > I assume an implementation would reject an attempt to configure a=
> > function that does not apply. What is your proposal? To have this=
> > spelled out more clearly in the YANG model? To have some sort of = a
> > must constraint to express this? (I would have to think about how= to
> > write this.)
> >
>
> Of course you could solve it at the implementation level, but as a use= r of
> an interface based on the YANG model I would wonder what to configure = in
> /lmap/tasks/task/function and why.

The function ties into a registry. Until we have such a registry, th= is
remains somewhat vague.

> The /lmap/tasks/task/program leaf, which will have the same issue, has= a
> "nacm:default-deny-write" statement, that I assume is to pre= vent
> configuration of it. Could something similar be done?

The registry proponents would never configure a program; they would<= br> identify a function via a registy entry and the system would have to
resolve how that maps to a program. Note that it is not mandatory to
have a program configured.

> An alternative is to remove the "program" and "function= "
> (registry-grouping) completely from the /lmap/tasks/task since they al= ready
> exist in the task in the capabilities which is referenced by name.

An entry in the task list says which functions a task can provide. I= n
the configured task, you might subset that.

=
So the purpose of the functions in /lmap/tasks/= task is to configure what functions (metrics) a task should produce? That m= akes sense. Would also make sense if those functions could be configured at= the action level, just like like the options.

Another question. What is the purpose of /sc= hedules/schedule/action/parameters? Is it only to provide configuration to = the "task instance" that is not feasible to describe as an option= ?

Regards,
Fredrik

-= -
Fredrik Kers | CTO
Netrounds | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com
--94eb2c05be0eaac1f5054eae9d40-- From nobody Thu May 4 05:52:19 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 5701C12956C for ; Thu, 4 May 2017 05:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-HuNKeLa0Go for ; Thu, 4 May 2017 05:52:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449191294B8 for ; Thu, 4 May 2017 05:52:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CBB106DC; Thu, 4 May 2017 14:52:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id qPMpQ_rwq1tF; Thu, 4 May 2017 14:52:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 May 2017 14:52:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9BDE2005E; Thu, 4 May 2017 14:52:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uRTjJOYgBSwm; Thu, 4 May 2017 14:52:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5622E20053; Thu, 4 May 2017 14:52:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 190183F384AF; Thu, 4 May 2017 14:52:14 +0200 (CEST) Date: Thu, 4 May 2017 14:52:14 +0200 From: Juergen Schoenwaelder To: Fredrik Kers Cc: lmap@ietf.org Message-ID: <20170504125213.GA8317@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Fredrik Kers , lmap@ietf.org References: <20170503102406.GC6642@elstar.local> <20170503144732.GA7170@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 04 May 2017 12:52:18 -0000 On Thu, May 04, 2017 at 10:32:39AM +0200, Fredrik Kers wrote: > > So the purpose of the functions in /lmap/tasks/task is to configure what > functions (metrics) a task should produce? That makes sense. Would also > make sense if those functions could be configured at the action level, just > like like the options. > Maybe, maybe not. This may depend on what exactly registries provide. Anyway, adding stuff to a YANG model is easy should the need arise. > Another question. What is the purpose of > /schedules/schedule/action/parameters? Is it only to provide configuration > to the "task instance" that is not feasible to describe as an option? Yes, kind of. Some people suggested such an extension mechanism would be needed but we lack experience with it. So the parameters are more or less a placeholder. Perhaps there should also have been on /tasks/task/parameters. (But then it is even less clear how parameters associated to a task and to an action are merged.) /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 May 4 06:09:48 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 A45F8127B52 for ; Thu, 4 May 2017 06:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 kWZNKqZ2SdjG for ; Thu, 4 May 2017 06:09:43 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 0FF8F129440 for ; Thu, 4 May 2017 06:09:41 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u65so17988999wmu.1 for ; Thu, 04 May 2017 06:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KGRlvBl0HdvAGSettqyeh1b7kx1+q5cQuoRn3fXQwC4=; b=XnazPhVckKFQi8xPA+gdQgcYVVsfzfTwH8lHDZ0SI72WYroYtSSpO2Ziadr+wHF7xA g+bn7MsT7fe65SD6n1iRtYaLopfx90zG8X3UiNh0UFgadoQ5Rqa95z67BbTtMYZGmbO/ yQQB2iYUnL2EYbdKzrfb/G0A5V1j/hDNI6ubuK+IkDZceRQ06GCwiZwGKVNOfMtdsZ5r zRIQgHTtFjKFQu4152YGTVwy0uXj1ckMqgZKTuW5OM3qM4EAM0mSNIOVEKKjPETr2dLw LBLoMBnCbtXnAGKwHIdPX9Bp15N01V/otuKU5Yy7IV2xukwD1tDA8ytpLi5kN9NtiX7l l/cQ== 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; bh=KGRlvBl0HdvAGSettqyeh1b7kx1+q5cQuoRn3fXQwC4=; b=ZiyIodm5+JYtVb0ShJBPSRZQHn+d9NM/NX93TmsCyjTEVT71kvG+K4W4hFy5LbqgBg vJr+rqZSyey10Vr2MuwWD+wDZyINdWyQdmXJWDQ1izaAWOoE2AQuzsP6CnbiQ+OnMMov qFflGL81Z8Ap7PYu5xVzd/rp4PcAgxS2WlryIxvERAMr0MmhTtqnKp84MFXMw3zECS2P utS8G/WmmfjLMcHkoQM7nvLG+Uv2A0PH+hQnMmU+8GTCUwpoUOsr7473CK4Yx2i4Je7o qiC81jRvwsRC9lmbygfUif/Muuf/NoShegGdPea6BFgXhFIGfGznYS2Ckl3BJJX7rC8v KsHA== X-Gm-Message-State: AN3rC/6pArAMWbLcfBZ9ssly3HqSkbJzoCDaUhVXYkGWk9Qq+mDgGxzL m0YpLzR8LPAIu5tyYBYDpwytccyzqg== X-Received: by 10.28.91.3 with SMTP id p3mr1851846wmb.68.1493903379554; Thu, 04 May 2017 06:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Thu, 4 May 2017 06:09:38 -0700 (PDT) In-Reply-To: <20170504125213.GA8317@elstar.local> References: <20170503102406.GC6642@elstar.local> <20170503144732.GA7170@elstar.local> <20170504125213.GA8317@elstar.local> From: Fredrik Kers Date: Thu, 4 May 2017 15:09:38 +0200 Message-ID: To: Juergen Schoenwaelder , Fredrik Kers , lmap@ietf.org Content-Type: multipart/alternative; boundary=001a114412c0448fc1054eb27cdc Archived-At: Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12 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, 04 May 2017 13:09:47 -0000 --001a114412c0448fc1054eb27cdc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK. Thank you for taking the time to answer my questions and comments. Regards, Fredrik --=20 *Fredrik Kers* | CTO *Netrounds* | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --001a114412c0448fc1054eb27cdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. Thank you for taking the time to answer my q= uestions and comments.

Regards,
Fredrik
=

--
Fredrik Kers | CTO
Netrounds | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com
--001a114412c0448fc1054eb27cdc-- From nobody Fri May 5 12:45:07 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 1E357126C25 for ; Fri, 5 May 2017 12:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 4DfDu9IvB8Mr for ; Fri, 5 May 2017 12:45:04 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 D4BEA124217 for ; Fri, 5 May 2017 12:45:03 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id j29so13541556qtj.1 for ; Fri, 05 May 2017 12:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TteXiTkQoYljse13aJIezdz7SAwfGrPmUifkIAhThQ8=; b=rTeeh6bpNXVrhW3o+y2jrPQXO91yP9xtKtfJzlVv9mcmbbQF5CTe9MLkaTeU48S2d3 jL/uRoEVKEsDHcBYzdUlJLq+aFUeISiBMOfG49pBlCJUC8NQFZuLQ/TG6sOzsSqAnWYh VMccKtiRu4r+E3115cEggJJ5h5Ls7n9RbQ7Bwej0FplcsbRkI3hlWTbgXPEamzXpSesG zhasfUoS4m1mnM7dykDCdmOq+Yyt5LxjkXwbXsaB9mCdhHEIPQWJBfycyPoqaH/VcRSX c3vgamw0ljPeWtxAqWTL5KHUQzXtzLo43HYDkMZtXOMA+omvtO8xqeCS0fM3Z+mDtkeO SKtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TteXiTkQoYljse13aJIezdz7SAwfGrPmUifkIAhThQ8=; b=l58iZr7u4onIeYadX0Xum1JvZW5fu5lObBw994bLkPqd+63FuIft7g1RJ3YIkEBzLN En4y86HHB2LRTCmsF3lEGht5hhyEw7NmNVukZbwCR2lktwPc9knb1T5oECyft0C95D4V RrditD5sFnCS3jr7aSEb9Cc1gwZQVmA9QnQVK0MicZZsXOHmEt8AV4905mvMkQniOtIY LbauWHQALczPsuKQEjzNINXKYFETdAeasbuQZ61ksht3qh+JkhXzkQQr3fXKOkDbrlyb ++Kqe/5772Jin1m+d2Ypcq6mvV1MAEaXDFhnlWCntLY5fRJNeDsdpUVBEY4jfLqPJSeB 4c6Q== X-Gm-Message-State: AODbwcDMv97jSuG/MLgWjfLI07/VG2xif3XBcB+DTOtcllxOMauOsGwk rwQhnZzC3CXXrNkbzgky8hjWOGpjpr+i X-Received: by 10.200.47.36 with SMTP id j33mr7703880qta.175.1494013502843; Fri, 05 May 2017 12:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.39 with HTTP; Fri, 5 May 2017 12:45:02 -0700 (PDT) From: Dan Romascanu Date: Fri, 5 May 2017 22:45:02 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a113c01bc20740f054ecc2006 Archived-At: Subject: [lmap] LMAP - what next? 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: Fri, 05 May 2017 19:45:05 -0000 --001a113c01bc20740f054ecc2006 Content-Type: text/plain; charset=UTF-8 Hi, With the LMAP WG having shipped the IM and DM documents to the RFC Editor, it's time to discuss what next. Specifically, I have two questions: - what to do with draft-ietf-lmap-restconf? - is there any new work for lmap on short term, or should we rather focus on implementations and revisit the issue in a year or two? Comments and discussions are welcome. Regards, Dan --001a113c01bc20740f054ecc2006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

With the LMAP W= G having shipped the IM and DM documents to the RFC Editor, it's time t= o discuss what next.

Specifically, I have two questions:
=
- what to do with draft-ietf-lmap-restconf?
- is there any new work for lmap on short term, or should we rather focus on=20 implementations and revisit the issue in a year or two?

Commen= ts and discussions are welcome.

Regards,

Dan
=
--001a113c01bc20740f054ecc2006-- From nobody Tue May 16 08:39: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 1BE90128768 for ; Tue, 16 May 2017 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=netrounds-com.20150623.gappssmtp.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 i9O-1QjW2C2c for ; Tue, 16 May 2017 08:39:27 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 645C712EAF4 for ; Tue, 16 May 2017 08:35:38 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l50so79288588wrc.3 for ; Tue, 16 May 2017 08:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LhGcVTwlv499UAMBzMsaLZIeB27O0uf9bCYRfw8sbUk=; b=x7tAJDB5kEs7vgoB/tRRmTvYfjAT0kfXanGmyhMDfSsYFHv7HewAkkdHBmTqd5pjLV uuxsSOokmxQNq88+h2w8pvb5S47fGOhyQ2mKP7sRSjEo8cyIcVa6paaO8ccS/V1LFWra S3fELB6y4MDLm64NXbZF6iu5zCWp/IjV8vf3LQs+G786Xs5seU0JbwmDFldUfhrK49r1 vre8cwt5yIryzHHot0pdJDfk+c+DJvhKe5SwsSRdNxBVR1e0FrnYTxRROKijS8r2yT1X jQiehl1UsQqc+XsNzz7mu9MZoNzUES45b4H8ch+DcSpj0XYoN6oXmfEYdYpoE5FHaDlY XfaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LhGcVTwlv499UAMBzMsaLZIeB27O0uf9bCYRfw8sbUk=; b=nfGc5qG4va4h9QaPhIamwEiMrNFRfGpojRxJd+Aq3AQryZGEozy9/oWKj/0Ot0z2c6 WIzBDVwaymuNfwxDA+q4fJ2+d87FbYkBtiOJtdrgWCeH9cPcQtv0Xh+dL4Wb4EYoiikv OpBj/BwRzxkqRdEqoR4EQYD24rhLsfnQg2+J7berSIjPPAzEZLXs8LygcRinx0DTGMuD GwoNK6Ngn4cpkBRFd5IDQahJsGKfLhSU31hRZUbTCtGzN7XJvoZj73Zo82y4PejNwoOR cKk8F44Grk48p5NSKjye7CdczScT1z97F+vLBuX2Xbv3MIflUw4aUYpsMfh3x1lVAWBA ZYHw== X-Gm-Message-State: AODbwcBVb8+pADtljprUaGd/J2JjUrDJtFq0Up+SPPTcX66CYBe8fva1 2FHX5s9AZ4j2FWn2pVU9C199oeg3Kw== X-Received: by 10.223.152.6 with SMTP id v6mr7857793wrb.60.1494948936651; Tue, 16 May 2017 08:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Tue, 16 May 2017 08:35:36 -0700 (PDT) From: Fredrik Kers Date: Tue, 16 May 2017 17:35:36 +0200 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary="f403045d5af053d370054fa5ec8f" Archived-At: Subject: [lmap] A question about running actions in sequence 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, 16 May 2017 15:39:29 -0000 --f403045d5af053d370054fa5ec8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! I have a question about how running Actions in sequence is supposed to work according to the LAMP information model. Let's take a simple example. Say you have two actions that you want to run in sequence, first a traceroute that finds all routers between the MA and a remote peer, and after that a time limited ping to each of the routers. It will not be possible to use the Schedule's duration to do the time limiting of the ping since there is no way to have a second Schedule (doing the ping) starting after the first Schedule (doing the traceroute) is finished. Also, you can not place both Actions in the same Schedule and use the Schedule's duration since you don't know how long time the traceroute will take. The only way that I see is to make it possible to configure the duration in the ping Actions itself. Is this how it's intended to be done? The possibility to schedule arbitrary actions in a sequence would be quite limited by this I think. Regards, Fredrik --=20 *Fredrik Kers* | CTO *Netrounds* | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --f403045d5af053d370054fa5ec8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I have= a question about how running Actions in sequence is supposed to work accor= ding to the LAMP information model.

Let's take a simple ex= ample. Say you have two actions that you want to run in sequence, first a t= raceroute that finds all routers between the MA and a remote peer, and afte= r that a time limited ping to each of the routers.

It will not= be possible to use the Schedule's duration to do the time limiting of = the ping since there is no way to have a second Schedule (doing the ping) s= tarting after the first Schedule (doing the traceroute) is finished.
Also, you can not place both Actions in the same Schedule and use th= e Schedule's duration since you don't know how long time the tracer= oute will take.

The only way that I see is to make it possible= to configure the duration in the ping Actions itself. Is this how it's= intended to be done? The possibility to schedule arbitrary actions in a se= quence would be quite limited by this I think.

Regards,
Fredrik

--
Fredrik Kers | CTO
Netrounds | Storgatan 7 | 972 = 38 Lule=C3=A5 | Sweden | www.netrounds.com
--f403045d5af053d370054fa5ec8f-- From nobody Tue May 16 09:11:18 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 F16BB129544 for ; Tue, 16 May 2017 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xghSCnV3XN7 for ; Tue, 16 May 2017 09:11:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA95012D0C3 for ; Tue, 16 May 2017 09:06:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D58506A0; Tue, 16 May 2017 18:06:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id lIphXCnsATXC; Tue, 16 May 2017 18:06:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 May 2017 18:06:35 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5B4A2006D; Tue, 16 May 2017 18:06:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O6r1idJr1POR; Tue, 16 May 2017 18:06:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A8C720063; Tue, 16 May 2017 18:06:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 592C63F49833; Tue, 16 May 2017 18:06:34 +0200 (CEST) Date: Tue, 16 May 2017 18:06:33 +0200 From: Juergen Schoenwaelder To: Fredrik Kers Cc: lmap@ietf.org Message-ID: <20170516160633.GA23770@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Fredrik Kers , lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] A question about running actions in sequence 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, 16 May 2017 16:11:18 -0000 On Tue, May 16, 2017 at 05:35:36PM +0200, Fredrik Kers wrote: > Hi! > > I have a question about how running Actions in sequence is supposed to work > according to the LAMP information model. > > Let's take a simple example. Say you have two actions that you want to run > in sequence, first a traceroute that finds all routers between the MA and a > remote peer, and after that a time limited ping to each of the routers. > > It will not be possible to use the Schedule's duration to do the time > limiting of the ping since there is no way to have a second Schedule (doing > the ping) starting after the first Schedule (doing the traceroute) is > finished. Right, the schedule's duration is a limit on the duration of the whole schedule, which may consist of multiple actions. > Also, you can not place both Actions in the same Schedule and use the > Schedule's duration since you don't know how long time the traceroute will > take. Yes. > The only way that I see is to make it possible to configure the duration in > the ping Actions itself. Is this how it's intended to be done? It seems this is what you are looking for. Right now, the information model does not support per action duration limits. This could be added though, I think, without breaking anything. > The possibility to schedule arbitrary actions in a sequence would be > quite limited by this I think. I am not sure this statement is right. But yes, if you want to have per action duration limits, they are not part of this version of the LMAP models. Whether this is a major omission or not - well I do not know. Perhaps a somewhat kludgy workaround could be a schedule that does just the traceroute (with a duration set to cover the traceroutes) where the traceroute action feeds into another schedule (with a duration set to cover pings) that does the pings. /js PS: Personally, I find the concrete use case a bit surprising. If you want to probe the path for a certain time, why not run traceroute for a certain time; this causes roughly the same number of probe packets and your measurement adjusts to any path changes during the measurement itself. But perhaps you just picked this as an example to illustrate the question. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed May 17 00:38: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 416DB1294E7 for ; Wed, 17 May 2017 00:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 zAAXWxZLI10z for ; Wed, 17 May 2017 00:38:39 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 7A16B1294CF for ; Wed, 17 May 2017 00:35:18 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b84so154411965wmh.0 for ; Wed, 17 May 2017 00:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0HJvf3UqZgTgXJx6jQD0hPC0Zo0prNkGDCcClBYk3W8=; b=XZ/KBv6Qg6pkV19bv+QLLz6y4K3npgXa/sdBeFynNhujgijXYo82Wlvp/+/opQIGpN GMNS0Y5sytivvnL7leGuIoAFM5kGXqeH4uQnLnmzlSvsn8ujS8tBuUl9vsCtZ1QJg2kJ YKWLUA/+HeDRUo+mx67ZvTL+jq39fPV/j3ENw39xBEgBH6h2ekIaODrXMlIaXSGp0uF8 YjJnr7L5IOLt2D4WI5AFp2bfxe+9D8oLs0BpEx5FzAa8K3FwQQ3fAtZHKij+nkcaNyhc 84l+GLRMyBfkz2NnrmxkC1jUYcE6KaXW5txBAVczydUbKBGfV5gbmrNZdL4fx/h78ZN9 5iuA== 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; bh=0HJvf3UqZgTgXJx6jQD0hPC0Zo0prNkGDCcClBYk3W8=; b=CS/nv8gdwKfGEGt0UYD3Vrvk49ETpzGaOc4AVqqwrAYX6uIHMOJHulCbLRLTtcqyVJ mFnH0ENbselw6ykDKU25ursZ7bLzx6CGpU2cXV5mUwGwLWKaLw41m7/pgysUKFL/pivH giaT66m8UEsa5kYdjAqakyCEPwi6aZRxARshno1VSZUakGsLHAl6tISWU5urK5E6yHjR emStGJpGYhIqK/RVEgNMMhGfEldXPl3RFnM7nfTKGGFe69UafULeTZrtc9/WriR9bQ9/ s9aPPScoqatIyX/G7tO917e6FRJPuAKuFedmY1xjTLde31f/C+ZcIPGqNfo0/p/TPwA0 /dUw== X-Gm-Message-State: AODbwcDGKy706Vxswc9wHF5uGvBkjuQmYu2fkMoxS/lKu+Txp9jzfVHg OV1PehreGVPWOD09bL8KjTnVGQNZ4AH5 X-Received: by 10.28.134.3 with SMTP id i3mr10061257wmd.68.1495006517293; Wed, 17 May 2017 00:35:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.16 with HTTP; Wed, 17 May 2017 00:35:16 -0700 (PDT) In-Reply-To: <20170516160633.GA23770@elstar.local> References: <20170516160633.GA23770@elstar.local> From: Fredrik Kers Date: Wed, 17 May 2017 09:35:16 +0200 Message-ID: To: Juergen Schoenwaelder , Fredrik Kers , lmap@ietf.org Content-Type: multipart/alternative; boundary="001a1143fa96668d78054fb354c9" Archived-At: Subject: Re: [lmap] A question about running actions in sequence 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, 17 May 2017 07:38:43 -0000 --001a1143fa96668d78054fb354c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Perhaps a somewhat kludgy workaround could be a schedule that does > just the traceroute (with a duration set to cover the traceroutes) > where the traceroute action feeds into another schedule (with a > duration set to cover pings) that does the pings. > Yes, if you give the first Action with uncertain runtime enough margin to finish, the result will be that they run in sequence. But probably with some delay. > > /js > > PS: Personally, I find the concrete use case a bit surprising. If you > want to probe the path for a certain time, why not run traceroute > for a certain time; this causes roughly the same number of probe > packets and your measurement adjusts to any path changes during > the measurement itself. But perhaps you just picked this as an > example to illustrate the question. > Yes, it was just used as an example. You would face the same problem when you combine any Action that runs until it's complete with an Action that runs until it's stopped. Thank you for your answer! Regards, Fredrik --=20 *Fredrik Kers* | CTO *Netrounds* | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com --001a1143fa96668d78054fb354c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
Perhaps a somewhat kludgy workaround could be a schedule that does
just the traceroute (with a duration set to cover the traceroutes)
where the traceroute action feeds into another schedule (with a
duration set to cover pings) that does the pings.

=
Yes, if you give the first Action with uncertain runtime enough = margin to finish, the result will be that they run in sequence. But probabl= y with some delay.
=C2=A0

/js

PS: Personally, I find the concrete use case a bit surprising. If you
=C2=A0 =C2=A0 want to probe the path for a certain time, why not run tracer= oute
=C2=A0 =C2=A0 for a certain time; this causes roughly the same number of pr= obe
=C2=A0 =C2=A0 packets and your measurement adjusts to any path changes duri= ng
=C2=A0 =C2=A0 the measurement itself. But perhaps you just picked this as a= n
=C2=A0 =C2=A0 example to illustrate the question.

Yes, it was just used as an example. You would face the same problem wh= en you combine any Action that runs until it's complete with an Action = that runs until it's stopped.

T= hank you for your answer!

Regards,<= br>
Fredrik

--
Fredrik Kers | CTO
Ne= trounds | Storgatan 7 | 972 38 Lule=C3=A5 | Sweden | www.netrounds.com
--001a1143fa96668d78054fb354c9-- From nobody Thu May 18 13:43: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 81B6A129C07 for ; Thu, 18 May 2017 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 xeAEc2WHX5ar for ; Thu, 18 May 2017 13:43:20 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 9AA7312EB07 for ; Thu, 18 May 2017 13:36:09 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id c13so44107028qtc.1 for ; Thu, 18 May 2017 13:36:09 -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; bh=f4GXhqjb9GSbz+jMT/YjcR2d4ntWsZjCLHo1OS0ClMg=; b=NmSWSp+4Ts6MfknqmAfwvN/WegUw+hKWxkwMX5FS3NLNFhdbotcJKfbbKiq/joUrak Fbpd2DA5UXVX36imQkJTslh4b1tkwzvTZwheUufNIGXkTfx6s46yFh/ivCzBUpnz1hb1 qe/N9wqD+y5+8whPUsRkGkjikQRbaOTaAyN/8GTU3QZZMjHl3Dw4c5T9AadePny5Phc8 9d4FWV6xiYoB31JheSjQ1u7H6Khhskwz8nBf6iQaEKeZ/cKjA4hheqgMuaWeeZ4fg7xB SXlINDUWXg0wwnP0D+YY5di0Np1QXqaaWTmHEGAH1ce2MtspPILYrjdRqPmwDl6z66yL i4mQ== 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; bh=f4GXhqjb9GSbz+jMT/YjcR2d4ntWsZjCLHo1OS0ClMg=; b=QayN9EcX5O+BCU5IpzGd4mL7BIO1n7OTiFJPzlQYIcf5r5u7ojI6utM2ehn0BSOECQ 42FFODzQToJeAj2kZWAD/sIp4gEdrbppcpy6soOUEpU5obhV467wD6+wVven5/RJGyaB s0kMQ/EQu/0dhSeitEx+bGQNLhXfhDtKfAxXYwN+6oJsPE5r659i6rGfcaeQ5pw5bPB0 zRBdC7IZtQANPwAwptc8kZhF9Ly6hsayVKvRn5BL0iXOOG8NNRf4zKp8ryKylfQbjNFo ik7brLqbofe9yccMu27kb+WH67mqujgKmsnOBbvXwUG/taPtRIQXhJ3O6pDKSh+U1WXs GLhQ== X-Gm-Message-State: AODbwcDe2WV2DlM3FzVhi2Fsbjuk5CSdfbdt2eXPMHkz0KNE4zE1ky/Y FGBmQvlWZcmsLZY0WQjpma+hosxUqia7 X-Received: by 10.200.4.162 with SMTP id s34mr6208254qtg.35.1495139768240; Thu, 18 May 2017 13:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.31.101 with HTTP; Thu, 18 May 2017 13:36:07 -0700 (PDT) In-Reply-To: References: From: Dan Romascanu Date: Thu, 18 May 2017 23:36:07 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary="f4030435cc58c69244054fd25ab3" Archived-At: Subject: Re: [lmap] LMAP - what next? 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, 18 May 2017 20:43:22 -0000 --f4030435cc58c69244054fd25ab3 Content-Type: text/plain; charset="UTF-8" Hi, There was no answer to the list to this mail. The chairs had some off-line discussions with Juergen (as editor of the LMAP documents) and with Benoit who is back to be our shepherding AD. Our assessment is that it would be good to complete the current charter by bringing to completion and publishing draft-ietf-lmap-restconf. While RESTCONF has been published, the progress on the client and server configuration models has been slow and we believe that the RESTCONF LMAP document would ideally describe how to put the pieces together, e.g., how to configure an LMAP agent to do call home to the LMAP controller and to run regular RESTCONF sessions to POST results to a collector. This is related to the RESTCONF configuration models work going on in the NETCONF WG which has its own pace of progress. Our proposal is as follows: - Resuscitate draft-ietf-lmap-restconf and sync it with the work going on in NETCONF. Juergen will put it higher in his TODO list - unless some spectacular proposal for new work shows up we shall work on the mail list and we will not meet at IETF 99 - unless some spectacular proposal for new work shows up we shall go dormant or even close the WG after completing the restconf document. Comments? Regrds, Dan On Fri, May 5, 2017 at 10:45 PM, Dan Romascanu wrote: > Hi, > > With the LMAP WG having shipped the IM and DM documents to the RFC Editor, > it's time to discuss what next. > > Specifically, I have two questions: > > - what to do with draft-ietf-lmap-restconf? > - is there any new work for lmap on short term, or should we rather focus > on implementations and revisit the issue in a year or two? > > Comments and discussions are welcome. > > Regards, > > Dan > > --f4030435cc58c69244054fd25ab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

There was no an= swer to the list to this mail. The chairs had some off-line discussions wit= h Juergen (as editor of the LMAP documents) and with Benoit who is back to = be our shepherding AD. Our assessment is that=C2=A0 it would be good to com= plete the current charter by bringing to completion and publishing draft-ie= tf-lmap-restconf. While RESTCONF has been published, the progress on the cl= ient and server configuration models has been slow and we believe that the = RESTCONF LMAP document would ideally describe how to put the pieces togethe= r, e.g., how to configure an LMAP agent to do call home to the LMAP
controller and to run regular RESTCONF sessions to POST results to a collec= tor. This is related to the RESTCONF configuration models work going on in = the NETCONF WG which has its own pace of progress.

Our propos= al is as follows:

- Resuscitate draft-ietf-lmap-restconf and = sync it with the work going on in NETCONF. Juergen will put it higher in hi= s TODO list
- unless some spectacular proposal for new work shows = up we shall work on the mail list and we will not meet at IETF 99
- unle= ss some spectacular proposal for new work shows up we shall go dormant or e= ven close the WG after completing the restconf document.

Comments?

Regrds,

Dan


On Fri, May 5= , 2017 at 10:45 PM, Dan Romascanu <dromasca@gmail.com> wrot= e:
<= div>Hi,

With the LMAP WG having shipped the IM and DM documen= ts to the RFC Editor, it's time to discuss what next.

Spe= cifically, I have two questions:

- what to do with draft-ietf-lmap-= restconf?
- is there any new work for lmap on short term, or should we rather focus on=20 implementations and revisit the issue in a year or two?

Commen= ts and discussions are welcome.

Regards,

Dan
=

--f4030435cc58c69244054fd25ab3--