From nobody Wed Feb 1 11:25:28 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 68C46129E6F for ; Wed, 1 Feb 2017 11:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGnGh18aw5KE for ; Wed, 1 Feb 2017 11:25:24 -0800 (PST) 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 0F7CF129E7A for ; Wed, 1 Feb 2017 11:25:24 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so281733201qtg.3 for ; Wed, 01 Feb 2017 11:25:24 -0800 (PST) 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=z8+2oa8clNq78b2hZm1JSJoSRhfB7mj3eEA7IHRoCZU=; b=Et3y9fpJc/EbY3zX0FyKCXnVhJhY6JQ/Bq3FTYxaU/glbPKovRojHnkEenYNEG1V0E qqxWo4KQgaTuCaK1rzXm7BnA+d+n3MdJ4dneHSeIBz/z+9mQVHHPm8HoqukrjydVcHll YLbZh02FC1YBC9Zc4/gIsWcvmKBHtK8W/RXmBgPGQd6aiTgG6YiablBIk0coIMRfNDgi +xYmQYhZQ2RUjNfLQ8n1lF55idt8YeXidUTS04CPd/zrLQqHxoYYri+QVjwpSHQS1w8L q4XN7CYTeOl/a78zg9RIY/+56aXLN0O5Pn7tPSTQg/zuS7zLmc/BD0jFyYTp8QoJp8z6 TBug== 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=z8+2oa8clNq78b2hZm1JSJoSRhfB7mj3eEA7IHRoCZU=; b=eEbtjL9YzLM1qm4mb24B/lRiBfI7rDXO2HWPjY9+u/D7JY8lbhvZv7aCaSQWqsUO5U rrqFmrUe+C+Ts9A2Z0j7iohZZYrHng3k1oQ8RXkFv3KpRKPRZ+Bw47vVXTTcNBDlB0P3 t7Aedxb7mTnmJRLaRCsTKUinnDdeRT3LE8I8xA7hYKYpbKO+a69eAaq4Rg5SDamq6QIW PpW8HYrmQHa5cXK52xW9PeTvNRk5CyuFOknx3Mqv6Wv+XUgaVFD3oK+GaTk2IWxvm03a a5ZEWJTiycYEkkzBnF8/1674IqnN6YuRmECagXATGaMm9bknfKYe27Fx3/JjyIJRgVuR Zhfw== X-Gm-Message-State: AIkVDXKXUhhri2MyDY9Eos3JOFbt72f+4CZ1ztqGkoTaLpO3i8cLQ/QAEfOv/Lx0xrUus4zWbT0u+G0DlgVz3A== X-Received: by 10.200.47.46 with SMTP id j43mr4286651qta.178.1485977122840; Wed, 01 Feb 2017 11:25:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.11 with HTTP; Wed, 1 Feb 2017 11:25:22 -0800 (PST) In-Reply-To: <20170201014501.52CD8B81C39@rfc-editor.org> References: <20170201014501.52CD8B81C39@rfc-editor.org> From: Dan Romascanu Date: Wed, 1 Feb 2017 21:25:22 +0200 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a113b0a508d25ce05477d02c5 Archived-At: Subject: [lmap] Fwd: [Netconf] RFC 8040 on RESTCONF Protocol X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:25:26 -0000 --001a113b0a508d25ce05477d02c5 Content-Type: text/plain; charset=UTF-8 LMAP-ers, Please see below the message about the publication of RESCTONF. As LMAP has chosen using RESTCONF for LMAP, this milestone is important for us as well, and opens the way to progressing the LMAP protocol document. Regards, Dan ---------- Forwarded message ---------- From: Date: Wed, Feb 1, 2017 at 3:45 AM Subject: [Netconf] RFC 8040 on RESTCONF Protocol To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, netconf@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 8040 Title: RESTCONF Protocol Author: A. Bierman, M. Bjorklund, K. Watsen Status: Standards Track Stream: IETF Date: January 2017 Mailbox: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net Pages: 137 Characters: 238832 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-restconf-18.txt URL: https://www.rfc-editor.org/info/rfc8040 DOI: 10.17487/RFC8040 This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --001a113b0a508d25ce05477d02c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

LMAP-ers,

Please see below the message about the publication o= f RESCTONF. As LMAP has chosen using RESTCONF for LMAP, this milestone is i= mportant for us as well, and opens the way to progressing the LMAP protocol= document.

Regards,

<= div class=3D"gmail_quote">Dan


-= --------- Forwarded message ----------
From: <= rfc-editor@rfc-editor.org>
Date: Wed, Feb 1, 2017 at 3:45 = AM
Subject: [Netconf] RFC 8040 on RESTCONF Protocol
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, netconf@ietf.org, rfc-editor@rfc-editor.org


A new Request for = Comments is now available in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8040

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 RESTCONF Protocol =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0A. Bierman,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M. Bj= orklund,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 K. Wa= tsen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0January 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 andy@yumaworks.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mbj@tail-f.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kwatsen@juniper.net
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 137
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 238832
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-netconf-restco= nf-18.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc8040

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC804= 0

This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the
datastore concepts defined in the Network Configuration Protocol
(NETCONF).

