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

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 30 May 2013 14:22:02 +0000

> Even if the scope of the initial phase of LMAP is designed on the assumption
> that the measurement system is under the control of a single organization,
> its components (controllers, MAs, collectors) may originate from different
> sources (vendors of equipment and applications). How will we ensure
> interoperability between these components if we do not define/select at
> least one mandatory-to-implement set of protocols and associated data
> models?

Who is asking for IETF to ensure protocol-level interoperability among these components?
I'm definitely not. In my reading of posts of other potential procurers of these measurement systems, I haven't seen any potential procurer ask for this. I could be wrong. If there are service providers who are actively wanting IETF to tell them what protocols to use, I'd like for them to say so.

Here is why I think this is a bad idea.
IMO, the right protocols to use with any given MA depend on a number of factors:
 - Location of the physical device (inside an end user network, or inside a SP network -- note that not all measurements that SPs want to run are intended for end user or regulatory consumption; some are intended for the SP only)
 - Whether or not the underlying physical device is managed by the same MA entity, and what management (bootstrap) protocol is being used for the ones that are managed by that same entity
- Whether or not the underlying physical device is dedicated to the purpose of measurements; if measurements is not the main purpose of the physical device, then the vendor of that device will have a large say in selecting protocols based on what the vendor is comfortable implementing.
- The nature of the actual measurement tests that are to be run
- The preferences of the MA entity (who makes the purchase decisions)

IMO, there are a number of cases where I would recommend TR-069 as the right protocol for control and reporting. I intend to work with BBF to ensure TR-069 can be used for this, in case my employer would like to do that. Other protocols that may be "right" for various conditions include IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for control and reporting), netconf (for control and reporting), IPFIX (for reporting), etc. I already know that the protocols I intend to recommend to my employer are not the same as what some other providers intend to use. From what I can see, all providers are intending to use the protocols that they consider right for them.

There is no "one size fits all" protocol answer. Trying to cram an IETF-defined (because I'm pretty sure IETF would never consider mandating a protocol that was Not Invented Here) protocol down the throats of service providers and vendors will create ill will and mistrust and would be futile (because IETF RFCs can easily be ignored -- SPs assign more decision-making weight to "what's right for me" than they assign to IETF RFCs).

In short, the protocols that are implemented on different devices and network elements will be determined by their procurer and/or the supplier. If we can get interoperable data models and consistency in the parameters used as inputs and outputs of test suites, then it really doesn't matter what the control and reporting protocols are. I've seen vendors swap out or support multiple protocols with little pain. Often, multiple protocols are implemented in chip vendor SoCs. But a consistent data model across all of them -- that's big. The top thing on my IETF wish list is the data model -- both a generic model that could be used by other orgs to create data models for their protocols, and specific SNMP, netconf, and other IETF-defined protocol data models.

My recommendation to IETF wrt actually trying to mandate protocols is "don't go there". The bandwidth spent on the protocol religious debate will impact time available for useful work, and the religious arguments will likely cause mistrust and hard feelings that will impact people's willingness to do the useful work. If IETF is successful in publishing something (because people like me will step back and let the religious pundits publish what they want -- knowing that it's easier to ignore the resulting RFC, than it is to engage in a religious war), the resulting RFC will be ignored by any and all who choose not to adhere to that religion.

With that said, a potentially useful exercise would be to identify which protocols would be better suited to different environments (based on some of the criteria I listed above). But this could be done without attempting to express it as a mandate. This could be presented in the form of useful guidance, as opposed to a religious mandate.
Barbara

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 30 May 2013 14:46:00 +0000

Hi Barbara, 

> Who is asking for IETF to ensure protocol-level interoperability among

Well, this is what most of the work in the IETF is about - achieving on-the-wire interoperability. 

> But a consistent data model across all of them -- that's big. The top thing on my IETF wish list is the data model -- both a generic model that could be used by other orgs to create data models for their protocols, and specific SNMP, netconf, and other IETF-defined protocol data models.

Can you explain what you exactly mean by a 'consistent data model'? You are talking about a range of protocols that spans from 

> IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for
> control and reporting), netconf (for control and reporting), IPFIX (for
> reporting), etc.

