Re: [lmap] on use cases and requirements

[Javier Bustos Jiménez <[e-mail]>]

Hello

Watching the slides for draft-linsner-lmap-use-cases two comments come to my mind:

1.- QoE is defined at ISO 9241-210: Human-centred design for interactive systems. Quality of Experience: "a person's perceptions and responses that result from the use or anticipated use of a product, system or service"

2.- About a question about how much often the probing has to be made and how many measures agents hould be distributed in order to be statistically representative, I remember that we had that problem when we built our national infrastructure and saldy the answer is "depends".  It depends in what is wanted to measure, the size and the distribution of the population.

Best regards
Javier
 
El 26-07-2013, a las 14:25, Nagami Kenichi <[e-mail]> escribió:

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Romascanu, Dan (Dan)
>>> Sent: 25 July 2013 13:40
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lmap
>> _______________________________________________
>> lmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lmap
>> 
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap