[lmap] Framework changes

<philip.eardley@bt.com> Tue, 11 November 2014 16:51 UTC

From: philip.eardley@bt.com
To: lmap@ietf.org
Date: Tue, 11 Nov 2014 16:51:28 +0000
Thread-Topic: Framework changes
Thread-Index: Ac/9y1FzSK5wOY5UQ1mKp+Ni6foYQQ==
Message-ID: <A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88E@EMV67-UKRD.domain1.systemhost.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88EEMV67UKRDdoma_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9cHOjlKGGa6npJkSuj_vuQM5acA
Subject: [lmap] Framework changes
Precedence: list

As well as Benoit's comments, I have a couple of other things that came up (I think in the Dublin interim):

*         As well as Capabilities, Failure and Logging Information, the MA can tell the Controller what Instruction it has (and the Controller could request for the MA to send it). This could be useful if the Controller thinks something has gone wrong, and wants to check what Instruction the MA is using.

*         It was suggested to add a bit of guidance about what to do if the MA re-boots or has been off-line for some time (so its instruction may be fail). For instance, assess how stale the Instruction is (assuming the MA is behind a NAT, it will periodically pull a new instruction or at least check for an update); re-set the clock before re-starting measurements; be careful about how re-start measurements after suppression ends (as t; anything else? I think the best place to add text is Section 6.

*         Mention that it's device-specific what the MA should do if it runs out of storage space for results or if it can't contact the controller. Again S6 seems best place

Hope these are ok
Best wishes
phil

[lmap] Framework changes philip.eardley