Subject: [lmap] LMAP Information Model: Comments

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sun, 10 Aug 2014 13:32:49 +0000

Trevor,

As I was going through the IM to develop the TR-069 data model I noticed a couple of items that might need clarifications and maybe some consideration.

1)    Item 1
// Channel object with name string allowing reference from Schedule. Contains channel endpoint target URL and security
// credentials to establish secure channel. Optionally allows interface specification (by interface name string reference)
// and connection when no data is pending for transfer
object {
string ma-channel-name;
url ma-channel-target;
credentials ma-channel-credentials;
[string ma-channel-interface-name;]
} ma-channel-obj;

We should define the datatype for credentials - I think you mention it in the text but for a data model - I really needed to know what it constituted.

2)    Item 2

// Task Configuration object with string name to allow reference from Schedule. Contains URI to link to registry or local
// specification of Task. Options allow the configuration of Task parameters (in the form of name-value pairs)
object {
string ma-task-name;
uri ma-task-registry;
name-value-pair ma-task-options<0..*>;
[boolean ma-task-suppress-by-default;] // default: TRUE
[string ma-task-cycle-id;]
} ma-task-obj;

For the "names" in many of these objects it seems we want to make these unique keys within the context of the MA. This may be a problem from the controller perspective. The controller would have to know which "names" are used for what MA. - Much easier to make these names UUIDs and call it a day. - You can still have a label if you like - but identifiers should be unique in the context of the controller.

As to the name-value pair - I think we just need a small comment that this type implementation specific (JSON, XML, TR-069) will all have different formats for name value pairs.

3)    Item 3

// MA Configuration
object {
uuid ma-agent-id;
[ma-task-obj ma-control-tasks<0..*>;]
ma-channel-obj ma-control-channels<1..*>;
[mas-schedule-obj ma-control-schedules<0..*>];
[urn ma-device-id;]

Just a typo mas instead of ma

4)    Item 4

// Report tasks result rows
object {
datetime ma-report-result-time;
string ma-report-conflicting-tasks<0..*>;
[int ma-report-result-cross-traffic;] // Bytes of non-measurement traffic
// on measurement interface during measurement period
data ma-report-result-values<0..*>;
} ma-result-row-obj;

Same comment as name-value pairs - implementation specific

5)    Item 5

// Selected Task interfaces (filtered by Integer list) can be output to other Task Configurations
// (referenced by name string) or connected to input/output Channels (referenced by name string)
object {
[int ma-schedule-task-filters<0..*>;] // default: all
[string ma-schedule-task-output-task-names<0..*>];
[string ma-schedule-task-channel-names<0..*>];
} ma-sched-dataset-obj;

This is the biggest problem that I found: After your explaination these integers represent an index into the a documented output of a registry item (measurement or local) for the scheduled task. - This sounds very "brittle" - Especially if I change the registry item...
Why don't we just give these outputs a URI? Just a thought. Maybe its too heavy.

BTW - I did find a couple of spelling and other editorial comments (e.g., ouput) - I just forgot to note them. I will make a point of getting those on my next review of draft-02.

BR,
Tim

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Aug 2014 18:33:05 +0200

> We should define the datatype for credentials - I think you mention it in the text but for a data model - I really needed to know what it constituted.

But the credentials you need depend on the security features of the
protocol you use. I do not think we can be more precise in the
information model without contraining the protocol choice.
 
> For the "names" in many of these objects it seems we want to make these unique keys within the context of the MA. This may be a problem from the controller perspective. The controller would have to…

I am not sure using UUIDs is a good choice for names yet. Several
deployed systems seem to use names scoped by the local system and in
fact that same name for the same thing over multiple MAs. I do not see
why the names benefit from being globally unique. The MA has a unique
identifier and hence uniqueness can always be achieved when needed.

> As to the name-value pair - I think we just need a small comment
> that this type implementation specific (JSON, XML, TR-069) will all
> have different formats for name value pairs.

Not sure why this would be needed. Again, an information model is
conceptual anyway.
 
> Same comment as name-value pairs - implementation specific