This document is a product of the Network Configuration Working Group of th= e IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/sta= ndards) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinf= o/ietf-announce
=C2=A0 https://mailman.rfc-editor.org/m= ailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/s= earch
For downloading RFCs, see https://www.rfc-editor.org/re= trieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a113b0a508d25ce05477d02c5-- From nobody Tue Feb 7 07:26:36 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148C0129CB3 for ; Tue, 7 Feb 2017 07:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=wE5lVGj0; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=t/7AfZff 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 9xYTLO4ji6Tb for ; Tue, 7 Feb 2017 07:26:33 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275D0129CB4 for ; Tue, 7 Feb 2017 07:26:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9828A20A0D; Tue, 7 Feb 2017 10:26:32 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 07 Feb 2017 10:26:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+L/xDdoKQr9C4jn AY2ON2Jj6QWU=; b=wE5lVGj0SiQZdQFjmPmV5Nr2Cuwf35VaUYRg7hPtG45HIsH 8nBdVox7+XOgJ03QbTqjdRQeoixr60MGRMU1OiHGjJvpLspNCvzQkCp5eHCK5USA qYGqVCcDAbbr4I3OKDQtFe9WcPjG+HOCB/iq+lK6V1SmtXJwPynNUf3kXXss= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=+L/xDdoKQr9C4jnAY2ON2Jj6QWU=; b=t/7AfZff+OEIn51t4/4l P4/7BCvHX43Dmny+gHpYfIyBRX6oDuHA5UGjxNHGNpa6fBy/KGT/l9HSsQr7eHFq gSg7XcD7b8snBD8m5O7AK1bEJ9FHl6EH0BLMLOBXufd3lN7xZbCI/R8K/z6rw1Pn Os/QhwpAMchXtaNE7SIULMg= X-ME-Sender: X-Sasl-enc: QOo5h0POOdOaYTAj13LcsgsC7GTPggQqXUoWd5GoQ5b3 1486481192 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.162]) by mail.messagingengine.com (Postfix) with ESMTPA id D3FB97E432; Tue, 7 Feb 2017 10:26:31 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170131194757.GA78531@elstar.local> Date: Tue, 7 Feb 2017 10:26:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:26:35 -0000 > On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: >>=20 >>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder = wrote: >>>>=20 >>>=20 >>> The status reports go to the LMAP controller, so I do not really see >>> why there is a specific risk since the controller has access to the >>> device ID anyway. >>=20 >> I still am missing what is the rationale for sending the device ID in = the status reports. I thought the agent ID was meant to uniquely = identify the MA. >>=20 >=20 > So here we go. I propose the following change: >=20 > - The ma-status-agent-id becomes optional. > - The ma-status-device-id becomes mandatory again. >=20 > Rationale: >=20 > If a device does not yet have an MA-ID, then the device-id must be > accessible such that the controller can configure an MA-ID. Section 3.1 says: "The MA may be pre-configured with an MA ID, or may use a Device ID in the first Controller contact before it is assigned an MA ID. The Device ID may be a MAC address or some other device identifier expressed as a URI. If the MA ID is not provided at this stage then it must be provided by the Controller during Configuration.=E2=80=9D Why would an MA be sending a status report before configuration? Thanks, Alissa >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Feb 7 07:31:25 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 2FEC6129CD2 for ; Tue, 7 Feb 2017 07:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=0Ne7uAdn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=MaR3T5/+ 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 37QhGByk6z3z for ; Tue, 7 Feb 2017 07:31:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACCF129CCD for ; Tue, 7 Feb 2017 07:31:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 928C920AD8; Tue, 7 Feb 2017 10:31:19 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 07 Feb 2017 10:31:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=9ycgbwZ8b7lTlBI GyluoCg+2XWA=; b=0Ne7uAdnrL0RTsl/EYaXkASKEnyPWMShyLwHyKxXtEQOqyh b+1W0yuBhmPy9eEA+RAR+RT9fNBmqwBcAzlFq/wfM6nxRz2M1nDTKdWF4rKKMOX1 YTt+Af+3/ABHNQgLl3wkTdIS4sDqRhx73BN+dspYVyzZyNxMkWxcBgAUEk9g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=9ycgbwZ8b7lTlBIGyluoCg+2XWA=; b=MaR3T5/+CLnASxUPXuzh K1jFYe0t4wwdT8RKGLCwCZP9w0vEdegNcYdX93Aj5v5EEZPUiQuTHhuz7Q4DcqAQ byH4NWAlsiK5/b2EGVmav74jReV9rR3EbcUxmn1cyoBHVDI9Mfcfj7GdUwaXB15H xps/7SD7tyu8UWyhn1yJjCM= X-ME-Sender: X-Sasl-enc: QYMdyD1HfTR0Dyz5ANtpM8FpC9/Ma+Fm6tz8tWhtN1d/ 1486481479 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.162]) by mail.messagingengine.com (Postfix) with ESMTPA id C2EF47E34E; Tue, 7 Feb 2017 10:31:18 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170126101706.GD43055@elstar.local> Date: Tue, 7 Feb 2017 10:31:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> <20170126101706.GD43055@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:31:25 -0000 > On Jan 26, 2017, at 5:17 AM, Juergen Schoenwaelder = wrote: >=20 > Trimming things down... >=20 > On Wed, Jan 25, 2017 at 01:25:26PM -0500, Alissa Cooper wrote: >>>=20 >>>> (4) "A queue is internally used to pass >>>> results to another schedule." >>>>=20 >>>> I thought it was up to the implementation to decide how to = implement this? >>>=20 >>> OK. I meanwhile understand that the word 'queue' has too many >>> connotations. Is 'buffer' a less problematic term? The key here is >>> that the data producer and the data consumer are in general not >>> running at the time and hence data needs to be stored temporarily >>> somewhere. >>=20 >> Isn=E2=80=99t this implied though? Even with =E2=80=9Cbuffer=E2=80=9D = it still seems like specifying an implementation detail. I=E2=80=99d = prefer to see something like your last sentence above instead. >=20 > So I will replace 'buffer' with 'somewhere'. Oh boy. Here is the > new text: >=20 > A set of schedules receiving the output produced > by this action. The output is stored temporarily > somewhere since the destination schedules will in > general not be running when output is passed to > them. The behaviour of an action passing data to > its own schedule is implementation specific. I don=E2=80=99t think you need to say =E2=80=9Csomewhere.=E2=80=9D The = output is temporarily stored since the destination ... >=20 >>> I will replace queue with buffer for now. >>>=20 >>>> (5) I don't understand why the 'program' elements are included in = the task configurations and capabilities. It doesn't seem wise to allow = the controller to tell the MA which program it needs to use to complete = a task, and I don't understand why the MA would need to communicate that = information to the controller either. I thought the recent list = discussion indicated that if an MA was not capable of performing an = action, that action would simply fail, which seems like all that is = needed. >>>=20 >>> There are multiple things: >>>=20 >>> (a) How do I tell which task I want to have executed? The = information >>> model assumes that this can be done with the help of a registry. >>> The YANG data model, in addition, allows to use a simple 'program >>> name'. Note that this is a choice, i.e., you either use a registry >>> or a program name, but not both. >>>=20 >>> The registry at the end is just some level of indirection - but >>> this indirection also requires to have tasks registered in a >>> registry. Right now, the implementation I know of only supports >>> program names. >>>=20 >>> (b) The task list in the capabilities branch serves as an inventory, >>> i.e., it tells the controller which tasks are supported by a given >>> implementation. The other task list defined options that are used >>> when a certain task is invoked (the Task Configuration in the >>> information model). If a controller configures a task that the >>> agent does support (i.e., it is not listed in the capability >>> tasks), it will not be executed. >>>=20 >>> Note that a capability task name 'traceroute' exposed by the LMAP >>> agent does not necessarily mean that there is a program called >>> traceroute at the operating system level. In fact, an implementation >>> could choose to run traceroute internally without an explicit system >>> level process (like RIPE Atlas did everything in a big event loop, = not >>> sure whether this is still the case). >>=20 >> Ok, I can understand that under circumstances where there is no = registry, there needs to be some identifier to indicate which task to = run, and which tasks the MA is capable of running. But the examples seem = to imply that =E2=80=98program=E2=80=99 is the path and file name of the = actual executable on the MA, which is what seems dangerous and = unnecessary to me. >=20 > I can take out the path if that helps. Yes. >=20 > Why would the controller necessarily even know where such executables = reside on the file system? And I know there are a lot of things that = could go wrong if a Controller gets compromised, but it just seems like = making it so trivial for an MA implementation to literally just run the = executable name specified by the Controller creates unnecessary risk. >=20 > Perhaps we need to add more explicit text to /tasks/task saying that a > configured LMAP task MUST resolve to a task listed in the = capabilities. > This is in my view what matters most. Agree. >=20 >> If the task name on its own is not sufficient for the MA to be able = to figure out which program is suitable to run, why not have the = additional field defined as =E2=80=98program-name=E2=80=99 with some = guidance about how to populate it, so that, e.g., what you end up with = in that field is =E2=80=9Cmtr=E2=80=9D or =E2=80=9Cfping=E2=80=9D = instead of "/usr/bin/mtr=E2=80=9D or "/usr/bin/fping=E2=80=9D? >=20 > I do not really see the logic here. An implementation that blindly > executes a program called 'mtr' by search a search PATH may actually > be worse than an implementation that executes /some/path/mtr. But at least that leaves it up to the implementation to be implemented = safely, rather than building an attack vector directly into the data = model design. >=20 >>>> Nits and minor comments: >>>=20 >>>> (2) "Implementers MUST taken care that >>>> option names and values are passed literally to programs. In >>>> particular, it MUST be avoided that any shell expansions are >>>> performed that may alter the option names and values." >>>>=20 >>>> This text strikes me as a bit odd. Surely there are a whole = selection of good programming practices that are necessary to ensure = that things don't go haywire when implementing LMAP -- why call out = these two with normative recommendations? Why does this guidance only = apply to options? I would recommend having this text be non-normative, = but if you do keep it I would suggest the following: >>>>=20 >>>> Implementers MUST take care that >>>> option names and values are passed literally to programs. In >>>> particular, shell expansions that may alter the option names and = values MUST NOT be performed. >>>=20 >>> I have no strong opinion on MUST vs must here and I usually happily >>> follow the advice of IESG members on RFC 2119 keywords. ;-) >>=20 >> Ok, my suggestion is to use non-normative =E2=80=9Cought to=E2=80=9D = rather than 2119 MUST. >=20 > Seriously? Yes, this comes up all the time in IESG eval and I would be willing to = bet that another AD will comment on the use of lowercase must. > I have left the 'must' in (there are other occurances of > must) and I leave it to the discretion of the IESG to discuss this if > needed - and then I do whatever comes out of it. Ok. Alissa >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Feb 8 03:35: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 0FFC51296C3 for ; Wed, 8 Feb 2017 03:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lBrN_pzTvit for ; Wed, 8 Feb 2017 03:35:03 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5D81295ED for ; Wed, 8 Feb 2017 03:35:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EB4037B6; Wed, 8 Feb 2017 12:35:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5TrBxx3LRMsF; Wed, 8 Feb 2017 12:34:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Feb 2017 12:35:01 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33CEE200BE; Wed, 8 Feb 2017 12:35:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ck3Z0E9uW8Ay; Wed, 8 Feb 2017 12:35:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7410E200BD; Wed, 8 Feb 2017 12:35:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8E2AC3E6C2A5; Wed, 8 Feb 2017 12:35:02 +0100 (CET) Date: Wed, 8 Feb 2017 12:35:02 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170208113501.GC97665@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> <20170126101706.GD43055@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:35:06 -0000 On Tue, Feb 07, 2017 at 10:31:17AM -0500, Alissa Cooper wrote: > > > On Jan 26, 2017, at 5:17 AM, Juergen Schoenwaelder wrote: > > > > Trimming things down... > > > > On Wed, Jan 25, 2017 at 01:25:26PM -0500, Alissa Cooper wrote: > >>> > >>>> (4) "A queue is internally used to pass > >>>> results to another schedule." > >>>> > >>>> I thought it was up to the implementation to decide how to implement this? > >>> > >>> OK. I meanwhile understand that the word 'queue' has too many > >>> connotations. Is 'buffer' a less problematic term? The key here is > >>> that the data producer and the data consumer are in general not > >>> running at the time and hence data needs to be stored temporarily > >>> somewhere. > >> > >> Isn’t this implied though? Even with “buffer” it still seems like specifying an implementation detail. I’d prefer to see something like your last sentence above instead. > > > > So I will replace 'buffer' with 'somewhere'. Oh boy. Here is the > > new text: > > > > A set of schedules receiving the output produced > > by this action. The output is stored temporarily > > somewhere since the destination schedules will in > > general not be running when output is passed to > > them. The behaviour of an action passing data to > > its own schedule is implementation specific. > > I don’t think you need to say “somewhere.” The output is temporarily stored since the destination ... > OK > > Why would the controller necessarily even know where such executables reside on the file system? And I know there are a lot of things that could go wrong if a Controller gets compromised, but it just seems like making it so trivial for an MA implementation to literally just run the executable name specified by the Controller creates unnecessary risk. > > > > Perhaps we need to add more explicit text to /tasks/task saying that a > > configured LMAP task MUST resolve to a task listed in the capabilities. > > This is in my view what matters most. > > Agree. Here is the new text: list task { key name; description "The list of tasks configured on the LMAP agent. Note that a configured task must resolve to a task listed in the capabilities. Attempts to execute a configured task that is not listed in the capabilities result in a runtime execution error."; > >> If the task name on its own is not sufficient for the MA to be able to figure out which program is suitable to run, why not have the additional field defined as ‘program-name’ with some guidance about how to populate it, so that, e.g., what you end up with in that field is “mtr” or “fping” instead of "/usr/bin/mtr” or "/usr/bin/fping”? > > > > I do not really see the logic here. An implementation that blindly > > executes a program called 'mtr' by search a search PATH may actually > > be worse than an implementation that executes /some/path/mtr. > > But at least that leaves it up to the implementation to be implemented safely, rather than building an attack vector directly into the data model design. > I think the above proposed new text actually takes care of this. Something not listed in the capabilities can't be executed. > >>>> Nits and minor comments: > >>> > >>>> (2) "Implementers MUST taken care that > >>>> option names and values are passed literally to programs. In > >>>> particular, it MUST be avoided that any shell expansions are > >>>> performed that may alter the option names and values." > >>>> > >>>> This text strikes me as a bit odd. Surely there are a whole selection of good programming practices that are necessary to ensure that things don't go haywire when implementing LMAP -- why call out these two with normative recommendations? Why does this guidance only apply to options? I would recommend having this text be non-normative, but if you do keep it I would suggest the following: > >>>> > >>>> Implementers MUST take care that > >>>> option names and values are passed literally to programs. In > >>>> particular, shell expansions that may alter the option names and values MUST NOT be performed. > >>> > >>> I have no strong opinion on MUST vs must here and I usually happily > >>> follow the advice of IESG members on RFC 2119 keywords. ;-) > >> > >> Ok, my suggestion is to use non-normative “ought to” rather than 2119 MUST. > > > > Seriously? > > Yes, this comes up all the time in IESG eval and I would be willing to bet that another AD will comment on the use of lowercase must. I do what you recommend. > > I have left the 'must' in (there are other occurances of > > must) and I leave it to the discretion of the IESG to discuss this if > > needed - and then I do whatever comes out of it. > > Ok. There are now three lowercase 'must' left. So IESG members searching for musts have something left to look at. ;-) If you want me to replace some of them with 'ought to' or other phrases, let me know. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 8 05:09: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 3BEB5129A15 for ; Wed, 8 Feb 2017 05:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 FBcIT9tvun_d for ; Wed, 8 Feb 2017 05:09:42 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24AD12940A for ; Wed, 8 Feb 2017 05:09:41 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v18D4obH000468; Wed, 8 Feb 2017 08:09:39 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 28g0d1kff7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Feb 2017 08:09:38 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v18D9aef028363; Wed, 8 Feb 2017 08:09:37 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v18D9UwV028215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 08:09:33 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 8 Feb 2017 13:09:19 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v18D9JF4031932; Wed, 8 Feb 2017 07:09:19 -0600 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v18D9Aef031427; Wed, 8 Feb 2017 07:09:10 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 42340E23AF; Wed, 8 Feb 2017 08:09:08 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 08:09:09 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "Alissa Cooper" Thread-Topic: [lmap] AD evaluation: draft-ietf-lmap-yang-10 Thread-Index: AQHSdludDjcLPOVF3EGR+tuQhbA1+KFIZnCAgAFxdgCAAQnkAIATM8KAgAFQUwD//8OgsA== Date: Wed, 8 Feb 2017 13:09:09 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF6894C8@njmtexg5.research.att.com> References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> <20170126101706.GD43055@elstar.local> <20170208113501.GC97665@elstar.local> In-Reply-To: <20170208113501.GC97665@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.205.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702080128 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:09:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVlcmdlbg0KLi4uDQo+IA0KPiA+ID4gV2h5 IHdvdWxkIHRoZSBjb250cm9sbGVyIG5lY2Vzc2FyaWx5IGV2ZW4ga25vdyB3aGVyZSBzdWNoDQo+ IGV4ZWN1dGFibGVzIHJlc2lkZSBvbiB0aGUgZmlsZSBzeXN0ZW0/IEFuZCBJIGtub3cgdGhlcmUg YXJlIGEgbG90IG9mDQo+IHRoaW5ncyB0aGF0IGNvdWxkIGdvIHdyb25nIGlmIGEgQ29udHJvbGxl ciBnZXRzIGNvbXByb21pc2VkLCBidXQgaXQganVzdA0KPiBzZWVtcyBsaWtlIG1ha2luZyBpdCBz byB0cml2aWFsIGZvciBhbiBNQSBpbXBsZW1lbnRhdGlvbiB0byBsaXRlcmFsbHkNCj4ganVzdCBy dW4gdGhlIGV4ZWN1dGFibGUgbmFtZSBzcGVjaWZpZWQgYnkgdGhlIENvbnRyb2xsZXIgY3JlYXRl cw0KPiB1bm5lY2Vzc2FyeSByaXNrLg0KPiA+ID4NCj4gPiA+IFBlcmhhcHMgd2UgbmVlZCB0byBh ZGQgbW9yZSBleHBsaWNpdCB0ZXh0IHRvIC90YXNrcy90YXNrIHNheWluZyB0aGF0IGENCj4gPiA+ IGNvbmZpZ3VyZWQgTE1BUCB0YXNrIE1VU1QgcmVzb2x2ZSB0byBhIHRhc2sgbGlzdGVkIGluIHRo ZSBjYXBhYmlsaXRpZXMuDQo+ID4gPiBUaGlzIGlzIGluIG15IHZpZXcgd2hhdCBtYXR0ZXJzIG1v c3QuDQo+ID4NCj4gPiBBZ3JlZS4NCj4gDQo+IEhlcmUgaXMgdGhlIG5ldyB0ZXh0Og0KPiANCj4g ICAgICAgbGlzdCB0YXNrIHsNCj4gICAgICAgICBrZXkgbmFtZTsNCj4gCWRlc2NyaXB0aW9uDQo+ ICAgICAgICAgICAiVGhlIGxpc3Qgb2YgdGFza3MgY29uZmlndXJlZCBvbiB0aGUgTE1BUCBhZ2Vu dC4gTm90ZQ0KPiAgICAgICAgICAgIHRoYXQgYSBjb25maWd1cmVkIHRhc2sgbXVzdCByZXNvbHZl IHRvIGEgdGFzayBsaXN0ZWQNCj4gICAgICAgICAgICBpbiB0aGUgY2FwYWJpbGl0aWVzLiBBdHRl bXB0cyB0byBleGVjdXRlIGEgY29uZmlndXJlZA0KPiAgICAgICAgICAgIHRhc2sgdGhhdCBpcyBu b3QgbGlzdGVkIGluIHRoZSBjYXBhYmlsaXRpZXMgcmVzdWx0IGluDQo+ICAgICAgICAgICAgYSBy dW50aW1lIGV4ZWN1dGlvbiBlcnJvci4iOw0KPiANCltBQ01dIA0KVGhlIHNlY29uZCBzZW50ZW5j ZSBpcyBhIHJlcXVpcmVtZW50IG9uIGltcGxlbWVudGF0aW9ucywgDQpmb3IgdGhlIENvbnRyb2xs ZXIgdG8gb2JleSBhbmQgZm9yIHRoZSBNQSB0byBldmFsdWF0ZSwgc28NCnMvbXVzdC9NVVNULw0K aW4gdGhlIG5ldyB0ZXh0PyAgT3IsICJvdWdodCB0byIgPw0KDQpBbA0KDQoNCg== From nobody Wed Feb 8 05:15:03 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 AA96D129A25 for ; Wed, 8 Feb 2017 05:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZWKvkyWg5_G for ; Wed, 8 Feb 2017 05:15:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D8D129A21 for ; Wed, 8 Feb 2017 05:15:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0EF157F1; Wed, 8 Feb 2017 14:14:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HU5bvjBvf5n2; Wed, 8 Feb 2017 14:14:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Feb 2017 14:14:58 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACB63200BE; Wed, 8 Feb 2017 14:14:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IYVBKLYvyznH; Wed, 8 Feb 2017 14:14:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36394200BD; Wed, 8 Feb 2017 14:14:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2E28E3E6C799; Wed, 8 Feb 2017 14:15:02 +0100 (CET) Date: Wed, 8 Feb 2017 14:15:02 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20170208131502.GD98187@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , Alissa Cooper , "lmap@ietf.org" References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> <20170126101706.GD43055@elstar.local> <20170208113501.GC97665@elstar.local> <4D7F4AD313D3FC43A053B309F97543CF6894C8@njmtexg5.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF6894C8@njmtexg5.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Alissa Cooper , "lmap@ietf.org" Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:15:01 -0000 On Wed, Feb 08, 2017 at 01:09:09PM +0000, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > ... > > > > > > Why would the controller necessarily even know where such > > executables reside on the file system? And I know there are a lot of > > things that could go wrong if a Controller gets compromised, but it just > > seems like making it so trivial for an MA implementation to literally > > just run the executable name specified by the Controller creates > > unnecessary risk. > > > > > > > > Perhaps we need to add more explicit text to /tasks/task saying that a > > > > configured LMAP task MUST resolve to a task listed in the capabilities. > > > > This is in my view what matters most. > > > > > > Agree. > > > > Here is the new text: > > > > list task { > > key name; > > description > > "The list of tasks configured on the LMAP agent. Note > > that a configured task must resolve to a task listed > > in the capabilities. Attempts to execute a configured > > task that is not listed in the capabilities result in > > a runtime execution error."; > > > [ACM] > The second sentence is a requirement on implementations, > for the Controller to obey and for the MA to evaluate, so > s/must/MUST/ > in the new text? Or, "ought to" ? > I am fine with MUST but I always happily follow advice of IESG members when it comes to RFC 2119 language. So will use MUST for now. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 8 05:59:56 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 532C4129A3D for ; Wed, 8 Feb 2017 05:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=FfeGihH9; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=OoxpvPDL 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 FBS4ST0UFgTi for ; Wed, 8 Feb 2017 05:59:52 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C092F129A32 for ; Wed, 8 Feb 2017 05:59:52 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2A3A020681; Wed, 8 Feb 2017 08:59:52 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 08:59:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=cKjhLMePS/9gs0yDhBILTziu1CA=; b=FfeGih H9MD+jFQNUwo7G9r2pUZS6OMBILUQbhv+NB/LuVusKeCrtEHNJOFj0Q2Bb+Rrhxr TpYTvKYmsazZPqaeRmK397/cAOyISCKbStlFwNUMETrzoxt9l/0saE9jOLBZwR/g zjNG8fb76mMBJCyDeUTU41c3QwcZZ/hZJ0qXY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=cKjhLMePS/9gs0 yDhBILTziu1CA=; b=OoxpvPDLzBZecEXDJ/mjdGo8WADJmC/9e+LbhRG3NS/MBG O7HpiIrl+APW6RUgJhDvneG4NqEPCQdlNjOyAYHjbOGfQGa+lr+OYJ+GUqmtBMLN 8uiWNcl+x4y4OlJTx3+XwTM5i8LhI/0LH+kgrFti7nosa0zb2FZMP5ghAvg7o= X-ME-Sender: X-Sasl-enc: uqaMg8Yf2eQzroeV7cUVFwoWr+PxJHcQg8oD9g0LfDvV 1486562391 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 3045E2414A; Wed, 8 Feb 2017 08:59:51 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_29AC5EDC-4012-4CEC-B698-1C95D398FDBC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170208131502.GD98187@elstar.local> Date: Wed, 8 Feb 2017 08:59:51 -0500 Message-Id: References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> <20170126101706.GD43055@elstar.local> <20170208113501.GC97665@elstar.local> <4D7F4AD313D3FC43A053B309F97543CF6894C8@njmtexg5.research.att.com> <20170208131502.GD98187@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:59:54 -0000 --Apple-Mail=_29AC5EDC-4012-4CEC-B698-1C95D398FDBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 8, 2017, at 8:15 AM, Juergen Schoenwaelder = wrote: >=20 > On Wed, Feb 08, 2017 at 01:09:09PM +0000, MORTON, ALFRED C (AL) wrote: >>> -----Original Message----- >>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >> ... >>>=20 >>>>> Why would the controller necessarily even know where such >>> executables reside on the file system? And I know there are a lot of >>> things that could go wrong if a Controller gets compromised, but it = just >>> seems like making it so trivial for an MA implementation to = literally >>> just run the executable name specified by the Controller creates >>> unnecessary risk. >>>>>=20 >>>>> Perhaps we need to add more explicit text to /tasks/task saying = that a >>>>> configured LMAP task MUST resolve to a task listed in the = capabilities. >>>>> This is in my view what matters most. >>>>=20 >>>> Agree. >>>=20 >>> Here is the new text: >>>=20 >>> list task { >>> key name; >>> description >>> "The list of tasks configured on the LMAP agent. Note >>> that a configured task must resolve to a task listed >>> in the capabilities. Attempts to execute a configured >>> task that is not listed in the capabilities result in >>> a runtime execution error."; >>>=20 >> [ACM]=20 >> The second sentence is a requirement on implementations,=20 >> for the Controller to obey and for the MA to evaluate, so >> s/must/MUST/ >> in the new text? Or, "ought to" ? >>=20 >=20 > I am fine with MUST but I always happily follow advice of IESG members > when it comes to RFC 2119 language. So will use MUST for now. Agree that MUST is better here. The rest of the changes look good to me. Thanks, Alissa >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --Apple-Mail=_29AC5EDC-4012-4CEC-B698-1C95D398FDBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 8, 2017, at 8:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Feb 08, 2017 at 01:09:09PM +0000, = MORTON, ALFRED C (AL) wrote:
-----Original = Message-----
From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen
...

Why would the controller necessarily even know = where such
executables reside on = the file system? And I know there are a lot of
things that = could go wrong if a Controller gets compromised, but it just
seems like making it so trivial for an MA implementation to = literally
just run the executable name specified by the = Controller creates
unnecessary risk.

Perhaps we need to add more explicit text to = /tasks/task saying that a
configured LMAP task MUST = resolve to a task listed in the capabilities.
This is in = my view what matters most.

Agree.

Here is the = new text:

     list = task {
       key = name;
description
         "The = list of tasks configured on the LMAP agent. Note
          tha= t a configured task must resolve to a task listed
          in = the capabilities. Attempts to execute a configured
          tas= k that is not listed in the capabilities result in
          a = runtime execution error.";

[ACM] 
The second = sentence is a requirement on implementations, 
for the = Controller to obey and for the MA to evaluate, so
s/must/MUST/
in the new text?  Or, "ought = to" ?


I am fine with MUST but I always happily = follow advice of IESG members
when it comes to RFC 2119 language. So = will use MUST for now.

Agree that = MUST is better here.

The rest of the = changes look good to me.

Thanks,
Alissa


/js

-- 
Juergen = Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>

= --Apple-Mail=_29AC5EDC-4012-4CEC-B698-1C95D398FDBC-- From nobody Wed Feb 8 07:23:53 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5373129BBE for ; Wed, 8 Feb 2017 07:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J77WbzikJ-n for ; Wed, 8 Feb 2017 07:23:51 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51137129526 for ; Wed, 8 Feb 2017 07:23:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1C7D376D; Wed, 8 Feb 2017 16:23:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LfV--A0AkcbU; Wed, 8 Feb 2017 16:23:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Feb 2017 16:23:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC98D200BE; Wed, 8 Feb 2017 16:23:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A7DT0aLDVhMX; Wed, 8 Feb 2017 16:23:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55F2E200BD; Wed, 8 Feb 2017 16:23:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 335063E6CE44; Wed, 8 Feb 2017 16:23:53 +0100 (CET) Date: Wed, 8 Feb 2017 16:23:53 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170208152353.GI98457@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:23:53 -0000 On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote: > > > On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: > >> > >>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder wrote: > >>>> > >>> > >>> The status reports go to the LMAP controller, so I do not really see > >>> why there is a specific risk since the controller has access to the > >>> device ID anyway. > >> > >> I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA. > >> > > > > So here we go. I propose the following change: > > > > - The ma-status-agent-id becomes optional. > > - The ma-status-device-id becomes mandatory again. > > > > Rationale: > > > > If a device does not yet have an MA-ID, then the device-id must be > > accessible such that the controller can configure an MA-ID. > > Section 3.1 says: > > "The MA may be pre-configured with an MA ID, or may use a Device ID in > the first Controller contact before it is assigned an MA ID. The > Device ID may be a MAC address or some other device identifier > expressed as a URI. If the MA ID is not provided at this stage then > it must be provided by the Controller during Configuration.” > > Why would an MA be sending a status report before configuration? > The ma-status-obj models status information, it is not modeling a status report. I think the reason for having the device-id in the status information is that this is the only way to obtain it if it is not configured. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 8 11:38:41 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B394D129428 for ; Wed, 8 Feb 2017 11:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=J9oMxd2N; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=TiyPT/sl 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 KCjukolkF-d6 for ; Wed, 8 Feb 2017 11:38:38 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED2B129FD3 for ; Wed, 8 Feb 2017 11:38:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DE13B204F7; Wed, 8 Feb 2017 14:38:37 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 14:38:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1QQJbay1YGXkkc9 1RpLIARCgabQ=; b=J9oMxd2NiiRqFlWXLJ1Fo1PbTvhPJPqo2HVyclGwBr0Ofv/ KzSq25E1ZlkpJ2MrJs+7AWKrcb7lt/kV3HIMETJcpbuDaoWyxGkKs5OJGhgSfEcX EUebzpOh9OGeyGsef+Uf5tWtv0XVbisQD2YuyJZ0ixN0FitYZs9WUZ6n/0xw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=1QQJbay1YGXkkc91RpLIARCgabQ=; b=TiyPT/slsSI8fy3KSiz0 zINuvhbrHdKvDsDMJ+DjabYkOYAEqqbsw0V/SGvlHMrcDDbM4832WYOIk9gKhiX+ 6EAm1mzmd+novspgK5zfG0da3PBkYJVJEL1T/CxcI0MOyc2aWm+RTLp+fegUdbxN AWvjOty8OJV1LqbDYObyZjE= X-ME-Sender: X-Sasl-enc: r7uOU6JoyGgm/PZX7OvrqyyUEc2ieEb71bqUKiM/5VUc 1486582717 Received: from dhcp-10-150-9-221.cisco.com (unknown [173.38.117.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 8FAB57E459; Wed, 8 Feb 2017 14:38:37 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170208152353.GI98457@elstar.local> Date: Wed, 8 Feb 2017 14:38:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <20170208152353.GI98457@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:38:39 -0000 > On Feb 8, 2017, at 10:23 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote: >>=20 >>> On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: >>>>=20 >>>>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder = wrote: >>>>>>=20 >>>>>=20 >>>>> The status reports go to the LMAP controller, so I do not really = see >>>>> why there is a specific risk since the controller has access to = the >>>>> device ID anyway. >>>>=20 >>>> I still am missing what is the rationale for sending the device ID = in the status reports. I thought the agent ID was meant to uniquely = identify the MA. >>>>=20 >>>=20 >>> So here we go. I propose the following change: >>>=20 >>> - The ma-status-agent-id becomes optional. >>> - The ma-status-device-id becomes mandatory again. >>>=20 >>> Rationale: >>>=20 >>> If a device does not yet have an MA-ID, then the device-id must be >>> accessible such that the controller can configure an MA-ID. >>=20 >> Section 3.1 says: >>=20 >> "The MA may be pre-configured with an MA ID, or may use a Device ID = in >> the first Controller contact before it is assigned an MA ID. The >> Device ID may be a MAC address or some other device identifier >> expressed as a URI. If the MA ID is not provided at this stage = then >> it must be provided by the Controller during Configuration.=E2=80=9D >>=20 >> Why would an MA be sending a status report before configuration? >>=20 >=20 > The ma-status-obj models status information, it is not modeling a > status report. I think the reason for having the device-id in the > status information is that this is the only way to obtain it if it is > not configured. Ok. But in a setup where the controller doesn=E2=80=99t actually need = the device-id (because the agent-id is pre-configured and the controller = uses that to uniquely identify the MA), this requires the device-id to = be divulged to the controller unnecessarily. That case could be = accommodated by making both the agent-id and the device-id optional and = specifying that the device-id should be provided if it was not provided = in pre-configuration. Alissa >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Feb 8 11:40: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 638A0129FE3 for ; Wed, 8 Feb 2017 11:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=gd0ZMW78; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=iB6uB+My 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 pI2fG6T-gK79 for ; Wed, 8 Feb 2017 11:39:59 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2AE129FE4 for ; Wed, 8 Feb 2017 11:39:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8968D20B7D; Wed, 8 Feb 2017 14:39:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 14:39:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=AnA6j5bAFqufbUJ2RkP1A0mcVuk=; b=gd0ZMW 78r8ujs4CNM9bDtxjyTbKxiN04cETsOS+KJcDrvZ9EfzToWoruWPXx1xfS4zmWMD 5DK/vqSwObMGyvG0gpMTkav+CIkM0PCsZx6DMkI05Z3s6l64C8tC7AyZeFJdQh+Z JJGi1fLQZAkelNmVdKG/ZJmoiDHCTHlTPKvtQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=AnA6j5bAFqufbU J2RkP1A0mcVuk=; b=iB6uB+MytvkfTAF6UKSC0eSFfQ4vbVU+PA0wTCrvAvsV4l hYw8Cyn258I9v43RZ89gp0L6HxBSIqRCkTLJgXQHLpSxrZA1aNK+Zx4PFa7ZjNH3 nKNgrGv69D+jI/d5+LvJ3b1+Iz2WyQBzjtL7GDbeu2gg/0gAcnJ2ucoAsB7V4= X-ME-Sender: X-Sasl-enc: EjkJ5oEzebBvR73KRhDH4rC2EPxShiTAkQc+PZu6cNXr 1486582798 Received: from dhcp-10-150-9-221.cisco.com (unknown [173.38.117.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 303FB7E06B; Wed, 8 Feb 2017 14:39:58 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_86B20CEC-BD07-4F18-8F11-C72A21342C9D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> Date: Wed, 8 Feb 2017 14:39:58 -0500 Message-Id: References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:40:03 -0000 --Apple-Mail=_86B20CEC-BD07-4F18-8F11-C72A21342C9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 8, 2017, at 2:38 PM, Alissa Cooper wrote: >=20 >>=20 >> On Feb 8, 2017, at 10:23 AM, Juergen Schoenwaelder = wrote: >>=20 >> On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote: >>>=20 >>>> On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder = wrote: >>>>=20 >>>> On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: >>>>>=20 >>>>>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder = wrote: >>>>>>>=20 >>>>>>=20 >>>>>> The status reports go to the LMAP controller, so I do not really = see >>>>>> why there is a specific risk since the controller has access to = the >>>>>> device ID anyway. >>>>>=20 >>>>> I still am missing what is the rationale for sending the device ID = in the status reports. I thought the agent ID was meant to uniquely = identify the MA. >>>>>=20 >>>>=20 >>>> So here we go. I propose the following change: >>>>=20 >>>> - The ma-status-agent-id becomes optional. >>>> - The ma-status-device-id becomes mandatory again. >>>>=20 >>>> Rationale: >>>>=20 >>>> If a device does not yet have an MA-ID, then the device-id must be >>>> accessible such that the controller can configure an MA-ID. >>>=20 >>> Section 3.1 says: >>>=20 >>> "The MA may be pre-configured with an MA ID, or may use a Device ID = in >>> the first Controller contact before it is assigned an MA ID. The >>> Device ID may be a MAC address or some other device identifier >>> expressed as a URI. If the MA ID is not provided at this stage = then >>> it must be provided by the Controller during Configuration.=E2=80=9D >>>=20 >>> Why would an MA be sending a status report before configuration? >>>=20 >>=20 >> The ma-status-obj models status information, it is not modeling a >> status report. I think the reason for having the device-id in the >> status information is that this is the only way to obtain it if it is >> not configured. >=20 > Ok. But in a setup where the controller doesn=E2=80=99t actually need = the device-id (because the agent-id is pre-configured and the controller = uses that to uniquely identify the MA), this requires the device-id to = be divulged to the controller unnecessarily. That case could be = accommodated by making both the agent-id and the device-id optional and = specifying that the device-id should be provided if it was not provided = in pre-configuration. Actually, that last bit should say: if it was not provided in = pre-configuration and if the MA has no agent-id. Alissa >=20 > Alissa >=20 >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap = --Apple-Mail=_86B20CEC-BD07-4F18-8F11-C72A21342C9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 8, 2017, at 2:38 PM, Alissa Cooper <alissa@cooperw.in> = wrote:


On Feb 8, 2017, at = 10:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, Feb 07, 2017 at 10:26:30AM -0500, = Alissa Cooper wrote:

On Jan = 31, 2017, at 2:47 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, Jan 31, 2017 at 09:15:52AM -0500, = Alissa Cooper wrote:

On Jan = 31, 2017, at 4:44 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


The status reports go to the LMAP = controller, so I do not really see
why there is a specific = risk since the controller has access to the
device ID = anyway.

I still am missing = what is the rationale for sending the device ID in the status reports. I = thought the agent ID was meant to uniquely identify the MA.


So here we go. I = propose the following change:

- The = ma-status-agent-id becomes optional.
- The = ma-status-device-id becomes mandatory again.

Rationale:

If a device does not = yet have an MA-ID, then the device-id must be
accessible = such that the controller can configure an MA-ID.

Section 3.1 says:
"The MA may be pre-configured with an MA ID, or may use a = Device ID in
 the first Controller contact before it = is assigned an MA ID.  The
 Device ID may be a = MAC address or some other device identifier
 expressed = as a URI.  If the MA ID is not provided at this stage then
 it must be provided by the Controller during = Configuration.=E2=80=9D

Why would an MA be = sending a status report before configuration?


The ma-status-obj models status = information, it is not modeling a
status report. I think = the reason for having the device-id in the
status = information is that this is the only way to obtain it if it is
not configured.

Ok. But in a setup = where the controller doesn=E2=80=99t actually need the device-id = (because the agent-id is pre-configured and the controller uses that to = uniquely identify the MA), this requires the device-id to be divulged to = the controller unnecessarily. That case could be accommodated by making = both the agent-id and the device-id optional and specifying that the = device-id should be provided if it was not provided in = pre-configuration.

Actually, = that last bit should say: if it was not provided in pre-configuration = and if the MA has no agent-id.

Alissa


Alissa


/js

-- 
Juergen = Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>

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

= --Apple-Mail=_86B20CEC-BD07-4F18-8F11-C72A21342C9D-- From nobody Wed Feb 8 12:42:09 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 BDDC9129491 for ; Wed, 8 Feb 2017 12:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trzNTJj7Iq8a for ; Wed, 8 Feb 2017 12:42:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F1B12947F for ; Wed, 8 Feb 2017 12:42:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 031EF66D; Wed, 8 Feb 2017 21:42:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8lv4Y0D-japC; Wed, 8 Feb 2017 21:42:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Feb 2017 21:42:04 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76475200BE; Wed, 8 Feb 2017 21:42:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fmp7Jf4_i5Xi; Wed, 8 Feb 2017 21:42:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7150200BD; Wed, 8 Feb 2017 21:42:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2EA93E6D565; Wed, 8 Feb 2017 21:42:07 +0100 (CET) Date: Wed, 8 Feb 2017 21:42:07 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170208204207.GB99261@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:42:08 -0000 On Wed, Feb 08, 2017 at 02:38:37PM -0500, Alissa Cooper wrote: > > > On Feb 8, 2017, at 10:23 AM, Juergen Schoenwaelder wrote: > > > > On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote: > >> > >>> On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder wrote: > >>> > >>> On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: > >>>> > >>>>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder wrote: > >>>>>> > >>>>> > >>>>> The status reports go to the LMAP controller, so I do not really see > >>>>> why there is a specific risk since the controller has access to the > >>>>> device ID anyway. > >>>> > >>>> I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA. > >>>> > >>> > >>> So here we go. I propose the following change: > >>> > >>> - The ma-status-agent-id becomes optional. > >>> - The ma-status-device-id becomes mandatory again. > >>> > >>> Rationale: > >>> > >>> If a device does not yet have an MA-ID, then the device-id must be > >>> accessible such that the controller can configure an MA-ID. > >> > >> Section 3.1 says: > >> > >> "The MA may be pre-configured with an MA ID, or may use a Device ID in > >> the first Controller contact before it is assigned an MA ID. The > >> Device ID may be a MAC address or some other device identifier > >> expressed as a URI. If the MA ID is not provided at this stage then > >> it must be provided by the Controller during Configuration.” > >> > >> Why would an MA be sending a status report before configuration? > >> > > > > The ma-status-obj models status information, it is not modeling a > > status report. I think the reason for having the device-id in the > > status information is that this is the only way to obtain it if it is > > not configured. > > Ok. But in a setup where the controller doesn’t actually need the device-id (because the agent-id is pre-configured and the controller uses that to uniquely identify the MA), this requires the device-id to be divulged to the controller unnecessarily. That case could be accommodated by making both the agent-id and the device-id optional and specifying that the device-id should be provided if it was not provided in pre-configuration. > I remain unconvinced. We do not have a notion of 'conditionally optional' in the information model and I do not want to introduce one. In the YANG data mode, the device-id is not present because such an id is covered by other YANG models and those models and we have an access control model to control access, i.e., access control policies are detached from the data definitions. I am fine with a statement that people should be careful about exposing device-ids when this is not needed in the security considerations but I am against changing the information model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 15 12:45: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 5F1691297B8 for ; Wed, 15 Feb 2017 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=tCK++r1N; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=a1jrYBjK 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 vo07t1tvwYoI for ; Wed, 15 Feb 2017 12:45:27 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34CE129717 for ; Wed, 15 Feb 2017 12:45:27 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2278920C3C; Wed, 15 Feb 2017 15:45:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 15 Feb 2017 15:45:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=VgJCDpuircZ4ctsnxi+OfNaP9hs=; b=tCK++r 1NaE3Vin6XdkDHCTEQ9XIUugktFnzXneRHdxZw4NIl9Uo5WpfcWMiHuLctHOBuwH 8gHJqQxQTGKP9IQ/Z98bm3Bgptyi+Y8mnympySWL8gp2Ue9fmaTZ7+OoarwYttYZ SYHMbUH8hrTLYCI73ltdyV9rdYHwOBlkE2PBQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=VgJCDpuircZ4ct snxi+OfNaP9hs=; b=a1jrYBjKRpKAHwCrORRBMUUKoxzY7Muoe1WFI3clMbgmYo C3kXPCipFord/5thg09etsDKVLNgEkqJJVQpjGFd9OZ24Wqe5vYfFYLx9FNqbxKB 8zkeri5+BAYPLFSQmMxOFnoqstGB/ukdN4QRlbpWPVy1Vkp753jAQpOZoQFUg= X-ME-Sender: X-Sasl-enc: X+nV4KKVcCXMe1wda2DgBJlWZ5+caHjHVUMFeA+HAsBG 1487191526 Received: from [10.24.60.139] (unknown [128.107.241.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 10D2024570; Wed, 15 Feb 2017 15:45:25 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DE41B4F-EBB8-4B4A-9E86-5F4C8C948F2A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170208204207.GB99261@elstar.local> Date: Wed, 15 Feb 2017 12:45:22 -0800 Message-Id: References: <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> <20170208204207.GB99261@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:45:29 -0000 --Apple-Mail=_0DE41B4F-EBB8-4B4A-9E86-5F4C8C948F2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 8, 2017, at 12:42 PM, Juergen Schoenwaelder = wrote: >>>=20 >>=20 >> Ok. But in a setup where the controller doesn=E2=80=99t actually need = the device-id (because the agent-id is pre-configured and the controller = uses that to uniquely identify the MA), this requires the device-id to = be divulged to the controller unnecessarily. That case could be = accommodated by making both the agent-id and the device-id optional and = specifying that the device-id should be provided if it was not provided = in pre-configuration. >>=20 >=20 > I remain unconvinced. We do not have a notion of 'conditionally > optional' in the information model and I do not want to introduce > one. >=20 > In the YANG data mode, the device-id is not present because such an id > is covered by other YANG models and those models and we have an access > control model to control access, i.e., access control policies are > detached from the data definitions. I am fine with a statement that > people should be careful about exposing device-ids when this is not > needed in the security considerations but I am against changing the > information model. Ok. Let=E2=80=99s go with that plan then. Alissa >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --Apple-Mail=_0DE41B4F-EBB8-4B4A-9E86-5F4C8C948F2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 8, 2017, at 12:42 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


Ok. But in a setup where the = controller doesn=E2=80=99t actually need the device-id (because the = agent-id is pre-configured and the controller uses that to uniquely = identify the MA), this requires the device-id to be divulged to the = controller unnecessarily. That case could be accommodated by making both = the agent-id and the device-id optional and specifying that the = device-id should be provided if it was not provided in = pre-configuration.


I remain = unconvinced. We do not have a notion of 'conditionally
optional' in the = information model and I do not want to introduce
one.

In the YANG data mode, the device-id is = not present because such an id
is covered by other YANG models and those = models and we have an access
control model to control access, i.e., = access control policies are
detached from the data definitions. I am = fine with a statement that
people should be careful about exposing = device-ids when this is not
needed in the security considerations but = I am against changing the
information model.

Ok. Let=E2=80=99s go with that plan = then.

Alissa


/js

-- 
Juergen = Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>

= --Apple-Mail=_0DE41B4F-EBB8-4B4A-9E86-5F4C8C948F2A-- From nobody Wed Feb 22 12:05:06 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 3A8C1129AE3 for ; Wed, 22 Feb 2017 12:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnmRnTI-6Xfe for ; Wed, 22 Feb 2017 12:05:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14A4129AE4 for ; Wed, 22 Feb 2017 12:05:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8A337A0; Wed, 22 Feb 2017 21:05:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SwbfyZF6FAxE; Wed, 22 Feb 2017 21:04:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Feb 2017 21:05:00 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72C9D200CD; Wed, 22 Feb 2017 21:05:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hHXOfTaHh1CE; Wed, 22 Feb 2017 21:04:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0F7D200CB; Wed, 22 Feb 2017 21:04:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 924FC3E8477C; Wed, 22 Feb 2017 21:05:02 +0100 (CET) Date: Wed, 22 Feb 2017 21:05:01 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170222200501.GB46746@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in> <20170208204207.GB99261@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:05:04 -0000 On Wed, Feb 15, 2017 at 12:45:22PM -0800, Alissa Cooper wrote: > > Ok. Let’s go with that plan then. > I have added Implementations and deployments should also be careful about exposing device-ids when this is not strictly needed. at the end of the second paragraph in the security considerations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 22 12:27:45 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6056129B06; Wed, 22 Feb 2017 12:27:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779525987.31155.16959137367588342092.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 12:27:39 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-17.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:27:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-17.txt Pages : 55 Date : 2017-02-22 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 22 12:27:59 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD5129B13; Wed, 22 Feb 2017 12:27:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779527710.31054.13711543701313325304.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 12:27:57 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-11.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:27:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-11.txt Pages : 60 Date : 2017-02-22 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 22 14:58:19 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 435F1129C60; Wed, 22 Feb 2017 14:58:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148780429426.31159.1164088656119377316.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 14:58:14 -0800 Archived-At: Cc: lmap-chairs@ietf.org, alissa@cooperw.in, draft-ietf-lmap-information-model@ietf.org, lmap@ietf.org, dromasca@gmail.com Subject: [lmap] Last Call: (Information Model for Large-Scale Measurement Platforms (LMAP)) to Proposed Standard X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 22:58:14 -0000 The IESG has received a request from the Large-Scale Measurement of Broadband Performance WG (lmap) to consider the following document: - 'Information Model for Large-Scale Measurement Platforms (LMAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 22 14:58:51 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C30129C3A; Wed, 22 Feb 2017 14:58:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148780432921.31050.12869181311199662809.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 14:58:49 -0800 Archived-At: Cc: lmap-chairs@ietf.org, alissa@cooperw.in, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org, dromasca@gmail.com Subject: [lmap] Last Call: (A YANG Data Model for LMAP Measurement Agents) to Proposed Standard X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 22:58:49 -0000 The IESG has received a request from the Large-Scale Measurement of Broadband Performance WG (lmap) to consider the following document: - 'A YANG Data Model for LMAP Measurement Agents' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Feb 26 13:10:00 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B64B812940D; Sun, 26 Feb 2017 13:09:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148814339074.2901.10793232146724828053.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2017 13:09:50 -0800 Archived-At: Cc: draft-ietf-lmap-information-model.all@ietf.org, ietf@ietf.org, lmap@ietf.org Subject: [lmap] Review of draft-ietf-lmap-information-model-17 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 21:09:51 -0000 Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lmap-information-model-17 Reviewer: Russ Housley Review Date: 2017-02-26 IETF LC End Date: 2017-03-08 IESG Telechat date: Unknown Summary: Ready Major Concerns: Section 3.1 says that the pre-configuration information contains the certificate of the Controller or the certificate of the CA which issued the certificate for the Controller. Section 3.1.1 includes ma-preconfig-credentials. Are these the same? Section 6 says that secure communication channels are needed. This means that some components of this system (at least the Controller) must have secret keys or private keys. I think that Section 6 should talk about which components of this system have keys and the consequences if the keys are not well protected. Minor Concerns: The Introduction in RFC 7594 says: "There is a desire to be able to coordinate the execution of broadband measurements and the collection of measurement results across a large scale set of Measurement Agents (MAs)." The Fact that LMAP is about broadband measurements should be stated in the first paragraph of the Introduction of this document. Nits: In Section 3, the reason for the 6 categories should probably be placed before the list instead of several paragraphs later. In 3.1: s/If the MA ID is not provided at this stage then/ /If the MA ID is not provided at this stage, then/