There is no data modeling language that would allow to write one data model for all these protocols. How can a 'consistent data model' be written in the absence of a common DML? 

Maybe you mean an Information Model? Please refer to RFC 3444 which talks 'On the Difference between Information Models and Data Models' - the way we use these terms in the IETF. Do you mean that the IETF should focus on developing the Information Models, and maybe some specific data models for the protocols under the IETF responsibility (SNMP, NETCONF, IPFIX)?

Thanks and Regards,

Dan

> -----Original Message-----
> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: Thursday, May 30, 2013 5:22 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: lmap charter - draft 2
> 
> > Even if the scope of the initial phase of LMAP is designed on the
> > assumption that the measurement system is under the control of a
> > single organization, its components (controllers, MAs, collectors) may
> > originate from different sources (vendors of equipment and
> > applications). How will we ensure interoperability between these
> > components if we do not define/select at least one
> > mandatory-to-implement set of protocols and associated data models?
> 
> I'm definitely not. In my reading of posts of other potential procurers
> of these measurement systems, I haven't seen any potential procurer ask
> for this. I could be wrong. If there are service providers who are
> actively wanting IETF to tell them what protocols to use, I'd like for
> them to say so.
> 
>  - Location of the physical device (inside an end user network, or
> inside a SP network -- note that not all measurements that SPs want to
> run are intended for end user or regulatory consumption; some are
> intended for the SP only)
>  - Whether or not the underlying physical device is managed by the same
> MA entity, and what management (bootstrap) protocol is being used for
> the ones that are managed by that same entity
> - Whether or not the underlying physical device is dedicated to the
> purpose of measurements; if measurements is not the main purpose of the
> physical device, then the vendor of that device will have a large say in
> selecting protocols based on what the vendor is comfortable
> implementing.
> IMO, there are a number of cases where I would recommend TR-069 as the
> right protocol for control and reporting. I intend to work with BBF to
> ensure TR-069 can be used for this, in case my employer would like to do
> that. Other protocols that may be "right" for various conditions include
> IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for
> control and reporting), netconf (for control and reporting), IPFIX (for
> reporting), etc. I already know that the protocols I intend to recommend
> to my employer are not the same as what some other providers intend to
> use. From what I can see, all providers are intending to use the
> protocols that they consider right for them.
> 
> There is no "one size fits all" protocol answer. Trying to cram an IETF-
> defined (because I'm pretty sure IETF would never consider mandating a
> protocol that was Not Invented Here) protocol down the throats of
> service providers and vendors will create ill will and mistrust and
> would be futile (because IETF RFCs can easily be ignored -- SPs assign
> more decision-making weight to "what's right for me" than they assign to
> IETF RFCs).
> 
> In short, the protocols that are implemented on different devices and
> network elements will be determined by their procurer and/or the
> supplier. If we can get interoperable data models and consistency in the
> parameters used as inputs and outputs of test suites, then it really
> doesn't matter what the control and reporting protocols are. I've seen
> vendors swap out or support multiple protocols with little pain. Often,
> multiple protocols are implemented in chip vendor SoCs. But a consistent
> data model across all of them -- that's big. The top thing on my IETF
> wish list is the data model -- both a generic model that could be used
> by other orgs to create data models for their protocols, and specific
> SNMP, netconf, and other IETF-defined protocol data models.
> 
> My recommendation to IETF wrt actually trying to mandate protocols is
> "don't go there". The bandwidth spent on the protocol religious debate
> will impact time available for useful work, and the religious arguments
> will likely cause mistrust and hard feelings that will impact people's
> willingness to do the useful work. If IETF is successful in publishing
> something (because people like me will step back and let the religious
> pundits publish what they want -- knowing that it's easier to ignore the
> resulting RFC, than it is to engage in a religious war), the resulting
> RFC will be ignored by any and all who choose not to adhere to that
> religion.
> 
> With that said, a potentially useful exercise would be to identify which
> protocols would be better suited to different environments (based on
> some of the criteria I listed above). But this could be done without
> attempting to express it as a mandate. This could be presented in the
> form of useful guidance, as opposed to a religious mandate.
> Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 May 2013 17:01:10 +0200

> Who is asking for IETF to ensure protocol-level interoperability

