Subject: [lmap] Fwd: Re: Martin Stiemerling's Block on charter-ietf-lmap-00-08: (with BLOCK)

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Jun 2013 17:22:31 +0200

FYI.
The discussion continues with the IESG.

Regards, Benoit

-------- Original Message --------
Subject: 	Re: Martin Stiemerling's Block on charter-ietf-lmap-00-08: 
(with BLOCK)
Date: 	Wed, 12 Jun 2013 17:21:28 +0200
From: 	Benoit Claise <[email-masked]>
To: 	Martin Stiemerling <[email-masked]>
CC: 	The IESG <[email-masked]>

Hi Martin,

Thanks for your feedback.
I improved the charter at 
https://datatracker.ietf.org/doc/charter-ietf-lmap/
See also in line.
> Martin Stiemerling has entered the following ballot position for
> charter-ietf-lmap-00-08: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I'm in general support of the LMAP WG, but I share Stewart's concerns
> about the length of the charter proposal and the difficulty to get to the
> point of it while reading the text.
>
> I would like to see an updated charter proposal that incorporates
> Stewart's text change proposals.
>
> Here are my comments on top of Stewart's comments:
> - The term 'mechanisms' is used a lot in the charter text and in some
> places it is ok, but in other places it worries me. For instance, right
> in the first paragraph where LMAP is introduced:
> "The Large-Scale Measurement of Broadband Performance (LMAP) working
> group
> is chartered to standardize the mechanisms for performance measurements
> of
> broadband devices such as home and enterprise edge routers, personal
> computers,
> mobile devices and other networking devices, whether wired or wireless."
>
> Another instance where 'mechanisms' is used as an arbitrary place
> holder:
> 3rd paragraph: "Many measurement systems that exist today use
> proprietary, custom-designed
> mechanisms to coordinate their Measurement Agents (MAs)"
> This is basically all about protocols and data specifications, right?
>
>
> It is better to specify what those mechanisms are, right in this place in
> order to avoid any misunderstandings on what LMAP is supposed to work.
> E.g. communication protocols between LMAP entities, information models,
> ...
Understood.
> - Also in the first paragraph:
> 'other networking devices': What is that? Anything outside of the
> broadband network?
replaced by "etc..."
> - 2nd paragraph: What is a 'characterization plan'?
removed.
> - Paragraph starting with "It is assumed that different organization's".
> I assume this paragraph tries to clearly say considerations for
> overlapping LMAP domains is out of scope, isn't it? However, the text is
> very, very soft about this, i.e., not clear enough to say it.
That's actually the reverse:

It is assumed that different organization's LMAP measurement domains can

overlap

> - "Inter-organization communication of results is not addressed in the
> LMAP system
> and is deferred to bi-lateral agreements."
> This should better read
> "Inter-organization communication of results is out of scope of LMAP."
> We  should not suggest anything about how this is handled in deployments
> IMHO.
Done.

I've also tried to group first what's in scope, then list what it's out 
of scope.
> - I would like to see a stronger statement that LMAP is developing any
> performance metrics at all:
> "LMAP will, where possible, adopt the performance metrics of the IPPM WG,
> and
> work with IPPM to develop any required new performance metrics. "
> New text suggestion:
> "LMAP will, where possible, adopt the performance metrics of the IPPM WG,
> and
> bring any required new performance metrics to the IPPM WG for
> standardization."
Fine. Hopefully IPPM will accept all new metrics under their current 
charter...
> - Paragraph "The case where an end user can independently perform network
> diagnostic
> measurements (beyond their private network) is not directly in scope,"
> What is 'not directly in scope'? It is in scope or out of scope?

The_use_case where an end user can independently perform network
diagnostic
measurements (beyond their private network) is not directly in scope,

> - There are two 'however' paragraphs:
> - starting with "Another area that is out of scope is the management"
> - starting with "Protection against the intentional or malicious
> insertion"
> This is an attempt to extend the scope of the WG beyond of what it is
> supposed to do the first place, isn't it?
Not really.
For the first one, we said "no discovery", but "if it's available, use it"
For the second one, it was initially written: preventing againg gaming 
the system is technical impossible... but if there is something very 
simple that could help, why not...
> I would like to see a clear
> statement that this has been noted but in order to focus the group it is
> better to let out of scope by now.
>
>
>
>
>
>