Subject: Re: [lmap] lmap charter - draft 2

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 3 Jun 2013 15:12:48 +0000

Dan, Shane, Barbara - 

   I have been out of the office so I apologize for my input being a bit late..

A few key points I think we need to consider for the charter involve EMS systems, and what Interoperability protocols we need. -

1)  Protocols / Interfaces -

  My conclusion - In order to ensure adoption we have to recognize that MA's on ISP devices will very likely be managed by their existing management protocols (DOCSIS, GPON and DSL existing management protocols MUST be acceptable).   If we choose to ignore this when we may be guilty of driving added cost into Internet services, which seems foolish to me.  To me this means we have a standard information model, and messaging, and choose a nice way making that portable and implementable, and possibly identifying the better IETF protocols and frameworks that require little extra tweaking to make them work.

2)  Inter-operability (protocols)

	Considering #1 and observing the existence of ISP EMS systems, it seems the inter-operation space should be restricted to MA to MA, and MA controller to MA controller like communication protocols.   If we have a like information model, one can split the management protocol, and the test protocols, the management protocol (EMS to MA need not inter-operate), however controller to MA, and MA to MA Must....
Plus I did spec. in an older email that some sort of customer to MA / ISP protocol needs to be standardized for interop as well.

Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Friday, May 31, 2013 4:46 PM
To: STARK, BARBARA H
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: Re: [lmap] lmap charter - draft 2

Hi Barbara,

On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" <[email-masked]> wrote:
>> Amongst the potential _IETF_ protocols that could fulfill the needs 
>> of one or the other functions, the IETF should (attempt to) pick one 
>> of its protocols & data-models for each.  I would not want to see the 
>> LMAP WG select multiple, overlapping _IETF_ protocols to perform a 
>> single function, (e.g.: we should think long & hard and try to select 
>> either SNMP -or- NETCONF/YANG for the "Control Protocol").  The main 
>> benefit with the above approach is for those who desire, like me, to 
>> have a complete "LMAP solution", with all of the necessary protocols 
>> and data-models, _available_ for them to deploy the IETF LMAP WG will have produced such.
> 
> So you are opposed to LMAP being an agent of providing a useful SNMP MIB for all of the existing network elements (and perhaps cable modems) managed via SNMP? 

No.  Please re-read my message, above, carefully.  I recommended the IETF _should_, (I did not say: must), try to pick a single IETF protocol for a particular function.  IMO, it is much, much too early -- the LMAP WG has not even been chartered! -- to declare a single, specific IETF protocol or data-model as a de-facto winner.  This is why I agree with the present charter when it states, for Control & Reporting transport protocols: "to be selected, perhaps REST-style HTTP(s) or IPFIX".  The charter is not mandating a choice right now, but it is /eventually/, at least the way that I'm interpreting it.  Yes, it has made some suggestions, (e.g.: "perhaps"), but I interpret that explanatory and not declarative.

-shane

> Here's my thought process relative to that...
> cost of replacing existing network elements whose main purpose is 
> network connectivity just so it can also do some specific metrics; and have corporate IT organization add a whole new system to the management network (including developing interfaces from other OSs) vs.
> cost of having vendors develop software upgrades for existing network 
> elements with new, additional management interface with different, unfamiliar protocol to a brand new system that corporate IT would have to add to the management network (including developing OS interfaces) vs.
> cost of upgrading existing network element's SNMP management interface 
> and existing management systems

> To me the math is pretty clear. I know what I would recommend to my employer.
> But if LMAP doesn't want to deliver something useful for the embedded base of network elements and devices, and only wants to consider greenfield deployments, I don't think that would stop the SNMP MIB from being created somewhere else.

> So if that's where the consensus lies, then I guess if we could get the Information Model done first, I would be ok. I'll bother the group no further after that. Y'all can deliver anything you want, targeted only to those who desire a complete greenfield "LMAP solution", that has no consideration for re-use/upgrade of anybody's embedded base of devices, network elements, and systems.
> Barbara

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 3 Jun 2013 15:45:45 +0000

