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

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 28 Nov 2012 20:47:29 +0000

> 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

If this draft were a working group draft under a chartered working group, I might agree with what you suggest.
But it isn't.
There is no working group that has this effort as part of its charter.
This is a personal draft.
There is no agreement to use this personal draft as a baseline for anything. 

What I thought we were asked to consider was:
Is there a need for something new to be done by IETF?
To figure this out, I thought we were supposed to explore what needs might exist, that were not being handled elsewhere (in other SDOs or other IETF WGs), and whether these needs were sufficiently compelling to charter an existing or new WG to deal with them.
We have identified the need of defining metrics, measurements, and points of measurement for all or some of the proposed use cases, and I think I have seen that there is a belief that this can be covered by the existing ippm wg, perhaps under its existing charter. I'm happy to leave that discussion to ippm, and don't think that this lmap list needs to try to hash out these things that ippm can deal with. 
There appears to be this other (IMO, not well defined) need around managing and controlling the taking of measurements, along with data collection, storage, and presentation, and such. 
I am trying to suggest a path that will allow for this "need" to be defined in such a way that it will (a) satisfy the expressers of a use cases's "need", (b) satisfy those who have experience in this area of device management, control and operational support systems, and operations architectures (like me, though I'm sure there are others) and might be willing to work on it if they better understood it, and (c) allow for sufficient assessment to see if there is consensus on needs that would be part of a new or modified WG charter that would pass muster.

I have seen 3 approaches proposed to proceed from where we are:
    (1) use the current "combined use case" draft as a starting point and attempt to edit it to the point that it provides sufficient assessment that would allow charter-able work efforts to be identified,
    (2) assess the needs of each use case independently (and identify commonality), to see if charter-able work can be identified (the draft can be considered input to this work, especially for the regulatory use case), or
    (3) do nothing in the area of management and control of performance measurements. 

I recommend (2). I have seen no justification presented for why approach (1) (combine the needs of all use cases; do not identify which requirement applies to which use case; do not consider the individual needs of individual use cases) is preferred by some. I've seen nothing to indicate that anyone else has an interest in (2), so I'm glad to do no work on progressing that approach. I've seen a few emails that perhaps suggest a preference for approach (1). In the absence of consensus to proceed with (1) or (2), or suggest another approach, I suspect that (3) will win. If there is a desire to proceed with approach (1), I can only say "Have at it". I want no part in it, and I'll be happy to step back and stay out of the way.
Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Wed, 28 Nov 2012 22:13:25 +0000

Personally I think working on the Charter to either modify the scope of IPPM to tackle the work or make this it's own project is very important because the statements in that charter will fix all the questions being asked here.

I'm hoping Henning and James are working on one - I was / am holding off for that so far.

Regards -
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Wednesday, November 28, 2012 2:47 PM
To: Shane Amante
Cc: [email-masked]
Subject: Re: [lmap] Is there a requirement for combined management and control architecture?

> 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:
> b) suggestions as to how to change the text to make it compatible with 
> the envisioned Use Case(s).
> 

I recommend (2). I have seen no justification presented for why approach (1) (combine the needs of all use cases; do not identify which requirement applies to which use case; do not consider the individual needs of individual use cases) is preferred by some. I've seen nothing to indicate that anyone else has an interest in (2), so I'm glad to do no work on progressing that approach. I've seen a few emails that perhaps suggest a preference for approach (1). In the absence of consensus to proceed with (1) or (2), or suggest another approach, I suspect that (3) will win. If there is a desire to proceed with approach (1), I can only say "Have at it". I want no part in it, and I'll be happy to step back and stay out of the way.
Barbara
_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: Shane Amante <[email-masked]>
Date: Wed, 28 Nov 2012 18:40:05 -0700

Barbara,

> This is a personal draft.

Fair enough.

> There is no agreement to use this personal draft as a baseline for anything. 

FWIW, others have commented, on this list, about this draft and the impression I had was that most, but not all, thought it was a relatively decent starting place for an architecture draft as to the coordinating the functions performed by a measurement controller, server, network parameter server, etc.  I'd say that's potentially rough consensus, but certainly not unanimity.  Regardless, as you say, there is no WG, yet, so no one could "officially" declare agreement, consensus, etc.

> I recommend (2). I have seen no justification presented for why approach (1) (combine the needs of all use cases; do not identify which requirement applies to which use case; do not consider the individual needs of individual use cases) is preferred by some. I've seen nothing to indicate that anyone else has an interest in (2), so I'm glad to do no work on progressing that approach.

Just to clear.  In your last sentence above, you said: "so I'm glad to do no work on progressing that approach", even though you're saying "I recommend (2)" just before that.  Did you really mean to say: "so I'm glad to do work on progressing that approach", (notice the missing "no")?  And, if so, are you offering to write a (rough) draft to share your thoughts on approach #2?  Or, am I misunderstanding your comment entirely?  :-(

> I've seen a few emails that perhaps suggest a preference for approach (1). In the absence of consensus to proceed with (1) or (2), or suggest another approach, I suspect that (3) will win. If there is a desire to proceed with approach (1), I can only say "Have at it". I want no part in it, and I'll be happy to step back and stay out of the way.

Thanks for this note.  If I understand you correctly and you are offering to take a lead on approach #2 that may provide more clarity what are the perceived or actual deficiencies in the present draft, which will only help clarify things for everyone.

-shane