Some people apparently are interested to be able to buy MAs that
interoperate on the wire.

> If there are service providers who are actively wanting IETF to tell
> them what protocols to use, I'd like for them to say so.

At the end of the day, the success of an IETF effort is decided in the
market place and everybody will be free to decide whether a standard
is useful to implement or deploy. Your notion of "the IETF is telling
operators what to deploy" sounds a bit detached from reality.

/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: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 30 May 2013 16:47:24 +0000

> Maybe you mean an Information Model? Please refer to RFC 3444 which
> talks 'On the Difference between Information Models and Data Models' - the
> way we use these terms in the IETF. Do you mean that the IETF should focus
> on developing the Information Models, and maybe some specific data
> models for the protocols under the IETF responsibility (SNMP, NETCONF,
> IPFIX)?

Thanks for the pointer to RFC 3444. That's a useful distinction. 
Yes, I think it would be very useful and much appreciated if IETF created an Information Model, and specific Data Models for IETF protocols where there is demand to use those protocols for control and/or reporting purposes.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 30 May 2013 16:53:40 +0000

> interoperate on the wire.

MA to MA operability is not what we are discussing. That comes from the measurement protocols, which I think are for ippm to recommend. We're discussing MA to Controller and MA to data Collector interoperability. Since the proposed scope indicates to me that a single entity has total say in selection of an MA and its affiliated systems, that entity will have total say as to the nature of its MA to Controller and MA to data Collector interfaces. My question remains as to whether any of the procurers of these systems are asking for the IETF to attempt to dictate to them what protocols must be implemented and run on those management interfaces.

> At the end of the day, the success of an IETF effort is decided in the market
> place and everybody will be free to decide whether a standard is useful to
> implement or deploy. Your notion of "the IETF is telling operators what to
> deploy" sounds a bit detached from reality.

You are right that the success of an IETF effort is decided in the market place. I believe that there is no market for control and reporting protocol mandates (from IETF or any other org). The potential procurers of these systems are not requesting that IETF produce a mandate for control and reporting protocols. Given the freedom of these procurers to select what they wish, and the lack of any such request from them, why would IETF choose to proceed with such an effort?
 
The notion of "the IETF is telling operators what to deploy" is, unfortunately, not detached from reality. I have difficulty counting the number of times I have seen individual contributors to IETF express the view that IETF should do more to force operators to bend to the collective will of IETF. I often see operators insulted and chastised for ignoring this collective will. They frequently ask "How can we force operators to do what we want?" and say things like "Maybe if we write or do x, the regulators will force the operators, or the people will rise up in revolt against the operators." I've also seen statements of "Operators are asking for x, but if we refuse to put x in a spec, then they will have no choice but to implement the spec without x."  And then these IETF contributors lambast the stupidity of the people for not rising up in revolt, and the regulators for not enforcing the IETF's will. Right now, I'm trying to get lmap to not put in its scope elements that (IMO) are almost guaranteed to result in these sorts of conversations. In this particular case, operators are the primary intended procurers of the systems in question, and operators are not asking IETF to write this mandate (and I'm actually actively asking IETF not to write such a mandate). Given my history of these sorts of discussions in IETF, I regret that I'm mistrustful of motivations for wanting to proceed with creating such a mandate. It has to me the look and feel of an exercise where non-operators want to create a mandate targeted at operators, and where the wishes of operators will be ignored and minimized. I apologize for seeing things this way, but this is how my past experiences have taught me to see things.
Barbara

---

From: Shane Amante <[email-masked]>
Date: Thu, 30 May 2013 12:51:24 -0600

Barbara,

> I'm definitely not. In my reading of posts of other potential procurers of these measurement systems, I haven't seen any potential procurer ask for this. I could be wrong. If there are service prov…

As per your request, I am speaking up to say: I am, (my affiliation is: Level 3 Communications)[1].  It is, by far, the most straightforward way to guarantee (equipment/software) vendors will build solutions that are on-the-wire interoperable between the various components that will comprise the overall LMAP architecture, so that I do not have to specify in excruciatingly specific detail what needs to get done in RFP/RFI's when I'm attempting to acquire equipment and/or work with third-party (potentially, already deployed) equipment.

Thanks,

-shane

[1] Note, I do recognize that I appear to be in the minority based on views presented by other members of the WG mailing list over the past few months.  Nonetheless, I wanted to make it clear that I still think this is an important/critical consideration for the LMAP work.  Ultimately, though, it is up to the WG co-chairs and AD's to determine "rough consensus" on this, and other points, relative to the work that a forthcoming LMAP WG will be tasked with.

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 30 May 2013 20:16:12 +0000

Hi Shane,
> >> single organization, its components (controllers, MAs, collectors)
> >> may originate from different sources (vendors of equipment and
> > I'm definitely not. In my reading of posts of other potential procurers of
> these measurement systems, I haven't seen any potential procurer ask for
> this. I could be wrong. If there are service providers who are actively wanting
> IETF to tell them what protocols to use, I'd like for them to say so.
> 
> As per your request, I am speaking up to say: I am, (my affiliation is: Level 3
> Communications)[1].  It is, by far, the most straightforward way to guarantee
> (equipment/software) vendors will build solutions that are on-the-wire
> interoperable between the various components that will comprise the
> overall LMAP architecture, so that I do not have to specify in excruciatingly
> specific detail what needs to get done in RFP/RFI's when I'm attempting to
> acquire equipment and/or work with third-party (potentially, already
> deployed) equipment.

Fair enough. But since the needs of your employer are not the same as the needs of my employer (and the embedded base of managed devices we have in the homes and hands of consumers is likely very different, as are many of the vendors we use in our networks) may I suggest a compromise approach. 

Rather than an approach of a standards track RFC that says "To implement the lmap architecture, the following protocols are mandatory", how about we take a page out of v6ops and do sort of an "architectural profile"? That is, create a BCP document that says "For a provider/network/3rd party whose characteristics are x, this document recommends the lmap architecture be instantiated as follows: MA must implement control protocol y and report protocol z, etc."

That way, a document could be created that more specifically targets the needs of your employer, without implying that it's the right solution for everyone else. You get an RFC, without argument as to whether the characteristics of your employer's network should weigh more heavily as criteria for protocol selection than the characteristics of my employer's network; and I don't feel threatened or backed into a corner, forced to argue religion. Would that work for you?
Barbara

---

From: <[email-masked]>
Date: Fri, 31 May 2013 10:12:25 +0100

Barbara, all,

I work for BT and believe we also would like protocol-level interoperability. 
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. 

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 think in practice the IETF will extend or re-use an existing IETF protocol and not a Broadband Forum protocol like TR-069.

I agree with you (Barbara) that specifying the (generic) Information Model is very useful and a key work item. If we get this right, then ISPs (or other standards bodies) that don't want to use the IETF protocol will still hopefully use the same Information Model.

<< Recommend re-wording to make this focus on the need for requirements of protocols and not on a specific set of standardized protocols:>>
Depends what you mean by 'requirements'.
Personally I think that the IETF is bad at doing requirements - they often seem to turn into large shopping lists that delay the protocol work and anyway aren't followed through (whereas other SDOs have a top-down process where the requirements formally determine the protocol). 

For me, what matters is reaching agreement on what we're trying to do (you could call this the high-level requirements or the top 2 or 3 requirements) - what are the constraints (like the single organisation assumption, and there will be a lot of MAs) - and roughly how to do it (could call this the high-level architecture). This would be recorded in the framework doc. Personally I think this would also be a good moment to reach (and record) consensus on what protocol (or protocols) will be re-used or extended.

I also think it's good practice for the later documents to record why the standard is like it is (for example in an Informational appendix). I think this would be useful for ISPs and other SDOs that want to use something other than the LMAP-defined protocol.

I think doing these two things, along with the generic Information Model, would fulfil what you want 

<< In addition, I've had people tell me privately that they think my idea of defining a standard DNS-SD Service Instance for an xml page on a router that can provide whatever info that router may want to share about WAN link utilization, its LAN link metrics, service attributes it may know, etc. would be a good idea.
I think this could be useful, but don't think I'll have effort to work on it.
A couple of comments
- At the moment the Charter is tightly focussed on the MA's interactions with the Controller and Collector. This work would be a different interface, between the home gateway (customer edge router) and other devices in the home network.
- could this be something that the homenet wg would be interested in? it's not a wg I follow, but name resolution and service discovery are mentioned in the charter. Their architecture doc is currently in last call. http://datatracker.ietf.org/wg/homenet/ 

I think your other comments are re-phrasings. I'm happy for Dan, Al and Benoit to decide about them.

Thanks
phil

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> STARK, BARBARA H
> Sent: 30 May 2013 21:16
> To: Shane Amante
> Cc: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [lmap] lmap charter - draft 2
> 
> Hi Shane,
> > > Who is asking for IETF to ensure protocol-level interoperability
> > > among
> > these components?
> > these measurement systems, I haven't seen any potential procurer ask
> > actively wanting IETF to tell them what protocols to use, I'd like
> for them to say so.
> >
> > As per your request, I am speaking up to say: I am, (my affiliation
> > is: Level 3 Communications)[1].  It is, by far, the most
> > straightforward way to guarantee
> > overall LMAP architecture, so that I do not have to specify in
> > excruciatingly specific detail what needs to get done in RFP/RFI's
> > when I'm attempting to acquire equipment and/or work with third-party
> > (potentially, already
> > deployed) equipment.
> 
> Fair enough. But since the needs of your employer are not the same as
> the needs of my employer (and the embedded base of managed devices we
> have in the homes and hands of consumers is likely very different, as
> are many of the vendors we use in our networks) may I suggest a
> compromise approach.
> 
> Rather than an approach of a standards track RFC that says "To
> implement the lmap architecture, the following protocols are
> mandatory", how about we take a page out of v6ops and do sort of an
> "architectural profile"? That is, create a BCP document that says "For
> a provider/network/3rd party whose characteristics are x, this document
> recommends the lmap architecture be instantiated as follows: MA must
> implement control protocol y and report protocol z, etc."
> 
> That way, a document could be created that more specifically targets
> the needs of your employer, without implying that it's the right
> solution for everyone else. You get an RFC, without argument as to
> whether the characteristics of your employer's network should weigh
> more heavily as criteria for protocol selection than the
> characteristics of my employer's network; and I don't feel threatened
> or backed into a corner, forced to argue religion. Would that work for
> you?
> Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 May 2013 13:06:42 +0000

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: Matt Tooley <[email-masked]>
Date: Fri, 31 May 2013 13:53:17 +0000

+1 on Barbara's comments.  The most valuable deliverable is the
information/data model.  The protocol(s) for interconnecting this should
be left to implementor as each SP will have a specific set of requirements
that correspond to the uniqueness of their networks.  And therefore the
suggestion of an "architectural profile" will get more buy-in from SPs
electing to implement the framework.

-- Matt

On 5/30/13 4:16 PM, "STARK, BARBARA H" <[email-masked]> wrote:

>>excruciatingly
>Fair enough. But since the needs of your employer are not the same as the
>needs of my employer (and the embedded base of managed devices we have in
>the homes and hands of consumers is likely very different, as are many of
>the vendors we use in our networks) may I suggest a compromise approach.
>
>Rather than an approach of a standards track RFC that says "To implement
>the lmap architecture, the following protocols are mandatory", how about
>we take a page out of v6ops and do sort of an "architectural profile"?
>That is, create a BCP document that says "For a provider/network/3rd
>party whose characteristics are x, this document recommends the lmap
>architecture be instantiated as follows: MA must implement control
>protocol y and report protocol z, etc."
>
>That way, a document could be created that more specifically targets the
>needs of your employer, without implying that it's the right solution for
>everyone else. You get an RFC, without argument as to whether the
>characteristics of your employer's network should weigh more heavily as
>criteria for protocol selection than the characteristics of my employer's
>network; and I don't feel threatened or backed into a corner, forced to
>argue religion. Would that work for you?
>Barbara

---

From: Shane Amante <[email-masked]>
Date: Fri, 31 May 2013 08:23:52 -0600

Hi Barbara,

> That way, a document could be created that more specifically targets the needs of your employer, without implying that it's the right solution for everyone else. You get an RFC, without argument as…

With all due respect, I do not wish to entertain the notion of any type of "profile", particularly when (in my understanding) you're suggesting that a profile may contain a unique protocol and/or data-model from [several] other profiles.  In my experience, IETF solutions (specifically: protocols & data-models) are most successful (i.e.: see ubiquitous deployment) when a WG creates single standard that vendors can easily & successfully implement and, of course, operators can rapidly and inexpensively deploy.

My fear is that if we start to go down the road of specifying different "profiles" (again, which encompass wholly different protocols and/or data-models), then this will most likely become a tremendous burden for the entire industry to bear.  Ultimately, we can all be more successful if we collectively agree to implement a single protocol with a single data-model, because it will have:
- much broader choices in terms of equipment/software that can be procured;
- much better economies of scale;
- operational excellence because there is only a single protocol/data-model to "debug"/enhance/etc. by everyone going forward;
- few, if any, concerns with having to evolve all "profiles" in lock-step;
- less testing (by vendors & operators) to ensure interoperability/compatibility between profiles; etc.

I acknowledge this will lead to some challenging discussions in order to, first, narrow down the potential set of protocols and data-models and, second, make a "rough consensus" call on a single, best overall protocol + data-model to move forward with.  Ultimately, though, this is why we are all at the IETF, because the goal of the IETF is to design and engineer a single, best-in-class specification that will see the broadest adoption possible.

Just my $0.02 ...

-shane

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 May 2013 15:47:12 +0000

> Ultimately, we can all be more successful if we
> collectively agree to implement a single protocol with a single data-model,

It's not going to happen. I will not be party to any such agreement. I already know that I will not be recommending a single protocol for wireless devices, DSL modem/routers, and network elements. I expect to be recommending (to my employer) that OMA-DM be used as a control protocol for wireless devices, TR-069 as a control protocol for DSL modems/routers, and whatever the network element vendor implements between their network element and their Element Management System (EMS) for network elements. Which means I'm not even willing to recommend a single protocol just for the devices and network elements that exist solely within my employer's environment.

Since some of the network element vendors use SNMP and some are wanting to migrate to netconf, I would really prefer for data models to be defined for both of these, rather than for just The Mandatory One Protocol (which may end up being neither of these). Having standard data models for both would be helpful and useful. The effort to do data models for both would probably be less than the effort required to pick one over the other (or pick something different entirely).

If you agreed that there could be a different protocol for wireless devices vs. DSL modems/routers (and leave network elements out of it), then I think it might be possible to select a single protocol for each of these. As long as it's the one that wireless providers want for wireless devices and that DSL providers want for DSL devices, and as long as it doesn't have to be an IETF protocol. Otherwise, if the providers' wishes are ignored, history suggests that those providers will completely ignore the recommendation. Collective agreement to implement cannot be assumed to result from IETF consensus to publish.
Barbara

---

From: Shane Amante <[email-masked]>
Date: Fri, 31 May 2013 12:28:36 -0600

Hi Barbara,

> If you agreed that there could be a different protocol for wireless devices vs. DSL modems/routers (and leave network elements out of it), then I think it might be possible to select a single proto…

I think there's a couple points of disconnect here.  First, and perhaps most fundamentally, the IETF only works on protocol and data-model specifications and, best current practices that document how a given protocol/standard the IETF has specified _has_ been successfully deployed in the Internet.  The IETF, as an organization, does not mandate that any operator anywhere in the world MUST deploy any specific protocol(s).  If you are aware of the IETF making any such proclamations, then I (and, perhaps, others) would certainly welcome any examples you can cite. 

Second, the IETF only has purview to change those standards that it has created, for example: SNMP, NETCONF/YANG, HTTP(S), data models used specifically by those protocols, etc.  IOW, I believe past precedent has made it quite clear that the IETF does not "tell" BBF, OMA, IEEE or any other SDO: a) the IETF has created its own modification to the other SDO's protocol/data-model; or, b) the IETF mandates that the SDO, under its own standards-process, must make modifications to the other SDO's protocols to do X, Y or Z.  (In my experience, the IETF may _request_ another SDO make changes or, much more often, provide clarifications to the IETF about the other SDO's protocols, but that's as far as things can and should go).

To summarize:
1)  The IETF does not mandate an operator deploy IETF standards or any standard, for that matter.
2)  If the IETF does proceed with forming an LMAP WG, then I believe the IETF should create or, better yet, re-use protocols that it has ownership _and_ responsibility to maintain, (cf: SNMP, NETCONF/YANG, HTTP(S), etc.).  The benefits should be clear: IETF participants have expertise with the IETF's own protocols/data-models which allows for speed and agility to modify them to suit new applications/use-cases while not breaking backwards compatibility, (unless it has a clear reason & consensus to do so). 
3)  If individuals in the IETF wish to pursue use of *other* SDO's protocols and/or data-models, particularly _modifications_ to those protocols, for one or more functions in LMAP then that activity must occur within the other SDO's for similar reasons to what I cited in #2.  Further, IMHO, the IETF should attempt to stay away from relying too heavily on interoperability with other SDO's protocols, because of the complexity that this creates when attempting to extend or enhance IETF-owned/controlled protocols.

With respect to #3, a compromise I could potentially see is what I think was first suggested by Phil.  Namely, the LMAP WG could be tasked with coming up with a protocol-neutral "information model" (refer to: <https://www.ietf.org/rfc/rfc3444.txt>) for one, or more, components in the LMAP architecture.  Such an "information model" may be the _basis_, i.e.: high-level guidance, upon which other SDO's use to modify their own protocols and/or data-models to suit the needs of that SDO's participants.  It would be ideal if we could come up with a minimal number of informational models that will comprise a small number of LMAP components/functions, (i.e.: perhaps *just* the configuration and reporting to/from the MAs), and stick that in as a milestone in the charter.