> Hi,
> 
> I am against these proposed changes.
> 
> /js

Why?
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Jun 2013 18:41:28 +0200

> > I am against these proposed changes.

I think I already stated my reasoning on the mailing list and I prefer
to not go into circles on the reasoning.

/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: <[email-masked]>
Date: Mon, 3 Jun 2013 17:49:35 +0100

Juergen 
Can you clarify whether you're against all the proposed changes?

The first set (which Shane was ok with), I think are alright with me
The last set (adding and deleting deliverables), I don't like. 

Thanks
phil

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: 31 May 2013 21:06
> To: STARK, BARBARA H
> Cc: Shane Amante; [email-masked]; Romascanu, Dan (Dan)
> On Fri, May 31, 2013 at 07:09:47PM +0000, STARK, BARBARA H wrote:
> > Hi Shane,
> > It sounds like we're very close.
> > Would you agree to the following deliverables?
> >
> > <!-- The following 3 dashed items are taken straight from the most
> recent proposed charter -->
> > - The LMAP Framework - provides common terminology and justifies the
> simplifying constraints
> > - The LMAP Use Cases - provides the motivating use cases as a basis
> for the work
> > - Information Model, the abstract definition of the information
> carried from the Controller to the MA and the information carried from
> the MA to the Collector. It includes
> >
> > <!-- changed "the metric(s) to be measured" to "the metric(s) that
> can be measured", because the Information Model needs to contain the
> full set of potential metrics; the actual set will vary by type of
> network, country, etc. -->
> >   - the metric(s) that can be measured and
> >   values for its parameters such as the Peer MA participating in the
> >   measurement and the desired environmental conditions (for example,
> only
> >   conduct the measurement when there is no user traffic observed)
> >
> > <!-- added a few words at the beginning of the next 2 to make it
> clearer that they were about the Information Model having elements to
> do these things -->
> >   - the schedule: information elements for defining when the
> measurement should be run and how
> >   the results should be reported (when and to which Collector)
> >   - the report: information elements for identifying the metric(s)
> measured and when, the actual
> >   result, and supporting metadata such as location. Result reports
> may
> >   be organized in batches or may be reported immediately, such as for
> an
> >   on-demand measurement.
> >
> > <!-- delete deliverables indicating protocol selection and add -->
> > - SNMP MIB: Data Model consistent with the Information Model, for
> control and reporting using SNMP.
> > - NETCONF data model: Data Model consistent with the Information
> Model, for control and reporting using NETCONF.
> >
> > And maybe (if people want)...
> > - IPFIX data model: Data Model consistent with the Information Model,
> for reporting using IPFIX.
> > - REST-style HTTP(s) data model: Data Model consistent with the
> Information Model, for reporting using REST-style HTTP(s).
> >
> 
> --

---

From: <[email-masked]>
Date: Mon, 3 Jun 2013 17:55:33 +0100

I'm keen for there to be a common (generic) information model
Personally I don't want to standardise extensions to a host of protocols. I'd like to try and pick one. If this proves impossible, then maybe we do more than one, or at least others done elsewhere still have the same information model.

Controller to Controller has not been suggested as in scope (in the charter, BoF, etc). I think the work should focus on the MA's interactions with the Controller and Collector. MA to MA is in scope of IPPM, don't think we should touch it in lmap.

Best wishes
phil

