Re: [lmap] on use cases and requirements

 Phil,

> http://tools.ietf.org/html/draft-nagami-lmap-use-case-measurement-provider-00
> you talk about a "measurement provider" - if I get it right, this is someone who provides information about different ISPs. this seems to me very similar to the regulator use case - but it's a public interest group, or a company providing the information instead of a regulator. It's probably worth pointing this out in http://tools.ietf.org/html/draft-linsner-lmap-use-cases - would this then cover your use case?

I think a use case for a regulator is similar to a measurement provider.

We were thinking the following case.

Multiple measurement providers can measure a performance
from MAs in the users  to MAs in the multiple content providers.

The measurement provider publishes the results that are easy to
understand for users.
It is necessary to show the measurement parameters in order to allow
comparison with the result of the other.
For example, the parameters are how to measure a performance,
measure a performance from where to where, etc.

If a use case for a regulator is same as this,
I would like to add "a public interest group, or a company providing
the information instead of a regulator" for clarity.
And it is necessary to show measurement parameters as well as the
measurement result.

Regards,
Ken Nagami

>
> You also mention a smartphone, I think it's worth adding this explicitly to draft-linsner
>
> You also have a lot of interesting details about your deployment. My feeling is that it would take a lot of work to summarise all the state-of-the-art, so we shouldn't try (perhaps we could add a few references in one of the docs)
>
>
> Rachel,
> http://tools.ietf.org/id/draft-huang-lmap-data-collection-use-case-00.txt
> I take this as a slight expansion of the ISP use case described in http://tools.ietf.org/html/draft-linsner-lmap-use-cases
> Could we work with you on adding a little text about simulations to our draft? - ie the ISP could use measurements to feed its simulation tools (assuming it uses simulations as part of the way it works out where a fault is, or where to add capacity, etc).
> Will you be in Berlin? Marc, Ken and I are meeting in the lmap breakfast to discuss use cases.
>
>
> Dan,
> Personally I'm happy to drop as much of Section 3 as people want (even all of it).
> I agree we should think carefully in terms of what the output of lmap needs to do - what are the most important aspects of which use cases.
> Reading between the lines, you think the use cases doc should only cover those aspects that we're going to (try to) make sure we solve during the initial lmap charter. And not be a general use case doc that would need future lmap capability.
> Is that right?
> (I'm ok if the answer is 'yes')
>
> Thanks
> phil
>
>> -----Original Message-----
>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
>> Romascanu, Dan (Dan)
>> Sent: 25 July 2013 13:40
>> To: lmap@ietf.org
>> Subject: [lmap] on use cases and requirements
>>
>> If you have a look at the updated agenda at
>> https://datatracker.ietf.org/meeting/87/agenda/lmap/ you will realized
>> that Jason and me slightly updated the section dedicated to use cases
>> and added ten minutes of discussion. Let me try to explain the
>> motivation and what we would try to achieve. According to the charter
>> in a couple of months the WG will need to submit the first WG Internet-
>> Drafts on Use Cases and Framework. These two documents should provide
>> clear enough requirements for the following phases where we need to
>> proceed to the creation of the Information Model, and discuss about the
>> selection or development of protocols for Control and Reporting and
>> their associated data models. At this moment in time we have one draft-
>> linsner-lmap-use-cases-03 as principal document on use cases, and two
>> new contributions, which is good for this phase. What we need to start
>> doing is to sort out of the use cases the subset that matches the
>> current WG charter - and we may need to drop  or prioritize some of the
>> aspects of the use cases for this purpose.
>>
>> (To be more specific and take this just as an example, I am not sure
>> that all the characteristics described in Sections 3.2, 3.3, 3.5 in
>> draft-linsner-lmap-use-cases-03 are LMAP problems or problems that
>> belong to the requirements of the first phase of LMAP.)
>>
>> Regards,
>>
>> Dan
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
>