Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items.

marcelo bagnulo braun <marcelo@it.uc3m.es> Mon, 01 April 2013 21:52 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6221F9125 for <ippm@ietfa.amsl.com>; Mon, 1 Apr 2013 14:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a2cwHHRsQQg for <ippm@ietfa.amsl.com>; Mon, 1 Apr 2013 14:52:40 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6C21F9122 for <ippm@ietf.org>; Mon, 1 Apr 2013 14:52:38 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9018511BD7E0 for <ippm@ietf.org>; Mon, 1 Apr 2013 23:52:38 +0200 (CEST)
X-uc3m-safe: yes
Received: from [192.168.1.101] (r186-52-184-168.dialup.adsl.anteldata.net.uy [186.52.184.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id A0B5711BD7D7 for <ippm@ietf.org>; Mon, 1 Apr 2013 23:52:37 +0200 (CEST)
Message-ID: <515A019F.7050807@it.uc3m.es>
Date: Mon, 01 Apr 2013 23:52:31 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: ippm@ietf.org
References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <CAH56bmCzqij=LDp3rvdWun24B-7n2grYbGKL9rTY1_ObPXLHvw@mail.gmail.com>
In-Reply-To: <CAH56bmCzqij=LDp3rvdWun24B-7n2grYbGKL9rTY1_ObPXLHvw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 01 Apr 2013 23:52:38 +0200 (CEST)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19762.002
X-TM-AS-Result: No--25.940-7.0-31-1
X-imss-scan-details: No--25.940-7.0-31-1
Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items.
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 21:52:42 -0000

El 01/04/13 23:30, Matt Mathis escribió:
>
>
> (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00
> Mon Year - Submit draft on metrics registry to IESG as Proposed Standard
> I wonder if this would be a better fit for LMAP?   I think the root
> problem here is certifying implementations and operational
> interoperability,

mmm, this is not how i see this.
I mean, the goal here is to define a registry for metrics that are 
specified enough so it is practical to implement them.
Basically, if we intend to have a protocol that can instruct a 
measurement agent something like "run test number 5 with input 
parameters a,b and c" then test number 5 should be specified enough so 
that it is practical to implement it.
For exmaple, leaving an arbitraty P-type, probably in general is too 
generic to leave it open. OTOH, defining that the packet is a UDP packet 
with a variable lenght of padding (where the lentgh of the padding and 
the source and address ports are input parameters) seems like a more 
feasible approach.

So, i dont think certification of implementations is how i would phrase it.
It is certainly about interoperability, but i guess this is what the 
IETF is about.

I believe this belong to IPPM because i think expertise on the metrcis 
is critical. The idea is to define entries in the registry by narrowing 
down some of the input paramters of the metrcis that IPPM has already 
defined.

It probably could be done also in lmap, but it makes more sense to me in 
ippm, as the metrics the registry will cover have been defined here.

Regards, marcelo



>   which are not areas where we have any experience.
> IPPM has been about on the wire measurements and properties, not about
> user interfaces, etc.
> I would say no for an IPPM work item, but would support it under LMAP.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> Privacy matters!  We know from recent events that people are using our
> services to speak in defiance of unjust governments.   We treat
> privacy and security as matters of life and death, because for some
> users, they are.
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>