> Bugenhagen, Michael K
> Sent: 03 June 2013 16:13
> To: 'Shane Amante'; STARK, BARBARA H
> A few key points I think we need to consider for the charter involve
> EMS systems, and what Interoperability protocols we need. -
> 
>   My conclusion - In order to ensure adoption we have to recognize that
> MA's on ISP devices will very likely be managed by their existing
> management protocols (DOCSIS, GPON and DSL existing management
> protocols MUST be acceptable).   If we choose to ignore this when we
> may be guilty of driving added cost into Internet services, which seems
> foolish to me.  To me this means we have a standard information model,
> and messaging, and choose a nice way making that portable and
> implementable, and possibly identifying the better IETF protocols and
> frameworks that require little extra tweaking to make them work.
> 
> 
> 	Considering #1 and observing the existence of ISP EMS systems, it
> seems the inter-operation space should be restricted to MA to MA, and
> MA controller to MA controller like communication protocols.   If we
> have a like information model, one can split the management protocol,
> and the test protocols, the management protocol (EMS to MA need not
> inter-operate), however controller to MA, and MA to MA Must....
> Plus I did spec. in an older email that some sort of customer to MA /
> ISP protocol needs to be standardized for interop as well.
> 
> 
> 
> Thanks,
> Mike
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Shane Amante
> > So you are opposed to LMAP being an agent of providing a useful SNMP
> MIB for all of the existing network elements (and perhaps cable modems)
> managed via SNMP?
> 
> No.  Please re-read my message, above, carefully.  I recommended the
> IETF _should_, (I did not say: must), try to pick a single IETF
> protocol for a particular function.  IMO, it is much, much too early --
> the LMAP WG has not even been chartered! -- to declare a single,
> specific IETF protocol or data-model as a de-facto winner.  This is why
> I agree with the present charter when it states, for Control &
> Reporting transport protocols: "to be selected, perhaps REST-style
> HTTP(s) or IPFIX".  The charter is not mandating a choice right now,
> but it is /eventually/, at least the way that I'm interpreting it.
> Yes, it has made some suggestions, (e.g.: "perhaps"), but I interpret
> that explanatory and not declarative.
> 
> -shane
> 
> 
> > network connectivity just so it can also do some specific metrics;
> and have corporate IT organization add a whole new system to the
> management network (including developing interfaces from other OSs) vs.
> > elements with new, additional management interface with different,
> unfamiliar protocol to a brand new system that corporate IT would have
> to add to the management network (including developing OS interfaces)
> vs.
> > But if LMAP doesn't want to deliver something useful for the embedded
> base of network elements and devices, and only wants to consider
> greenfield deployments, I don't think that would stop the SNMP MIB from
> being created somewhere else.
> 
> > So if that's where the consensus lies, then I guess if we could get
> the Information Model done first, I would be ok. I'll bother the group
> no further after that. Y'all can deliver anything you want, targeted
> only to those who desire a complete greenfield "LMAP solution", that
> has no consideration for re-use/upgrade of anybody's embedded base of
> devices, network elements, and systems.
> > Barbara
> 
>

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 3 Jun 2013 17:12:52 +0000

Juergen, Barbara, and Phil,

    I am ok with Barbara's proposal.

 And am wondering if the SNMP is the issue ?

REST "appropriated" the same 4 commands functions from SNMP so I'm hoping that's not the same issue - creation of a model that could be used by both would be awesome.

Best regards,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 03, 2013 11:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] lmap charter - draft 2

Juergen

The first set (which Shane was ok with), I think are alright with me The last set (adding and deleting deliverables), I don't like. 

Thanks
phil

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Juergen Schoenwaelder
> Sent: 31 May 2013 21:06
> To: STARK, BARBARA H

---

From: Brian Trammell <[email-masked]>
Date: Mon, 3 Jun 2013 21:57:05 +0200

Hi, Phil, all,

Trying to catch up on the thread, but wanted to make this point quickly...

> Personally I don't want to standardise extensions to a host of protocols. I'd like to try and pick one. If this proves impossible, then maybe we do more than one, or at least others done elsewhere…

Seconding this. Without a common information model (and a reference architecture, so you have a point of common terminology for talking about the components of the measurement system within that information model), it's hard to see what benefit this effort would have for measurement interoperability.