If at all, this is data model specific not implementation
specific. And yes, everything in the information model needs to become
concrete in the data model. So I think such disclaimers are not
needed.
 
> Why don't we just give these outputs a URI? Just a thought. Maybe its too heavy.

I agree that this may need improvement.

> BTW - I did find a couple of spelling and other editorial comments
> (e.g., ouput) - I just forgot to note them. I will make a point of
> getting those on my next review of draft-02.

OK.

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 11 Aug 2014 18:39:35 +0000

Juergen,

Comments inline.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 11:33 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] LMAP Information Model: Comments

On Sun, Aug 10, 2014 at 01:32:49PM +0000, Carey, Timothy (Timothy) wrote:
> // Channel object with name string allowing reference from Schedule. 
> Contains channel endpoint target URL and security // credentials to 
> establish secure channel. Optionally allows interface specification 
> (by interface name string reference) // and connection when no data is 
> pending for transfer object { string ma-channel-name; url 
> ma-channel-target; credentials ma-channel-credentials; [string 
> ma-channel-interface-name;] } ma-channel-obj;
> 

But the credentials you need depend on the security features of the protocol you use. I do not think we can be more precise in the information model without contraining the protocol choice.

<TAC> So we should say the credentials will be dependent on the protocol selected and leave it at that. It's the item 4 discussion.
 
> 2)    Item 2
> 
> // Task Configuration object with string name to allow reference from 
> Schedule. Contains URI to link to registry or local // specification 
> of Task. Options allow the configuration of Task parameters (in the 
> form of name-value pairs) object { string ma-task-name; uri 
> ma-task-registry; name-value-pair ma-task-options<0..*>; [boolean 
> ma-task-suppress-by-default;] // default: TRUE [string 
> ma-task-cycle-id;] } ma-task-obj;
> 

I am not sure using UUIDs is a good choice for names yet. Several deployed systems seem to use names scoped by the local system and in fact that same name for the same thing over multiple MAs. I do not see why the names benefit from being globally unique. The MA has a unique identifier and hence uniqueness can always be achieved when needed.

<TAC> Well then we should say that the MA+Name is what makes it unique. My point was that a controller will need to figure out how to make a the object instance unique. If our expectation is that the name will be unique for that object type in the context of an MA, then lets state that expectation. That way a controller can figure out how it would like to define the names. It also helps people when they develop a data model (e.g., TR-069). Now I know I can put a uniqueKey constraint on all the Name parameters; before your statement I was hesitant given the examples.

> As to the name-value pair - I think we just need a small comment that 
> this type implementation specific (JSON, XML, TR-069) will all have 
> different formats for name value pairs.

Not sure why this would be needed. Again, an information model is conceptual anyway.
 
> Same comment as name-value pairs - implementation specific

If at all, this is data model specific not implementation specific. And yes, everything in the information model needs to become concrete in the data model. So I think such disclaimers are not needed.

<TAC> Indeed you are correct - I was suggesting we provide language in the IM that says when we expect the element to be implementation specific - to state that. I'm not adamant; just concerned about a person picking this up without the benefit of the last year of discussion and looking how to define a credential, or name-value pair or whatever. I know I did a search on these types just to be sure they were not defined and I missed something...
 
> 5)    Item 5
> 
> // Selected Task interfaces (filtered by Integer list) can be output 
> to other Task Configurations // (referenced by name string) or 
> connected to input/output Channels (referenced by name string) object 
> { [int ma-schedule-task-filters<0..*>;] // default: all [string 
> ma-schedule-task-output-task-names<0..*>];

OK.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Aug 2014 21:38:05 +0200

> <TAC> Well then we should say that the MA+Name is what makes it unique. My point was that a controller will need to figure out how to make a the object instance unique. If our expectation is that t…

I am not sure about the "uniqueKey constraint on all the Name
parameters" and surely do not want to be held responsible for whatever
this means. If I were to translate the information model to YANG, the
names would be unique for the given thing they are naming (the
smallest possible scope). For example, I would allow a channel and a
schedule to have the same name but the names of all schedules would
have to be unique and the names of all channels would have to be
unique.

/js