Subject: Re: [lmap] Information Model proposed changes for version 03

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Dec 2014 09:50:52 +0100

On Thu, Nov 20, 2014 at 05:25:21PM +0000, [email-masked] wrote:
> For anyone not at the LMAP session in Honolulu, please see the proposed changes that were suggested to the LMAP Information Model:
> http://www.ietf.org/proceedings/91/slides/slides-91-lmap-1.pptx
> 
> If I do not hear any objections I will start to implement the changes and issue version 03.
>

- Slide #5: I guess I will have to accept this. It would be nice
  though if the models (and in particular the data models) allow
  implementations to augment the base models with information about
  queues.

- Slide #6: My proposal was to consider the parameters an ordered set
  and to add parameters by prepending or appending. Overriding does
  not make much sense to me (overriding assumes every parameter can
  only appear once which is so far not required).

- Slide #7: OK

- Slide #8: OK

- Slide #9: OK

- Slide #10: I do not understand the second bullet. Why do we have to
  spell out separate pre-configuration for factory reset?

- Slide #11: I prefer to remove the JSON examples since it will be
  very irritating if LMAP protocols / data models will deviate from
  them.

/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: James Miller <[email-masked]>
Date: Tue, 2 Dec 2014 13:22:26 -0500

On slide #11 and on the inclusion of JSON examples, we employ a CSV row
export for the FCC Measuring Broadband America Program's fixed effort but
JSON is the native client export for the current smartphone application in
the mobile effort.  I agree with Juergen that programs, especially as they
evolve, may have a mix of data formats and the data model should endeavor
to be neutral with respect to a particular data format.

I've received feedback in the past that the example snippets are very
useful in our technical briefing and data descriptions.  I'd offer the
feedback as a reference point but don't have a particular preference and
agree with Juergen that you have to follow the examples and keep
documentation current lest you invite confusion.  When we started working
up the Fixed documentation I didn't include CSV example snippets (thinking
users would likely be viewing the raw CSV files) but I did include an
example in the Mobile data dictionary and received good feedback on the
inclusion.

Rainy snowy weather in DC but hoping you all are enjoying sunshine and
surfing weather!

References:

Mobile Performance Data Dictionary
https://github.com/FCC/mobile-mba-androidapp/wiki/Data-Representation

MBA Fixed Data Dictionary
http://www.fcc.gov/measuring-broadband-america/2014/validated-data-fixed-2014#dict
MBA Fixed Data Developer FAQ
http://www.fcc.gov/measuring-broadband-america/2013/developer-and-researcher-faq-measuring-broadband-america-feb-2013

--
[email-masked]

"Wovon man nicht sprechen kann, darüber muß man schweigen."
(What we cannot speak about we must pass over in silence.  )
Ludwig Josef Johann Wittgenstein

On Tue, Dec 2, 2014 at 3:50 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > For anyone not at the LMAP session in Honolulu, please see the proposed
> changes that were suggested to the LMAP Information Model:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>