I think the actual protocols used to do control are less important thereto, and where these protocols touch existing management infrastructure and/or must deal with the specifics of a given access technology, it makes sense that these should be based on existing management protocols from the appropriate forum. You really only need a control protocol that is access technology agnostic when you want to run measurements across different access technologies. As a researcher with access mainly to end systems, I find this a cool feature (and am indeed working on a platform at the moment that has this as a requirement), but I don't think it's necessary for the access measurement use cases we're focused on here.

However, I do think it necessary for the WG to produce at least one instance of a control protocol and report protocol, which could (1) be used in a "pure IP" situation (i.e., where the entity running the measurement does not have privileged access to the underlying access technology and no requirement to integrate tightly with it) and (2) provide a point of reference for other (possibly access technology and management infrastructure specific) protocols sharing the information model. I'm skeptical that just focusing on an information model without having control/report protocols on which to gain implementation experience will provide a generally useful result.

> Controller to Controller has not been suggested as in scope (in the charter, BoF, etc). I think the work should focus on the MA's interactions with the Controller and Collector. MA to MA is in scop…

Agree on all of these points.

Cheers,

Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 3 Jun 2013 21:07:22 +0000

> However, I do think it necessary for the WG to produce at least one instance
> of a control protocol and report protocol, which could (1) be used in a "pure
> IP" situation (i.e., where the entity running the measurement does not have
> privileged access to the underlying access technology and no requirement to
> integrate tightly with it) and (2) provide a point of reference for other
> (possibly access technology and management infrastructure specific)
> protocols sharing the information model. 

FYI. TR-069 is a "pure IP" protocol that has no underlying assumptions regarding or integration with any access technology. It is used by DSL, PON, and DOCSIS operators worldwide to manage modems, routers, gateways, set-top boxes, VoIP analog terminal adaptors, etc., as well as by wireless operators to manage small cell (femtocell) access points attached to a home network (where broadband IP access is not affiliated with the wireless service and is supplied by whomever the end user subscribes to). I'm not providing this information to suggest that LMAP consider TR-069, but merely to make sure that there are no misconceptions about what it is (and isn't). It runs over HTTP(s), using a handful of very generic RPCs to manage parameters defined by an xml data model. 

With that said, I see that I cannot sway the leadership from their desire to try to select an IETF protocol as an LMAP Control Protocol and an LMAP Report Protocol. I can only hope that these will be described as "an" instance of such protocols, and not "the" instance of such protocols.
Barbara

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 3 Jun 2013 21:43:28 +0000

You could make very similar arguments about TCP, routing protocols, VoIP - you name it, more or less just by changing your message slightly. I'm not sure that this is very helpful in the IETF context.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Friday, May 31, 2013 9:07 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] lmap charter - draft 2

Hi Phil,

> I work for BT and believe we also would like protocol-level interoperability.

And do you believe that the only way to achieve protocol-level interoperability is for the IETF to "ensure" it by creating a standards-track RFC with mandatory-to-implement protocols listed? Or might there be other ways to achieve this?

> The case we're particularly interested in is where MAs are embedded in 
> home gateways. They're dual sourced and the selection of vendors 
> changes from one cycle to another. The MAs would interact with the 
> BT-run Controller and Collector, which may be from another vendor that 
> specialises in network management.

>From your description, it sounds like BT is in a position to tell its vendors what protocols to use. Would it not be possible for BT to specify the protocols that BT wants in an RFP, or get together with other European telcos in HGI or BBF to create a home gateway profile that identifies the mandatory-to-implement protocols for BT or for all European telcos? Do you think that the protocols BT or European telcos will want to have implemented are the same as what Level3 would want/need, and the same as US cable operators or US telcos, and that we can all agree on the IETF providing a single standards-track RFC that mandates a single set of protocols for all of us? Because that's *exactly* what's in the charter. A deliverable that defines a mandatory-to-implement "one size fits all" set of protocols. 
 
