IETF Logo Mail Archive

Re: [lmap] /capabilities/task* vs /capabilities/tasks/task*

"Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com> Tue, 03 January 2017 20:27 UTC

Return-Path: <timothy.carey@nokia.com>
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 15FA91296D4 for <lmap@ietfa.amsl.com>; Tue, 3 Jan 2017 12:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0zsdhouA6AuE for <lmap@ietfa.amsl.com>; Tue, 3 Jan 2017 12:27:40 -0800 (PST)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65AD12944A for <lmap@ietf.org>; Tue, 3 Jan 2017 12:27:39 -0800 (PST)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id CD30E4ED78B23; Tue, 3 Jan 2017 20:27:35 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v03KRcOU008979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2017 20:27:38 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v03KRble008751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jan 2017 20:27:38 GMT
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Tue, 3 Jan 2017 15:27:37 -0500
From: "Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "lmap@ietf.org" <lmap@ietf.org>
Thread-Topic: [lmap] /capabilities/task* vs /capabilities/tasks/task*
Thread-Index: AQHSZfwRtfWHXaN6T0mH3TVV6/TYdKEnMX0Q
Date: Tue, 03 Jan 2017 20:27:37 +0000
Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <20170103163223.GA7367@elstar.local>
In-Reply-To: <20170103163223.GA7367@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/tfBOPupLMfcLYwch_1UUcJpEEE4>
Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task*
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 20:27:42 -0000

Juergen,
The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: Tuesday, January 03, 2017 10:32 AM
To: lmap@ietf.org
Subject: [lmap] /capabilities/task* vs /capabilities/tasks/task*

While implementing the /capabilities, I discovered that we do not have a node representing the whole task list in the capabilities branch, i.e., the tasks all appear right below /capabilities. I think it would be simpler and more consistent with all other lists we have if we would have a have tasks appear below /capabilities/tasks. (It would also make sense to move /capabilities before any configuration
branches.)

It is also a bit unclear how capability tasks and configured tasks work together. Right now, I can set the program property on both.
Would it not be more natural to have the program set only on the capability and a configured task can only reference a capability task?
Right now the behaviour is not really clear; I can try to configure a task to run any program, which is likely not what we want. Perhaps the idea is that I can only configure a program listed in the capability tasks. Perhaps we should instead have a way to reference a capability task from a task configuration (and if the reference can't be resolved, the referencing task (and any other indirect references to the referencing task) would not be applied config. Well, what we have may be possible to implement in a reasonable way, even though the details may be not entirely obvious.

/js

PS: I do not really know where the chairs think we are with the LMAP
    documents in their lifecycle. I have implemented what I described
    in the first paragraph in my sources, see the diff here:

    http://www.beadg.de/lmap/draft-ietf-lmap-yang-10-from-09.diff.html

-- 
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/>

v2.23.0 | Report a Bug | By Email