Re: [lmap] lmap framework and IPPM registries.

["Bugenhagen, Michael K" <[e-mail]>]

Al - 

   Thanks!
  
In the BBF meeting we were discussing how to move forward with documenting the tests for some of the U.S. based tests that are currently being reported so we had some apples to apples reference tests.

   We agreed that going through the IETF IPPM / registry group was the way to go- so I wanted to make sure what that process might look like.
I thought it would require new RFC work for defining a special test without ambiguity.... as you indicate.

  So we'll point anyone wanting to standardize tests to the IPPM - Excellent.

BTW - The BBF has some WT-143 broadband tests already defined on throughput testing, I'll discuss getting those converted to RFC's with the original editors of those tests.. that seems a logical first step.

Cheers,
Mike 



-----Original Message-----
From: lmap [mailto:[e-mail]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Tuesday, April 15, 2014 9:45 AM
To: Bugenhagen, Michael K; 'MARCELO BAGNULO BRAUN'; 'Juergen Schoenwaelder'
Cc: '[e-mail]'
Subject: Re: [lmap] lmap framework and IPPM registries.

Mike,  I won't be able to expand on details with you, but see my reply below:

> -----Original Message-----
> From: Bugenhagen, Michael K 
> [mailto:[e-mail]]
> Sent: Tuesday, April 15, 2014 10:28 AM
...
> 
> Marcelo, Juergen, Al
> 
>     Just for clarity - and my making sure I'm tracking this correctly 
> - and we're all on the same page -
> 

We are not, we have yet to achieve that state in many cases, unfortunately.


> 
> The tests conducted by most of the regulators (the one's they are
> reporting) are modifications of the standard testing methods.
> i.e. - the Throughput test results use a delay window or stability window
> to negate the influence of "burst" or buffering - and report the stable
> throughput after x seconds, or y seconds of stability.

Real bad example, because IPPM does not yet have a solid metric and method RFC
for Throughput or Capacity. Work is in-progress here, of course.

> 
> Question -  Given the Registry method we've described requires a Standard
> test MIB to become a registry entry
> Assumption - Does it follow that we need to write a standalone test
> standard (RFC) for each unique test method...
> 
> I think this is true, if not please correct me.

We considered this possibility, but practicality caused us to choose the
alternative where one or more existing RFCs are references for a Registered Metric,
and the registry entry itself MUST provide all the details to specify the metric 
and methods *exactly*, without ambiguity.

So, not true about lots of new RFCs. We simply don't see this happening
to support the registry - there's barely enough review energy to get the 
the registry design memos adopted and to consensus.  This is clearly overhead
work and though essential to LMAP, not exciting == few volunteers.

Some RFCs are needed (Throughput) and many very good Registry Entries are needed.

Al


> 
> At the moment we have very few tests that use that modified method, which
> infers we have more work to do on the IPPM side with new test RFC's?
> 
> Thanks,
> Mike
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: lmap [mailto:[e-mail]] On Behalf Of MARCELO BAGNULO
> BRAUN
> Sent: Monday, April 14, 2014 1:41 PM
> To: Juergen Schoenwaelder
> Cc: [e-mail]
> Subject: Re: [lmap] lmap framework and IPPM registries.
> 
> Juergen Schoenwaelder <[e-mail]> dijo:
> 
> > On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote:
> >> Hi,
> >>
> >> One issue i realized is that the current lmap framework states the
> >> the measurement method is specified as a URN to a registry entry,
> >> while the current IPPM registry draft do not have a URN as metric
> >> identifier but a name and a metric identifier.
> >
> > So according to IPPM, which one is the "native" unique thing to refer
> > to, the name or the metric identifier (a 16-bit number if I understand
> > right)?
> 
> the identifier is the unique identifier
> 
> metrics names should be unique, but not must be
> 
> 
> >
> >> I think it is very important that these two efforts are aligned so i
> >> suggest that we discuss whether a URN is the proper way to go or the
> >> current flat identifier proposed in the ippm registry drafts.
> >>
> >> I am uncertain what is the benefit of an URN versus a flat
> >> identifier. Regards, marcelo
> >
> > It should be a URI.
> >
> > Standard metrics can have their own URN space, e.g., derived from
> > their unique "thing" (the name or the metric, I can't tell). Or IPPM
> > even makes their native "identifier" simply a URN. Making this
> > reference a URI within LMAP makes things easily extensible without
> > requiring to go through a central registry or to work with potential
> > clashes in number spaces reserved for private use. Using URIs also
> > seems rather natural in a web-based world.
> >
> 
> It is perfectrly possible to reserve a range of identifiers for private
> use so a manager of a measurement domain can locally assign values for
> metrics without going through the registry.
> 
> I still dont understand how does the IANA manages a well know set of
> metric identifiers using URN/URIs. I am not saying this is not feasible,
> just that i fail to understand it yet.
> 
> Regards, marcelo
> 
> 
> 
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> >
> 
> 
> 
> --
> ----
> MARCELO BAGNULO BRAUN
> WebCartero
> Universidad Carlos III de Madrid
> 
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap

_______________________________________________
lmap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lmap