I've suggested an alternate approach of:
1. Define the LMAP data models for all IETF protocols that people agree are likely to be used for LMAP, 2. For populations who want it, LMAP may define an "architectural profile" or "device profile" that is a targeted informational or BCP recommendation of the profiles that are to be used for that specific population. So if the European telcos wanted IETF to identify the protocols for their devices, they could. And if Level3 wants IETF help to figure out what's right for a Level3-type network, that could also be done. And the set of protocols don't have to be the same. Or the Europeans could do this in HGI or BBF or in their own RFPs.

>From your email, I was unclear whether you were in support of the current charter proposal of deliverables that identify mandatory-to-implement "one size fits all" control and report protocols. Could you clarify that? The charter currently only has deliverables for data models for these mandatory-to-implement protocols. I would prefer if there were data model deliverables for all IETF protocols that people agree are likely to be used for lmap purposes (personally, I think SNMP and netconf are both likely as control protocols). Do you disagree with this and want only the data models for the IETF mandatory-to-implement protocols defined? For example, since that single control protocol probably wouldn't be SNMP, I guess no SNMP MIB would get defined.

A protocol comparison guide might be useful. That is, which protocols might be useful in various networks or devices, depending on characteristics of those networks or devices. This wouldn't be a top priority for me, but I do think it could be useful. But this wouldn't be a mandatory-to-implement standards-track RFC, either.

> I don't take the current language to mean it's mandatory to implement 
> for all ISPs, regulators etc. I'm happy for Dan, Al and Benoit to 
> decide about re- phrasings.

I disagree. The current language is very clear about deliverables that identify "the" control protocol and "the" report protocol, and trying to make these standards track. The language also only has data model deliverables for these 2 protocols, and no others. This isn't just about "re-phrasing".

Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Jun 2013 06:00:53 +0200

> The last set (adding and deleting deliverables), I don't like. 

The change "the metric(s) to be measured" to "the metric(s) that can
be measured" is OK.

The "information element" change I am bit less excited about since
IPFIX uses the term "information element" in a rather different way
and IMHO the change is not needed since all these items are scoped by
"It includes" where "It" refers to the Information Model.

The proposed change of deliverables I do not agree with.

/js

---

From: Capello Alessandro <[email-masked]>
Date: Tue, 4 Jun 2013 11:12:05 +0200

Hi all,

the scenario that we are considering in Telecom Italia includes MA on CPEs but also other MAs (both active and passive) in the aggregation/core portion of the network. The ambition is to have a common measurement infrastructure (one controller) to assist troubleshooting.

I agree that the information model is key, but especially for the latter kind of probes, partially based on internal developments, we would also like to see the IETF converging on a single protocol (a couple, considering controller-to-MA and MA-to-collector communications).

Regarding the re-use of existing management protocols for access technologies (e.g. TR-069, etc.), I think that on one hand they could speed up the deployment of a measurement infrastructure extended to access device, but on the other hand I would like to highlight the complexity of integrating the LMAP infrastructure (especially controller and collector) with multiple management systems (DSL, mobile, etc.). It would probably bring to a multi-controller scenario (each access technology would have its own controller), with inter-controllers communication being explicitly out of scope for LMAP.

Regards,
Alessandro

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 04 Jun 2013 09:49:37 -0300

On 6/3/13 4:57 PM, Brian Trammell wrote:
>  I'm skeptical that just focusing on an information model without having control/report protocols on which to gain implementation experience will provide a generally useful result.

Same to me.

	If we want to accomplish Benoit goal's "Let's not forget that the end
goal is not only for a branch office/managed service type of device, but
also for devices bought directly from BestBuy by the average man in the
street." I doubt that just a data model would do.

Regards,
as

---

From: Benoit Claise <[email-masked]>
Date: Tue, 04 Jun 2013 18:33:40 +0200

Arturo,
> street." I doubt that just a data model would do.
I guess you meant: I doubt that just an information model would do
See RFC 3444.

Regards, Benoit

---

From: <[email-masked]>
Date: Wed, 5 Jun 2013 12:09:55 +0100

it seems that a data model is protocol-specific. but maybe some protocols are similar enough that the data model can be the same?
i guess this might come out of the detailed work, or be considered as part of it

________________________________________
From: Bugenhagen, Michael K [[email-masked]]
Sent: 03 June 2013 18:12
To: Eardley,PL,Philip,TUB8 R; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lmap] lmap charter - draft 2

Best regards,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 03, 2013 11:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] lmap charter - draft 2

Juergen

Thanks
phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Jun 2013 13:29:30 +0200

On Wed, Jun 05, 2013 at 12:09:55PM +0100, [email-masked] wrote:

> it seems that a data model is protocol-specific. but maybe some
> protocols are similar enough that the data model can be the same?

While this is in principle possible, the experience tells us it is
rather unlikely since the devil is in the details (differences in the
atomicity of transactions, the error handling, the constraints on data
and supported encodings, ...).

Since SNMP was mentioned in the context of this statement and SNMP has
lots of protocol specific restrictions, the likelihood to be able to
use a data model written for another protocol with SNMP is very close
to 0%.

/js

---

From: James Miller <[email-masked]>
Date: Wed, 5 Jun 2013 12:49:42 -0400

In the original I-D, I think we excluded elements that did not relate to
the scope of the execution of a predefined schedule of tests for an already
developed sample of measurement devices.  The problem of automating the
identification and exchange of the speed tier, carrier and other
information about the measurement device's provisioned service is a very
important piece that  I think Mike and others have explained is included in
ongoing work at BBForum and elsewhere.  We  referenced in the use cases,
the importance of developing a statistically-valid sample of a set of users
as an important task for many entities undertaking a large-scale
measurement program.

In practice, the FCC's Measuring Broadband America program includes in the
sample creation an exchange with the provisioning carriers to confirm the
speed tier of the provisioned broadband connect.  The benefits we gain are
a rock solid baseline for the provisioned (advertised) rate that supports
our sample refinements, data processing and reporting.  This "validation"
process can be cumbersome and we identify it as one area of concern for
scaling the FCC approach.

It's important to note though that this information is important for
setting up a trial and analyzing data but would be strictly necessary for
the execution Active test measurements with a trial that was already setup.
 For example, we are using largely the same network/transport layer testing
techniques in our Mobile program, but with very different approaches for
developing the sample of measurement devices, interaction of the tests with
devices and privacy approaches, and approaches to reporting.

So while the PHY/MAC layer information is part of the ecosystem, I would
NOT see it as strictly necessary to the protocols for communication between
the measurement servers, devices and other collection elements.  I would
see TR69, MIB definitions and other elements incorporated at different
layers of a LMAP solution.

--
[email-masked]

"Wovon man nicht sprechen kann, darüber muß man schweigen."
(What we cannot speak about we must pass over in silence.  )
Ludwig Josef Johann Wittgenstein

On Mon, Jun 3, 2013 at 5:07 PM, STARK, BARBARA H <[email-masked]> wrote:

> FYI. TR-069 is a "pure IP" protocol that has no underlying assumptions
> regarding or integration with any access technology. It is used by DSL,
> PON, and DOCSIS operators worldwide to manage modems, routers, gateways,
> set-top boxes, VoIP analog terminal adaptors, etc., as well as by wireless
> operators to manage small cell (femtocell) access points attached to a home
> network (where broadband IP access is not affiliated with the wireless
> service and is supplied by whomever the end user subscribes to). I'm not
> providing this information to suggest that LMAP consider TR-069, but merely
> to make sure that there are no misconceptions about what it is (and isn't).
> It runs over HTTP(s), using a handful of very generic RPCs to manage
> parameters defined by an xml data model.
>
> With that said, I see that I cannot sway the leadership from their desire
> to try to select an IETF protocol as an LMAP Control Protocol and an LMAP
> Report Protocol. I can only hope that these will be described as "an"
> instance of such protocols, and not "the" instance of such protocols.
> Barbara
>