Subject: [lmap] LMAP detection of "BB line service state"

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 20 Jan 2014 14:21:41 +0000

One thing that is key to the metric "NOT" producing false positive results (negative types), is the ability of the MA to know the "service state" of the broadband line.

  I haven't heard this discussion so I'll contribute -

There are multiple types of ISP service "states" that dynamically change depending upon the terms of service.

Some of the more common ones -

1) Exceeding a cap results in a Bandwidth profile decrease
	- Many wireless carriers / SAT. providers have these in place (read their websites).
	Some are "gentle" enforcements and may not be implemented right at the threshold crossing, others are hard coded.

	Complications to this
	- Some ISP's have a buyout (pay to increase your cap and then you get the full speed back, others don't but it rests on your billing cycle, or possibly at the end of the month.  

   Either way

1) Fair "service tests" are conducted against the terms of service
	-  Provided the "terms of service" are made available / publically know ... they shouldn't be part of performance testing.

So the problem gets to - How does a MA know what the bandwidth state the line is currently based on the "terms of service".
    
Presumption - If we want this to scale, and have low cost then we can't assume manual anything for this "learning" of state.

Recommendation - the BBF liaison had a proposal to share that "state" information with the MA, which seems to be the easiest answer.
			Systemically build a function into the MA that "asks" what the line state information is.

	To do this we'd have to 
	1) add that step to the MA doing a test
	2) Choose what protocols to use to have the MA ask via the home network what the service state is to conduct the test.
		(current speed, service state, .... )

Cheers,
Mike

---

From: <[email-masked]>
Date: Tue, 21 Jan 2014 09:44:19 +0000

Michael,

I think this may depend on who's operating the measurement system.

For an operator-controlled measurement system, then they should know what contract the BB user is on and whether they're currently being capped. In the light of this they can work out what tests they want done. The controller instructs the MA. I'm not sure how up-to-date the Controller can be kept informed about dynamic capping (this info is going via OAM, which isn't very dynamic).
 
For a regulator-controlled measurement system, there is likely to be some off-line way that the ISP tells the regulator what contract the BB user is on - so that they can run sensible tests. After results collection, perhaps the ISP could tell the regulator that user y had exceeded their cap on Jan 21st (so treat those results with caution). I think defining a real-time interface about caps is unlikely. Partly technical (dynamic info, many different capping approaches) and partly commercial.

For an end-user controlled measurement system, I think it would be quite useful for the end user (& their MA) to be able to confirm what contract they are on. Again I think defining a real-time interface about caps is difficult. I think it's something some ISPs might find it useful to tell a subscriber (eg via an email or webpage) but doubtful about standards or about real time (more likely a warning before it starts and, after a time lag, informing them it's happening or happened)

So, rather than dynamically informing the MA about capping, I'd take a different approach. If, for a particular test, it really matters to understand about capping, then there should be a preliminary part of the test where it sends some probe traffic in order to assess this. 

Best wishes
phil

> -----Original Message-----
> From: Bugenhagen, Michael K
> [mailto:[email-masked]]
> Sent: 20 January 2014 14:22
> To: [email-masked]; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R;
> Cook, Charles; [email-masked]'
> Subject: LMAP detection of "BB line service state"
> 
> One thing that is key to the metric "NOT" producing false positive
> results (negative types), is the ability of the MA to know the "service
> state" of the broadband line.
> 
> There are multiple types of ISP service "states" that dynamically
> change depending upon the terms of service.
> 
> 	Some are "gentle" enforcements and may not be implemented right at
> the threshold crossing, others are hard coded.
> 
> 	Complications to this
> 	- Some ISP's have a buyout (pay to increase your cap and then you
> get the full speed back, others don't but it rests on your billing
> cycle, or possibly at the end of the month.
> 
>    Either way
> 
> 	-  Provided the "terms of service" are made available / publically
> know ... they shouldn't be part of performance testing.
> 
> 
> So the problem gets to - How does a MA know what the bandwidth state
> the line is currently based on the "terms of service".
> 
> Presumption - If we want this to scale, and have low cost then we can't
> assume manual anything for this "learning" of state.
> 
> Recommendation - the BBF liaison had a proposal to share that "state"
> information with the MA, which seems to be the easiest answer.
> 	2) Choose what protocols to use to have the MA ask via the home
> network what the service state is to conduct the test.

---

From: KEN KO <[email-masked]>
Date: Tue, 21 Jan 2014 13:09:54 +0000

