Re: [ippm] IPPM Metric Registry Concept of Roles
Heitor Ganzeli <heitor@nic.br> Fri, 01 February 2019 11:26 UTC
Return-Path: <heitor@nic.br>
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 5AA21131239 for <ippm@ietfa.amsl.com>; Fri, 1 Feb 2019 03:26:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IcTYZNivgzW for <ippm@ietfa.amsl.com>; Fri, 1 Feb 2019 03:26:38 -0800 (PST)
Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883E713121D for <ippm@ietf.org>; Fri, 1 Feb 2019 03:26:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 2B83D18ECDD; Fri, 1 Feb 2019 09:26:34 -0200 (-02)
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBhraIGhDV4m; Fri, 1 Feb 2019 09:26:34 -0200 (-02)
Received: from [IPv6:2001:12ff:0:5::138] (unknown [IPv6:2001:12ff:0:5::138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: heitor@nic.br) by mail.nic.br (Postfix) with ESMTPSA id D7AA918ECB8; Fri, 1 Feb 2019 09:26:33 -0200 (-02)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1549020393; bh=9dDbkd03KgWZWFmThCOH0JJb/h7jMZS3lCYt4oz/sRQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aCev0VxXfmbCYB2w2gzNFbn+OkgbEKEuMOkuJ0r5R7jMspihyTtfpwZqoyqo7WRPI pRw2vJBpJnSC95Zw4j/kNdia4Fq5+eAEgWHF3euOMVXec7kn0mOAgFB8RZs7B+daze gY+QvJzaE5ejxw0UOMND0BwGmUqF+e4LCqpm1lj8=
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, "ippm@ietf.org" <ippm@ietf.org>
References: <2ee89f4a-b4c2-c9fe-2f4f-a9172891d9a8@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD2DB8@njmtexg5.research.att.com> <0f6adc59-66f6-9ea0-2cba-475e99c3ff91@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD36B4@njmtexg5.research.att.com> <b4e9c4c3-3939-53c0-903e-75ab66fa1980@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD389D@njmtexg5.research.att.com> <d2643485-8059-3407-b09d-019617608006@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD39A1@njmtexg5.research.att.com>
From: Heitor Ganzeli <heitor@nic.br>
Openpgp: preference=signencrypt
Autocrypt: addr=heitor@nic.br; prefer-encrypt=mutual; keydata= mQINBFjubQ8BEAC/3D7yUlpaJizgcNBUinaaEzS02HUgJjsPpFcOhsl9uIfutd/yN9MVdniG FZgiJ2xhptJyLXNiGZgtMEdj5J/1zzQFZPp1pF5ZlVqxjNs1NFqgC+0pVC0qdnxOY5fgfRVj obsdBTmVvqOAZ1QGhkLjjvoWcBS2x0owWwKNICKlNxIMwK2GfPMgwntaf7RFPcUr44kJFnNA xYADu3AdBHGAanpXfCrtcO5aIIPVydxKGIgHKufQczqxBfCmMHL+NwK/doqkUTsUmRysr1ok TPrEjFej6DthZOCVAHYr2t+/EhY3c8sqdBEXSg9LQQpcENVd9UeZYiy4tIEzEF2fEgJi88Yi ADC43V0wNqVgSmSeUgMNTtEVPm4oF/im63/MZWvVWX9yBFM+1648PSuoWI293hnUwRolB++Y eo1T52MvDxDAB5d2MfPHOdOBbZYXcCbBQGk7WnzGkSTf/V6Kk3DWexjewQxwpcd3ldXyQ73/ 4zBGymHzwiX6gh43Oj1xNpmMGQqdLE7nQYjGi9sPV7Qj+wU4YGkagDPbU2TJc2wn8rwKT/EE RnImjrdtTndOFXA4yBbklMKa1YRV1dUWswVvTemiVSIhknRq3pcJTcA9CwFxurTei69Spwy9 B0sfzWoXLXWawComQwlpoaDtLzicc8Wyz6kx7TRoSTgBSN3HhQARAQABtCdIZWl0b3IgZGUg U291emEgR2FuemVsaSA8aGVpdG9yQG5pYy5icj6JAj0EEwEKACcFAljubQ8CGwMFCQeGH4AF CwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQSps6diIRt07HZxAAqOgYAB+mipk7Uuk6I6EX RPuj2R8ajAPaLKuzQSRIldwgM8bAmfKU9ng5NYRqbe169HIVNnQRatHYoIZZYUxaMt64cGoh Y4LvKJqRvyAHoYrgmKVD2Qn6xH5mqoj45UNTZlcvtVYVe8hFua7L433DP43vA9e/pf6H6s6l 4xyoGLtinE4+xem6LcXL0RmCtWQllP2qhecpykhPuzOj7uxXu0gR4juZSQIz2yaWg/nuwk23 uclLhTY6vdIrCu+PCmBXOiD4qw22lsElLt2C81Tqw+ceY+rNsuJHzqdxT02DKjOErnrMfVNj RTy++b+EtqkwiAYGyPMny7zATRF08RHSwjX6efUfbP1OIzURHuEOXzLj0nDLiZmCwxSlBJbL cOBkikFCRx7ppEPmnrsCRYMpS+x+V0Kw6bmDu3ZH9XVIpvDzzKYNk0C5jjkeg0SoGWZnLqDr w+ZkBLPBcaegt/s5ImWmTFSeFVera+OvUGjllJa1rmoucAhv6YiAq7JudFA29be0hkyo9Ynf ESUfaRc7fcjFJQOl3r+Ts3f4DK6sUnOBXzgARzbl2A0gfwJUMXa8ulfyFK2fdAijSwWKhvux dF62hv8c1nsEXXXLI5rOHwMHF3BqISYkSFPx+014FC23zBoPma50Xfi6dLFNSZ9xYveF4VzW P4ff9Y8TLJofGuq5Ag0EWO5tDwEQAL5KEBkXrH1cWXwfRxo1disK7iotCCsrMEa9rqT6uYvm 4jFo+rg0Y0TdpbCdL2GcGgU2BOWrAg7VvcknrPNVfeaW8dXCAvr1x5+qRzs3XyH+RSyWvHTd rRD9dZOmXML7pJk+SHgNOVnTNsH65l4QeFFTPseoNCq7RWl92URlqcyZI44f1aTCcpxSkWCp L3f/G6byOZH82/nO/1BS4JwwwQKTYyD8Q015g86eGnMAxqt3qtlMVvU3vw+YHmJWAav7cV9i AhEXo1nsnQz4SU6UXfbh8lP0FdFJLEUCrdbFFIGI4vLvWiLDEJmYqDsiH6JmR0MY8oFCHjds w0uiP4jsDLt5554OdnVKdYft8FnPLdn8OghiIM/gNYrdTjFZXmA1dUS/odK+RwCCqE5avqMU d8G93ZdlcWPGgwZXNuthAPHNiroaQOkeuq72oX9m2213xqhKFc3R2psgSomY30zraVmm+tw8 GnIhKxBl/1Ky8tFG0y5Qfd7LY84giXoVWCbn0rPZnzgSGziqlSehlif8gi40YahfQdu31H2Q F0z3NMvFXx2tibE071t1Fg3Evnsl9O+KoKdLs9+2Sw/fP31bIi4sHjp5ChuXeeXRY7LtMRfU KGAGrLkoEcQZiprAC3Be3TOWP0892tMpsdC58uud/5TG01Pcq63KkXiVSyW9ouBHABEBAAGJ AiUEGAEKAA8FAljubQ8CGwwFCQeGH4AACgkQSps6diIRt05GoRAAptasEtPpjO2hYL8lfggT MlanCi5q1o9ifjx76hqNvoxJuhmEBVZv06GrPJ5n8angF5OoCpbDPEDl8umyDr6xVS0IJ/8q 0CDrJOadYf4wXdFuavi332zfBvqtrpmBVUPjSdoBhNzrzpbz9rF3vUgAEWIoHEeL+mYtXhks vb14qZ2VJ3l/h5oxxdeTj5WnP+w4buUrDq38zVEyNT9Hds7wpmnKa2Nr/xmCmz+04im/6y/A BJ2q5VD7pQmayfIkgm5JigCwE94wuruC/bBKeHX3GlhgWGUmp76vllP71oodw3FJ2csnydSq ITk9yC14s0Ylp8wpOP1nWqxPPpLD7PX5JCoSgjyk4JvhHj6Qqb3f0ZjxKC1/mNoV+RUWQ3AM 6IINQ6t/JZ8FmsQKcckwZ+VLL68ynQJSC3bq713j5r4zZxCzFK2ljUYCPEM4hkitdBQfTqS6 KQg5bXAASZ07GwTDPVjoR8U9Rf++lkCR4Gcdc9RXXS6bIGKSgiL0JyWvRF8axDxlB/AOI28f yml0IH5r7WNMGaALbfVIckclmxfdwn6/RHW6e25WohiIVTBcWIRGmRBYWqkLpcQK/v/nWF9i Hdu3mLmipVu5uzDuKZrLUDExvquK/6T+Ra8wLVGSE5rmBYOrkSD0WCRXO+oYc4bSrgmAhb7G +TCfjtB1F8rNW6U=
Message-ID: <502a2af0-459d-fec9-1ac2-22cabe4c91e7@nic.br>
Date: Fri, 01 Feb 2019 09:26:33 -0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF6BFD39A1@njmtexg5.research.att.com>
Content-Type: multipart/alternative; boundary="------------9A9749FDB011F5E4ED5F2BD2"
Content-Language: en-US
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br D7AA918ECB8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/70_X7CptFqDROHZf41pkt6-t9gM>
Subject: Re: [ippm] IPPM Metric Registry Concept of Roles
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 01 Feb 2019 11:26:45 -0000
Thanks! I'm sure the team will be thrilled to share our findings once we get more concrete results from the system. Regards, On 1/31/19 6:29 PM, MORTON, ALFRED C (AL) wrote: > > Great! I think I speak for all of us who have worked > > on the Performance Metrics Registry and/or LMAP when I > > say that IPPM would like to hear about your measurement > > system development at NIC.br (when you’re ready), on > > the list and possibly at a meeting. > > > > thanks again for your review! > > Al > > > > *From:*Heitor Ganzeli [mailto:heitor@nic.br] > *Sent:* Thursday, January 31, 2019 3:19 PM > *To:* MORTON, ALFRED C (AL) <acm@research.att.com>; ippm@ietf.org > *Subject:* Re: [ippm] IPPM Metric Registry Concept of Roles > > > > Ok, thanks a lot! I think that closes all our doubts regarding the matter. > > > > Regards, > > On 1/31/19 5:03 PM, MORTON, ALFRED C (AL) wrote: > > Great, thanks for the reference to the LMAP YANG model. > > > > I think we should say: > > > > It should be noted that the LMAP framework [RFC7594] > > distinguishes the Role from other Run-time Parameters by defining a > > special parameter "Roles" inside the Registry-grouping Function list > > in the LMAP YANG Model [RFC8194]. > > > > Al > > > > *From:*Heitor Ganzeli [mailto:heitor@nic.br] > *Sent:* Thursday, January 31, 2019 1:40 PM > *To:* MORTON, ALFRED C (AL) <acm@research.att.com> > <mailto:acm@research.att.com>; ippm@ietf.org <mailto:ippm@ietf.org> > *Subject:* Re: [ippm] IPPM Metric Registry Concept of Roles > > > > Hi Al, > > > > The term "Function" is actually from rfc8194 - YANG Data Model for > LMAP section 4.1 page 17. > https://tools.ietf.org/html/rfc8194#page-17 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8194-23page-2D17&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=y8rhttmoB7Dsk9KdYI-OwaDSRJPIO12eNpXC29Lpi8Y&e=> > > We didn't know how to concisely reference the object and put only > "Function list". > > > > However, RFC7594 uses the term "Measurement Method role" which is > first mentioned in section 3. > https://tools.ietf.org/html/rfc7594#section-3 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7594-23section-2D3&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=UoSTqfBW5u5tD9fGN05CbjNoOXiMz6N7c4MTMCBfrWs&e=> > > > > Thanks again for considering our requests, > > Regards, > > > > On 1/31/19 11:51 AM, MORTON, ALFRED C (AL) wrote: > > Hi Heitor, > > > > I agree that we can add text referencing the LMAP > > Framework RFC 7594, since we introduced that reference > > already in the early sections. > > > > So the last paragraph would read: > > > > When the Role column of a registry entry defines more than one > Role, > > then the Role SHALL be treated as a Run-time Parameter and > supplied > > for execution. It should be noted that the LMAP framework > [RFC7594] > > distinguishes the Role from other Run-time Parameters by > defining a > > special parameter "Roles" inside the Function list. > > > > -=-=-=-=-=-=-=-=-=-=-=- > > I found that the term “role” is used consistently with the > > definition in the Registry draft throughout, so no need to > > provide a Section number in the reference to RFC 7594. > > > > However, the term “Function List” that you proposed to end the > > new sentence does not appear in RFC 7594. > > > > Can you supply the term that RFC 7594 uses, and a section > reference, please? > > > > thanks again, > > Al > > > > > > *From:*Heitor Ganzeli [mailto:heitor@nic.br] > *Sent:* Wednesday, January 30, 2019 11:43 AM > *To:* MORTON, ALFRED C (AL) <acm@research.att.com> > <mailto:acm@research.att.com>; ippm@ietf.org > <mailto:ippm@ietf.org> > *Subject:* Re: [ippm] IPPM Metric Registry Concept of Roles > > > > Hi Al, > > Thanks for your reply. > > Discussing the new text internally, we think it still gives > margin for multiple interpretations mainly because Roles > should be informed inside the "Function" list on the LMAP > framework, instead of "parameters" like other run-time > parameters. We don't know if framework specificities can be > mentioned here, but we'd like to suggest the following > modifications: > > -=-=-=-=-=-=-=-=- > > > > 7.3.6 Role > > In some methods of measurement, there may be several roles > defined, > > e.g., for a one-way packet delay active measurement there is one > > measurement agent that generates the packets and another agent > that > > receives the packets. This column contains the name of the role(s) > > for this particular entry. In the one-way delay example above, > > there should be two entries in the Role registry column, > "Source" and "Destination". > > > > When a measurement agent is instructed to perform the > > "Source" Role for one-way delay metric, the agent knows that it > > is required to generate packets. > > > > When the Role column of a registry entry defines more than one > Role, > > then the Role SHALL be treated as a Run-time Parameter, and > supplied > > for execution. It should be noted that the LMAP framework > distinguishes > > > > Role from other Run-time Parameters by defining a special > parameter "Roles" > > > > inside the Function list. > > > > -=-=-=-=-=-=-=-=- > > > > Regards, > > > > On 1/30/19 12:20 PM, MORTON, ALFRED C (AL) wrote: > > Hi Heitor, > > > > Thanks for your e-mail and your careful read of the > > Registry draft. It’s good to hear that you are > > developing an LMAP-based system. > > > > I think you’ve discovered a case where we failed to > > keep the Role description and the current thinking > > in-sync. I certainly never meant for 2 roles to > > result in two separate registry entries, but that’s > > what the description says in -17. > > > > When reading this paragraph, I saw many places where > > I think we can clarify the text. I propose the following > > revised section which follows our shared understanding. > > > > thanks again, and regards, > > Al > > > > -=-=-=-=-=-=-=-=- > > > > 7.3.6 Role > > > > In some methods of measurement, there may be several roles > defined, > > e.g., for a one-way packet delay active measurement there > is one > > measurement agent that generates the packets and another > agent that > > receives the packets. This column contains the name of the > role(s) > > for this particular entry. In the one-way delay example > above, > > there should be two entries in the Role registry column, > one for > > each Role. When a measurement agent is instructed to > perform the > > "Source" Role for one-way delay metric, the agent knows > that it > > is required to generate packets. The values for this field > are > > defined in the reference method of measurement (and this > frequently > > results in abbreviated role names such as "Src"). > > > > When the Role column of a registry entry defines more than > one Role, > > then the Role SHALL be treated as a Run-time Parameter and > supplied > > for execution. > > > > -=-=-=-=-=-=-=-=- > > > > *From:*ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of > *Heitor Ganzeli > *Sent:* Tuesday, January 29, 2019 12:37 PM > *To:* ippm@ietf.org <mailto:ippm@ietf.org> > *Subject:* [ippm] IPPM Metric Registry Concept of Roles > > > > Hello IPPM WG. > > > > At NIC.br we are developing a measurement system based on > the LMAP framework. Metrics (mainly private ones) are > defined following the proposed IPPM metric registry > standard. During this effort we identified some doubts > regarding the concept of roles in the metric registry: > > > > draft-ietf-ippm-metric-registry-17 states at 7.3.6 > > > > “7.3.6. Role > > > > In some method of measurements, there may be several > roles defined > > e.g. on a one-way packet delay active measurement, there > is one > > measurement agent that generates the packets and the > other one that > > receives the packets. This column contains the name of > the role for > > this particular entry. In the previous example, there > should be two > > entries in the registry, one for each role, so that when a > > measurement agent is instructed to perform the one way > delay source > > metric know that it is supposed to generate packets. > The values for > > this field are defined in the reference method of > measurement.” > > > > Regarding a) an interest to avoid proliferation of metrics > and b) efficient use of the LMAP Framework (announcement > of capabilities, scheduling of tasks and reporting of > results), shouldn't it be enough and preferred to keep a > single metric definition that can be referenced with one > of multiple possible roles? For example, an LMAP > measurement agent could announce the capability to execute > a task producing the OWPD metric, acting either as a > client or a server. When scheduling a task the LMAP > controller would reference that OWPD metric and pin the > role to a specific value (ex: client). And when reporting > measurement results that same role would be reported > together with the metric URN. > > > > It seems the above use cases are solved with a single > metric that allows multiple roles. Regarding the metric > registry, this perspective interprets the "role" column as > a enumeration of all roles applicable to this metric, > instead of indicating a single mandatory role. > > > > Reinforcing this point of view, the > draft-ietf-ippm-initial-registry-09 seem to list all > possible roles when describing metrics. Items 4.3.6, > 6.3.6, 7.3.6, 8.3.6, 9.3.6. But we do not have any > concrete reference on how the final LMAP report would be > when reporting data for these metrics. > > > > Could you please comment on the real motivation behind the > current draft's choice of creating multiple similar > metrics with a single role each? and if this part of the > draft is open for discussions and improvements? > > > > Thanks in advance, > > > > -- > NIC.br | Heitor Ganzeli > Analista de Projetos/Projects Analyst > Centro de Estudos e Pesquisas em Tecnologias de Redes e > Operações (Ceptro.br) > +55 11 5509-3537 R.: 4077 > INOC 22548*HSG > *www.nic.br* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-SdzhkV5T1JPu4CVfVSzHFx2EMN32n-y7kdUY0INPbs&s=tMrmlKjleks6aqNR_e2hHWBgD41F6PtgBcIUUyRXUFM&e=> > > > > > -- > NIC.br | Heitor Ganzeli > Analista de Projetos/Projects Analyst > Centro de Estudos e Pesquisas em Tecnologias de Redes e > Operações (Ceptro.br) > +55 11 5509-3537 R.: 4077 > INOC 22548*HSG > www.nic.br > <https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=fG1ocUH95zQ-PzyYzaD--CzygSO2jA_RSUpES0wjDpo&s=MUCJBAT5t4EXSTjulqkhUKD6YwHRvVfOx0yzhS2FGfc&e=> > > > > -- > NIC.br | Heitor Ganzeli > Analista de Projetos/Projects Analyst > Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações > (Ceptro.br) > +55 11 5509-3537 R.: 4077 > INOC 22548*HSG > www.nic.br > <https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=QOPZTCihknPSVf5ZFftCv9_ay06SEk8rjmb3st5mkAk&e=> > > > -- > NIC.br | Heitor Ganzeli > Analista de Projetos/Projects Analyst > Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações > (Ceptro.br) > +55 11 5509-3537 R.: 4077 > INOC 22548*HSG > www.nic.br > <https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2hGiiEpJIC8A3jaYmWr17H1ypQeFeDJoYmo4VksLzdQ&s=j9NRs3Qg01ScMMrjZYHfzNfkNQC71N2aMey4K8O81ZU&e=> > -- NIC.br | Heitor Ganzeli Analista de Projetos/Projects Analyst Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537R.: 4077 INOC 22548*HSG www.nic.br <http://nic.br>
- [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli