Subject: Re: [lmap] LMAP Information Model - Question

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sun, 21 Jul 2013 12:27:40 +0000

Trevor,

Thanks for the replies -I added the LMAP list.
BR,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 8:40 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Scharf, Michael (Michael)
Subject: RE: LMAP Information Model - Question

Good questions - some discussion inline.....

Trevor.

>From: Carey, Timothy (Timothy) [mailto:[email-masked]] 
>Sent: 16 July 2013 21:32
>To: Burbridge,T,Trevor,TUB8 R
>Cc: 'KEN KO'; Bugenhagen, Michael K; Cook, Charles; 'Stark, Barbara'; Scharf, Michael (Michael)
>Subject: LMAP Information Model - Question
>
>Trevor,
>
>I was looking at your draft-burbridge-lmap-information-model-00 document and had a couple of questions/comments.
>
>Configuration information - is this strictly be the Measurement Controller and MA or can any element have the access rights to configure the MA? My assumption is that any authorized party can configure the MA configuration elements not just the controller? Question is are there information elements that are restricted to only the controller?
>

Yes, our thoughts were that there is only a single controller to simplify the management of the MA. We did not want to get into the complexity of having to delegate rights to other parties. If other parties are involved they can relay there request via the authorised controller.

>You introduced a concept of group membership for a MA. Can a MA belong to multiple groups? Looking at the draft it doesn't seem so but I don't know why we would have restricted it. Also how does a MA know which group this test belongs to it knows if it should report the MA ID?
>

We were thinking that a single Group could be used to capture any unique set of characteristics. It is really only intended as an anonymous group substitute instead of an individual MA ID. Note that other line/device/user characteristics MAY be optionally transmitted in the report.

>I'll have to look at how to integrate the registry aspect to the measurement task - seems the attributes of the task changes based on the test but will be documented in the registry - Maybe we can generalize this somehow in TR-069.
>

The registry will specify some parameters of the measurement task. There are other optional parameters that are configured in the Measurement task Configuration - e.g. test target MA.

>For the schedule - I noticed that there is a list of tasks to execute - Will these have conditional logic in anyway - goes to being either a list or a policy of some sort.
>

To keep things simple again we were expecting this to be a simple list. When one measurement task is finished then the next on the list is started. Each task may include its own back-off behaviour in which case the other tasks would also be delayed. Providing a complex conditional language is maybe too much -  e.g. if it fails wait 1 minute and then be able to displace task X but not task Z etc.

>I assume the measurement suppression is for tasks within a schedule?

The suppression is currently targeted at one or more measurement tasks regardless of which schedules they are included in. I was imagining that most reasons for suppression would mean that we want to disable a task- e.g. code or configuration error for the task. If a schedule is wrong then the schedule can be fixed directly.

>On the status information you will probably want to have a set of defined codes with the ability for  vendor specific codes.

Yes - logging and status information is barely started......

>On the Timing randomness - The integers are what unit - milliseconds, seconds - this one probably needs more description of how to apply the upper, lower and spread to the distribution - Unless this is documented somewhere else - then just point to the reference.
>

More work in progress - yes I would imagine milliseconds.

>In the security section you mentioned the MA context could be excluded but I only saw how the MA ID would be excluded - did I miss something?

In the report information model there is a place for optional MA characteristics such as Michael has been talking about.

>
>BTW - What the information elements do not show is the Read-only vs Read-write aspects of the elements - that would be a good thing to have the in RFC unless be set you mean there are no read-only parameters; also any sizes of the string would help.
>

I think everything is writeable by some entity (either pre-configuration or controller or MA). I don't think the information model is the right place to specify access control for who can write the information.

>
>All-in-all - Nice start; I can use this to start some of the BBF work.
>

Thanks - it would be good to have this discussion on the LMAP list - if you are willing can you respond to this email including the LMAP list?

>BR,
>Tim