Mobile operators currently provide traffic volume vs. data cap reporting to subscribers in "near-real time" - that is, current to within about the last 24 hours. So it seems like a similar capability should be feasible with regard to service state for lmap. I think it's a valid question whether that data can be made real time, and whether anything less is actionable by the MA.

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, January 21, 2014 4:44 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] LMAP detection of "BB line service state"

Michael,

 

Best wishes
phil

> To: [email-masked]; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 
> R; Cook, Charles; [email-masked]'
> results (negative types), is the ability of the MA to know the 
> "service state" of the broadband line.
> 
> 	- Some ISP's have a buyout (pay to increase your cap and then you get 
> the full speed back, others don't but it rests on your billing cycle, 
> or possibly at the end of the month.
> 
>    Either way
> 
> Presumption - If we want this to scale, and have low cost then we 
> can't assume manual anything for this "learning" of state.
> 
_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: Charles Cook <[email-masked]>
Date: Tue, 21 Jan 2014 06:36:26 -0700

Service Caps can be an issue.   Since no one has a crystal ball
regarding whether a subscriber will operate close to the service cap,
and since it would not be appropriate for a subscriber to be charged for
a measurement test that they did not request, one possibility is that
when the MA registers with the Measurement Controller, information
regarding the existence of a Service Cap is provided.  If there is a
service cap, then the Measurement Controller simply does not schedule
any bandwidth/throughput tests with that MA. 

If  the service provider that owns the MA runs the test, then I agree
that the service provider can meter their own test and adjust billing to
make the subscriber whole.

If a third party must run a bandwidth/throughput test on an MA with a
Service Cap, then somehow there needs to be a mechanism to meter the
test and charge the third party for their usage of the subscriber's
allocation.  Obviously this would be much more complex.

Another possibility is that the third-party could negotiate with the
service provider increase the service cap beyond what the customer has
subscribed to so that any tests that are run would not eat into the
amount of bandwidth that the customer contracted for with the service
provider.

However it is done, we need to ensure that the subscriber is whole.

Charles

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 21 Jan 2014 13:50:46 +0000

The key point I had in mind was that the test result really needs to have the "service state" information in the actual result to make this truly scalable.

Simple math wise

In a single ISP per speed tier I would assume (and they have many speed tiers)

10k lines
12 measurements a day (minimum required granularity that lets one see a peak hour)
30 days per month.

Yields -  360k test results.... makes a very large spreadsheet... 

   So scalable for any LMAP test IMHO means having sort-able key fields in the test result.

Maybe a really, really small ISP could do a manual processes but if you are doing this in scale per market you'd have to hire a person to do that.
So I don't like added costs on my ISP line - I'll vote for trying to kept this cheap vs. doing to make our jobs a bit easier by not addressing it.

-----Original Message-----
From: Cook, Charles 
Sent: Tuesday, January 21, 2014 7:36 AM
To: [email-masked]
Cc: Bugenhagen, Michael K; [email-masked]; [email-masked]; [email-masked]
Subject: Re: LMAP detection of "BB line service state"

Service Caps can be an issue.   Since no one has a crystal ball
regarding whether a subscriber will operate close to the service cap, and since it would not be appropriate for a subscriber to be charged for a measurement test that they did not request, one possibility is that when the MA registers with the Measurement Controller, information regarding the existence of a Service Cap is provided.  If there is a service cap, then the Measurement Controller simply does not schedule any bandwidth/throughput tests with that MA. 

If  the service provider that owns the MA runs the test, then I agree that the service provider can meter their own test and adjust billing to make the subscriber whole.

If a third party must run a bandwidth/throughput test on an MA with a Service Cap, then somehow there needs to be a mechanism to meter the test and charge the third party for their usage of the subscriber's allocation.  Obviously this would be much more complex.

Another possibility is that the third-party could negotiate with the service provider increase the service cap beyond what the customer has subscribed to so that any tests that are run would not eat into the amount of bandwidth that the customer contracted for with the service provider.

Charles

On 1/21/2014 2:44 AM, [email-masked] wrote:
> For an end-user controlled measurement system, I think it would be 
> quite useful for the end user (& their MA) to be able to confirm what 
> contract they are on. Again I think defining a real-time interface 
> about caps is difficult. I think it's something some ISPs might find 
> it useful to tell a subscriber (eg via an email or webpage) but 
> doubtful about standards or about real time (more likely a warning 
> before it starts and, after a time lag, informing them it's happening 
> or happened)
>

-- 

Charles Cook
Principal Architect
Network

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 21 Jan 2014 14:01:52 +0000

Phil,

   I think the BBF guys felt the MA should do a Pull on the ISP system vs. the other way around.

I would agree with that approach.

I'm also finding out that there are many more types of service "terms" out there than I thought - beyond caps I remember Matt Mathis saying that Malware could impact line performance (part of the line in use all the time), and things like failure to pay (yes I have a teenager) ends up placing you in a walled garden or changes your bandwidth profile.  

  So there are other "line states" out there that we probably don't know about in an ISP terms of service.

So - On the take the high road side, a customer having more information about their line / service is always good....  so making this poll-able from the customer end for a MA that may or may not be and ISP MA sounds like a win-win-win...

Best Regards,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 21, 2014 3:44 AM
To: Bugenhagen, Michael K; [email-masked]; [email-masked]; Cook, Charles; [email-masked]
Subject: RE: LMAP detection of "BB line service state" 

Michael,

 

Best wishes
phil

---

From: KEN KO <[email-masked]>
Date: Tue, 21 Jan 2014 14:01:27 +0000

I think the key point was brought up by Charles - any solution that reports after the fact that a subscriber's cap was exceeded due to traffic added by a test represents a failure condition. The subscriber cannot be disadvantaged by testing conducted by either the operator or a third party. 

As Charles also pointed out, there are multiple ways to prevent this. Some are contractual, not technical (e.g., operator and third party agree to increase data cap by the planned volume of test traffic + margin).

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Tuesday, January 21, 2014 8:51 AM
To: Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] LMAP detection of "BB line service state"

Simple math wise

10k lines

-----Original Message-----
From: Cook, Charles
Sent: Tuesday, January 21, 2014 7:36 AM
To: [email-masked]
Cc: Bugenhagen, Michael K; [email-masked]; [email-masked]; [email-masked]
Subject: Re: LMAP detection of "BB line service state"

Charles

-- 

Charles Cook
Principal Architect
Network

---

From: "Sharam Hakimi" <[email-masked]>
Date: Tue, 21 Jan 2014 09:21:51 -0500

These are part of PRE and POST processing of the measurement task and
data and MA does not need to know these details to perform measurements
in my opinion. The task will be allocated based on the contract and the
results would be matched against any contractual detail.  

Thanks,
Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Tuesday, January 21, 2014 9:01 AM
To: Bugenhagen, Michael K; Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] LMAP detection of "BB line service state"

I think the key point was brought up by Charles - any solution that
reports after the fact that a subscriber's cap was exceeded due to
traffic added by a test represents a failure condition. The subscriber
cannot be disadvantaged by testing conducted by either the operator or a
third party. 

As Charles also pointed out, there are multiple ways to prevent this.
Some are contractual, not technical (e.g., operator and third party
agree to increase data cap by the planned volume of test traffic +
margin).

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen,
Michael K

The key point I had in mind was that the test result really needs to
have the "service state" information in the actual result to make this
truly scalable.

Simple math wise

In a single ISP per speed tier I would assume (and they have many speed
tiers)

10k lines
12 measurements a day (minimum required granularity that lets one see a
peak hour)
30 days per month.

   So scalable for any LMAP test IMHO means having sort-able key fields
in the test result.

Maybe a really, really small ISP could do a manual processes but if you
are doing this in scale per market you'd have to hire a person to do
that.
So I don't like added costs on my ISP line - I'll vote for trying to
kept this cheap vs. doing to make our jobs a bit easier by not
addressing it.

-----Original Message-----
From: Cook, Charles
Sent: Tuesday, January 21, 2014 7:36 AM
To: [email-masked]
Cc: Bugenhagen, Michael K; [email-masked]; [email-masked];
[email-masked]

Charles

On 1/21/2014 2:44 AM, [email-masked] wrote:
> For an operator-controlled measurement system, then they should know
what contract the BB user is on and whether they're currently being
capped. In the light of this they can work out what tests they want
done. The controller instructs the MA. I'm not sure how up-to-date the
Controller can be kept informed about dynamic capping (this info is
going via OAM, which isn't very dynamic).
>  
> For a regulator-controlled measurement system, there is likely to be
some off-line way that the ISP tells the regulator what contract the BB
user is on - so that they can run sensible tests. After results
collection, perhaps the ISP could tell the regulator that user y had
exceeded their cap on Jan 21st (so treat those results with caution). I
think defining a real-time interface about caps is unlikely. Partly
technical (dynamic info, many different capping approaches) and partly
commercial.
> So, rather than dynamically informing the MA about capping, I'd take a
different approach. If, for a particular test, it really matters to
understand about capping, then there should be a preliminary part of the
test where it sends some probe traffic in order to assess this. 
>> 	- Many wireless carriers / SAT. providers have these in place
(read 
>> their websites).
>> 			Systemically build a function into the MA that
"asks"
>> what the line state information is.
>>
>> 	To do this we'd have to

-- 

Charles Cook
Principal Architect
Network

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 21 Jan 2014 14:44:50 +0000

Keep in mind beside testing -

   It's been suggested that the API or website to find out what you service state is should be made global as a standard so people don't have to call their ISP to find out what is going on....

Do you like your ISP's music on hold feature.... ?

:)

-----Original Message-----
From: Sharam Hakimi [mailto:[email-masked]] 
Sent: Tuesday, January 21, 2014 8:22 AM
To: KEN KO; Bugenhagen, Michael K; Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lmap] LMAP detection of "BB line service state"

These are part of PRE and POST processing of the measurement task and data and MA does not need to know these details to perform measurements in my opinion. The task will be allocated based on the contract and the results would be matched against any contractual detail.  

Thanks,
Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Tuesday, January 21, 2014 9:01 AM
To: Bugenhagen, Michael K; Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] LMAP detection of "BB line service state"

As Charles also pointed out, there are multiple ways to prevent this.
Some are contractual, not technical (e.g., operator and third party agree to increase data cap by the planned volume of test traffic + margin).

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Tuesday, January 21, 2014 8:51 AM
To: Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] LMAP detection of "BB line service state"

Simple math wise

10k lines

-----Original Message-----
From: Cook, Charles
Sent: Tuesday, January 21, 2014 7:36 AM
To: [email-masked]
Cc: Bugenhagen, Michael K; [email-masked]; [email-masked]; [email-masked]
Subject: Re: LMAP detection of "BB line service state"

Charles

> For an operator-controlled measurement system, then they should know
what contract the BB user is on and whether they're currently being capped. In the light of this they can work out what tests they want done. The controller instructs the MA. I'm not sure how up-to-date the Controller can be kept informed about dynamic capping (this info is going via OAM, which isn't very dynamic).
> For a regulator-controlled measurement system, there is likely to be
some off-line way that the ISP tells the regulator what contract the BB user is on - so that they can run sensible tests. After results collection, perhaps the ISP could tell the regulator that user y had exceeded their cap on Jan 21st (so treat those results with caution). I think defining a real-time interface about caps is unlikely. Partly technical (dynamic info, many different capping approaches) and partly commercial.
> So, rather than dynamically informing the MA about capping, I'd take a
different approach. If, for a particular test, it really matters to understand about capping, then there should be a preliminary part of the test where it sends some probe traffic in order to assess this. 
(read 
"asks"

-- 

Charles Cook
Principal Architect
Network

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 Jan 2014 14:59:05 +0000

We keep coming back to this, over and over again. My opinion on dealing with this hasn't changed since the last time we discussed it.

There are several components to this:
1. Information model to include in a report all aspects of the environment a test was conducted under. This includes every little aspect of the access service (its states, its configuration, etc.) that we can dream of. I've been trying to do this dreaming of access service aspects in BBF and not IETF, because (IMO) the competency to understand these aspects of access service exist much more in BBF than in IETF. That's why in my last contribution to BBF, I greatly expanded this list in the current BBF draft. My hope is that we can liaise that draft to IETF soon and suggest that lmap include these aspects in their data model, as info that can be included when reporting measurement results. But I don't think that IETF is the right place to argue about what all the right aspects are. Like I said, I think the competency to characterize access services exists more in BBF.

2. Architectural framework for how to get the info to wherever it needs to go. We've discussed (and I thought agreed) that there are various ways this can be architected. As Phil described, some ISPs might choose to do send the data from one of their backend systems to another. Or from their backend systems to regulator or 3rd party systems. I thought we had agreed that this was a valid approach that is allowed but not mandated. I also thought we agreed that lmap (and BBF) will provide no guidance on how to do this (it's out-of-scope for lmap). We also discussed that some ISPs might choose to send this info to their managed device, through the management interface. Again, this would be allowed but not mandated. The management interface is out-of-scope for lmap. I'm quite sure we agreed on that. But in BBF we have a management protocol called TR-069 whose data model we know how to expand to include the ability to supply this info to an RG. OMA-DM could do the same thing for devices managed through the OMA-DM protocol. But all of this is outside the scope of IETF, and outside IETF's sphere of influence. So discussing this sort of stuff in IETF (where the management interface for lmap has been stated to be out-of-scope) is a waste of time. The discussion to expand the data models for these protocols needs to happen in BBF and OMA-DM.

3. Getting the info to devices not managed by the ISP and where there will be no backend system interfaces. I'm still trying to get around to that contribution to homenet for using DNS-SD and mDNS to get info from an ISP-managed device to another device in the home network. But homenet isn't lmap. Of course, this would only help where there exists an ISP-managed device in the home network that can be supplied the info by some mechanism like TR-069 or OMA-DM. It does nothing for the case where no ISP-managed device exists in the home network. There are ways to do this, but I thought we'd agreed that we weren't going to try to tackle "standardizing" or creating a super-simple solution for that use case right now, because we have enough on our plates.

Which leads me right back to where I was before, regarding my personal to-do list:
1. Shore up service attributes in BBF
2. Get the BBF work liaised to IETF and try to get the service attributes included as (optional) "report" elements in the lmap information model. [They are optional because some ISPs might do this association in the backend. They need to be in the report part of the information model because some ISPs might want to send the info to the MA (using the out-of-scope management protocol) for attachment to the reported data.]
3. Do the homenet contribution for DNS-SD / mDNS.
4. Get the service attributes in the TR-069 data model both as info to be included with reported data, and as info that can be provided to the managed device to accomplish this association. [OMA-DM is not on my personal to-do list.]

So Mike and others: What exactly are you wanting from lmap right now? Do you want to move the discussion regarding defining service attributes to IETF and out of BBF? Do you want to try to put the management protocol and interface back in scope in lmap? Do you want lmap to work on this DNS-SD/mDNS thing that I think belongs in homenet and that really needs to have the contribution written describing it (and I'm really trying to get to it for London)? Do you want to forbid ISPs from being allowed to send this info around using their backend systems? Do you want to try to create a standardized solution for the case where there is no ISP-managed device in the home network?  I'm really not understanding the reason for bringing this up in lmap right now.

Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 Jan 2014 15:18:37 +0000

>    It's been suggested that the API or website to find out what you service
> state is should be made global as a standard so people don't have to call their
> ISP to find out what is going on....
> 
> 

I just sent a much longer message, but I'll send an excerpt to respond to this. 
As I mentioned in the other email, I don't think lmap (IETF) is the right place to discuss defining service attributes.
I agree that a website is possible for providing this info. I don't think lmap is the right place to discuss this. I think it's out-of-scope for lmap. I think that once the service attributes are defined (and I want to do this in BBF where competency exists for understanding service attributes), and the xml for providing this info via TR-059 has been specified, and the xml for that homenet contribution that I keep meaning to get to exists, that posting this xml on a website is so simple that I don't need lmap to tell me how. Once xml of service attributes is published somewhere, I know exactly how to create a website that people can log in to or have their MA device log into to read the xml. I don't need lmap to do anything with this. I need lmap to stick to what they've already chartered themselves to do.

Mike, I have no clue what specifically it is that you are wanting lmap to do at this time. You're aware of the work we're doing in BBF. And I recently put a lot of effort into expanding the service attribute section in WT-304. Maybe you could provide comments against that, in BBF. I've said I want to do a homenet contribution to have a DNS-SD / mDNS way to get service attributes from an ISP-managed device in the home network to some other device in the home network. But sending emails to lmap isn't going to make my contribution to homenet happen any quicker.
Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 21 Jan 2014 15:57:36 +0000

>So Mike and others: What exactly are you wanting from lmap right now? Do you want to move the discussion regarding defining service attributes to IETF and out of BBF? Do you want to try to put the management protocol and interface >back in scope in lmap?

   I would like the interface approach.

Why - it's future proof, and by this I mean "cloud proof," or more correctly Cloud Framework aligned. (aka it aligns with NFV frameworks)
	 What most people don't realize about Cloud is that it's a framework - NOT an architecture.

Cloud requires a Common information model about infrastructure - like a API at a location -
	So if we identify some interface when Cloud comes along it can be identified as part of the Infrastructure Layer at that location (the interface / API that is).

But then again I don't think there is a right now given this discussion has been going on for almost a year :)

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Tuesday, January 21, 2014 8:59 AM
To: KEN KO; Bugenhagen, Michael K; Cook, Charles; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: LMAP detection of "BB line service state"

Which leads me right back to where I was before, regarding my personal to-do list:
1. Shore up service attributes in BBF
2. Get the BBF work liaised to IETF and try to get the service attributes included as (optional) "report" elements in the lmap information model. [They are optional because some ISPs might do this association in the backend. They need to be in the report part of the information model because some ISPs might want to send the info to the MA (using the out-of-scope management protocol) for attachment to the reported data.] 3. Do the homenet contribution for DNS-SD / mDNS.
4. Get the service attributes in the TR-069 data model both as info to be included with reported data, and as info that can be provided to the managed device to accomplish this association. [OMA-DM is not on my personal to-do list.]

Barbara