At the end of the day, from the PoV of the IETF, every network operator *will* have the freedom of choice to use, for example, a) all IETF-specified protocols/data-models; b) a mixture of IETF-specified protocols/data-models *and* other SDO's protocols/data-models; c) all other SDO's protocols/data-models; or, d) none of the above.  IMO, I have a preference for (a) for my network, but do not wish to hold other IETF participants back in any way from pursuing, outside the IETF, standardization and/or deployment using options (b) through (d) depending on their (network's) needs.

Regards,

-shane

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 May 2013 19:09:47 +0000

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).

Barbara

> From: Shane Amante [mailto:[email-masked]]
> Sent: Friday, May 31, 2013 2:29 PM
> To: STARK, BARBARA H
> >> Ultimately, we can all be more successful if we collectively agree to
> >> implement a single protocol with a single data-model,
> >
> > It's not going to happen. I will not be party to any such agreement. I already
> know that I will not be recommending a single protocol for wireless devices,
> DSL modem/routers, and network elements. I expect to be recommending
> (to my employer) that OMA-DM be used as a control protocol for wireless
> devices, TR-069 as a control protocol for DSL modems/routers, and whatever
> the network element vendor implements between their network element
> and their Element Management System (EMS) for network elements. Which
> means I'm not even willing to recommend a single protocol just for the
> devices and network elements that exist solely within my employer's
> environment.
> >
> > Since some of the network element vendors use SNMP and some are
> wanting to migrate to netconf, I would really prefer for data models to be
> defined for both of these, rather than for just The Mandatory One Protocol
> (which may end up being neither of these). Having standard data models for
> both would be helpful and useful. The effort to do data models for both
> would probably be less than the effort required to pick one over the other
> (or pick something different entirely).
> >
> > If you agreed that there could be a different protocol for wireless devices
> vs. DSL modems/routers (and leave network elements out of it), then I think
> it might be possible to select a single protocol for each of these. As long as it's
> the one that wireless providers want for wireless devices and that DSL
> providers want for DSL devices, and as long as it doesn't have to be an IETF
> protocol. Otherwise, if the providers' wishes are ignored, history suggests
> that those providers will completely ignore the recommendation. Collective
> agreement to implement cannot be assumed to result from IETF consensus
> to publish.
> > Barbara
> 
> I think there's a couple points of disconnect here.  First, and perhaps most
> fundamentally, the IETF only works on protocol and data-model
> specifications and, best current practices that document how a given
> protocol/standard the IETF has specified _has_ been successfully deployed in
> the Internet.  The IETF, as an organization, does not mandate that any
> operator anywhere in the world MUST deploy any specific protocol(s).  If you
> are aware of the IETF making any such proclamations, then I (and, perhaps,
> others) would certainly welcome any examples you can cite.
> 
> Second, the IETF only has purview to change those standards that it has
> created, for example: SNMP, NETCONF/YANG, HTTP(S), data models used
> specifically by those protocols, etc.  IOW, I believe past precedent has made
> it quite clear that the IETF does not "tell" BBF, OMA, IEEE or any other SDO: a)
> the IETF has created its own modification to the other SDO's protocol/data-
> model; or, b) the IETF mandates that the SDO, under its own standards-
> process, must make modifications to the other SDO's protocols to do X, Y or
> Z.  (In my experience, the IETF may _request_ another SDO make changes
> or, much more often, provide clarifications to the IETF about the other SDO's
> protocols, but that's as far as things can and should go).
> 
> To summarize:
> 2)  If the IETF does proceed with forming an LMAP WG, then I believe the
> IETF should create or, better yet, re-use protocols that it has ownership
> _and_ responsibility to maintain, (cf: SNMP, NETCONF/YANG, HTTP(S), etc.).
> The benefits should be clear: IETF participants have expertise with the IETF's
> own protocols/data-models which allows for speed and agility to modify
> them to suit new applications/use-cases while not breaking backwards
> compatibility, (unless it has a clear reason & consensus to do so).
> 3)  If individuals in the IETF wish to pursue use of *other* SDO's protocols
> and/or data-models, particularly _modifications_ to those protocols, for one
> or more functions in LMAP then that activity must occur within the other
> SDO's for similar reasons to what I cited in #2.  Further, IMHO, the IETF should
> attempt to stay away from relying too heavily on interoperability with other
> SDO's protocols, because of the complexity that this creates when
> attempting to extend or enhance IETF-owned/controlled protocols.
> 
> With respect to #3, a compromise I could potentially see is what I think was
> first suggested by Phil.  Namely, the LMAP WG could be tasked with coming
> up with a protocol-neutral "information model" (refer to:
> <https://www.ietf.org/rfc/rfc3444.txt>) for one, or more, components in the
> LMAP architecture.  Such an "information model" may be the _basis_, i.e.:
> high-level guidance, upon which other SDO's use to modify their own
> protocols and/or data-models to suit the needs of that SDO's participants.  It
> would be ideal if we could come up with a minimal number of informational
> models that will comprise a small number of LMAP components/functions,
> (i.e.: perhaps *just* the configuration and reporting to/from the MAs), and
> stick that in as a milestone in the charter.
> 
> At the end of the day, from the PoV of the IETF, every network operator
> *will* have the freedom of choice to use, for example, a) all IETF-specified
> protocols/data-models; b) a mixture of IETF-specified protocols/data-models
> *and* other SDO's protocols/data-models; c) all other SDO's protocols/data-
> models; or, d) none of the above.  IMO, I have a preference for (a) for my
> network, but do not wish to hold other IETF participants back in any way from
> pursuing, outside the IETF, standardization and/or deployment using options
> (b) through (d) depending on their (network's) needs.
> 
> Regards,
> 
> -shane

---

From: Shane Amante <[email-masked]>
Date: Fri, 31 May 2013 13:59:29 -0600

Hi Barbara,

>  be organized in batches or may be reported immediately, such as for an

I'm OK with the above changes.

> - NETCONF data model: Data Model consistent with the Information Model, for control and reporting using NETCONF.

I'm not OK with deleting deliverables related to protocol selection for:
- The Control Protocol and associated data model; and,
- The Report Protocol and associated data model.

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.  

I do not believe this in any way inhibits other SDO's from specifying, standardizing, recommending, etc. their own protocols for either (or, both) of the Control or Reporting functions.  At the end of the day, the market (operators) will decide whether they want a wholly IETF solution or part-IETF/part-other-SDO solution.

-shane

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 May 2013 22:05:42 +0200

Hi,

I am against these proposed changes.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 May 2013 21:08:33 +0000

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

---

From: Shane Amante <[email-masked]>
Date: Fri, 31 May 2013 15:45:37 -0600

Hi Barbara,

> 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