Subject: [lmap] Is there a requirement for combined management and control architecture?

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 24 Nov 2012 22:20:02 +0000

Thanks, James, for the email you sent. It really helped to improve my understanding of what you believe to be important to a regulatory use case, and explain why you put certain requirements into the draft.
If I read your email correctly, I believe that you support separating discussion of recommendations for measurements and metrics, from discussions on management and control of the elements participating in metric data collection and dissemination. I agree with this. I believe that the draft that you co-authored was very much focused on a management and control architecture, so I am going to focus my comments now purely on requirements of management and control architectures for measurement collection architectures of the various use cases we have been considering.

There is a key element of the draft that I disagree with, that I would like to better understand your thoughts on.

It appears to me that the draft attempts to combine the management and control requirements for all use cases (end user, access network provider, application service provider, regulatory/research) into a single management and control architecture (that therefore imposes the requirements of the most complex use case on all use cases). This appears to me to be a core assumption of the draft, and is my fundamental objection to the draft. This assumption is made without any attempt to justify it, and I saw nothing in your email that would justify it. In my opinion, just because all of the use cases are "good" or "valid", does not imply that combined management and control of them is desirable or good. Most of the statements from my prior emails were to explain why I find (mandated) combination of management and control architectures to be undesirable. To me, the requirements of the different use cases all seem to be very independent of each other. 

Why do you (or do you?) consider it important that a single management and control architecture be defined that meets the combined needs of all use cases?

If the draft authors would agree to consider the management and control architecture requirements of each use case independently, I think we might be able to progress to doing such independent requirement assessment. But if the draft authors insist that they must be combined into a single architecture, then I would like for some attempt to be made to provide a convincing reason for their combination.
Barbara

---

From: Shane Amante <[email-masked]>
Date: Mon, 26 Nov 2012 22:59:28 -0700

Barbara,

I'm not James :-), but let me step in anyway to ask a clarifying question, below.

> Why do you (or do you?) consider it important that a single management and control architecture be defined that meets the combined needs of all use cases?

Isn't one of the fundamental benefits of standards that it allows an _entire_ industry to benefit from the economies of scale by _allowing_ (not, forcing) ISPs to specify to manufacturers, in RFP's, that they build equipment (HW + SW) that follows a single specification?  Thus, isn't it better to find commonalities across several use cases and *attempt* to engineer a solution that covers all of them in a consistent fashion?

At this stage of the LMAP work, I believe that it's a good idea to combine the "management and control requirements" for all use cases.  I can certainly see validity in that approach, particularly relative to services on my own network, other small- to mid-size networks and, potentially, other use cases as well.

-shane

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 27 Nov 2012 14:17:13 +0000

> Isn't one of the fundamental benefits of standards that it allows an _entire_
> industry to benefit from the economies of scale by _allowing_ (not, forcing)
> ISPs to specify to manufacturers, in RFP's, that they build equipment (HW +
> SW) that follows a single specification?  Thus, isn't it better to find
> commonalities across several use cases and *attempt* to engineer a solution
> that covers all of them in a consistent fashion?
>
> At this stage of the LMAP work, I believe that it's a good idea to combine the
> "management and control requirements" for all use cases.  I can certainly see
> validity in that approach, particularly relative to services on my own network,
> other small- to mid-size networks and, potentially, other use cases as well.

<bhs> Commonalities, to me, implies the intersection of requirements of all use cases. Not the union. To understand what the intersection is, the set of requirements for each use case needs to be understood independently, as its own stand-alone set of requirements. Where the requirements intersect is the "commonality". The current draft is attempting to define the union. It is imposing the sum of all requirements for all use cases on all elements. 

I'm absolutely in favor of seeing if there is commonality. Commonality is impossible to determine unless the needs of each use case are first identified independent of the other use cases.

---

From: Shane Amante <[email-masked]>
Date: Tue, 27 Nov 2012 18:59:11 -0700

> I'm absolutely in favor of seeing if there is commonality. Commonality is impossible to determine unless the needs of each use case are first identified independent of the other use cases.

Sometimes it's more efficient not to reinvent the wheel over-and-over-and-over ...  :-)  Hence, I can understand why the draft authors have taken the approach of identifying requirements that _are_ common across all Use Cases defined in the draft.  This suggests, to me at least, that those requirements already in the draft that are incompatible with one, or more, Use Cases should on a case-by-case basis:
a) have technical evidence presented as to _why_ they are incompatible with a Use Case; and,
b) suggestions as to how to change the text to make it compatible with the envisioned Use Case(s).

Is this not how the editing process of a IETF draft works?

-shane