Subject: [ippm] IPPM Metric Registry Concept of Roles

From: Heitor Ganzeli <[email-masked]>
Date: Tue, 29 Jan 2019 15:37:06 -0200

**

*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-3537R.: 4077
INOC 22548*HSG
www.nic.br <http://nic.br>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 30 Jan 2019 14:20:25 +0000

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:[email-masked]] On Behalf Of Heitor Ganzeli
Sent: Tuesday, January 29, 2019 12:37 PM
To: [email-masked]
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:

“7.3.6.  Role

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=>

---

From: Heitor Ganzeli <[email-masked]>
Date: Wed, 30 Jan 2019 14:42:50 -0200

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 onemeasurement
agent that generates the packets and another agent thatreceives 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 itis 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
suppliedfor 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:
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *Heitor Ganzeli
> *Sent:* Tuesday, January 29, 2019 12:37 PM
> *To:* [email-masked]
> *Subject:* [ippm] IPPM Metric Registry Concept of Roles
>
>  
>
> Hello IPPM WG.
>
>  
>
> 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.
>
>  
>
> *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=>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 31 Jan 2019 13:51:57 +0000

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:[email-masked]]
Sent: Wednesday, January 30, 2019 11:43 AM
To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
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

there should be two entries in the Role registry column, "Source" and "Destination".

When a measurement agent is instructed to perform the

is required to generate packets.

then the Role SHALL be treated as a Run-time Parameter, and supplied

for execution. It should be noted that the LMAP framework distinguishes

-=-=-=-=-=-=-=-=-

Regards,

-=-=-=-=-=-=-=-=-

7.3.6  Role

-=-=-=-=-=-=-=-=-

From: ippm [mailto:[email-masked]] On Behalf Of Heitor Ganzeli
Sent: Tuesday, January 29, 2019 12:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [ippm] IPPM Metric Registry Concept of Roles

Hello IPPM WG.

“7.3.6.  Role

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=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=fG1ocUH95zQ-PzyYzaD--CzygSO2jA_RSUpES0wjDpo&s=MUCJBAT5t4EXSTjulqkhUKD6YwHRvVfOx0yzhS2FGfc&e=>

---

From: Heitor Ganzeli <[email-masked]>
Date: Thu, 31 Jan 2019 16:39:52 -0200

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

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

Thanks again for considering our requests,

Regards,

On 1/31/19 11:51 AM, MORTON, ALFRED C (AL) wrote:
> *From:*Heitor Ganzeli [mailto:[email-masked]]
> *Sent:* Wednesday, January 30, 2019 11:43 AM
> *To:* MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
> *Subject:* Re: [ippm] IPPM Metric Registry Concept of Roles
>
>  
>
> Hi Al,
>
> Thanks for your reply.
>
> 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
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     identified some doubts regarding the concept of roles in the
>     metric registry:
>
>      
>
>     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.
>
>      
>
>     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.
>
>      
>
>     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.
>
>      
>
>     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
> 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=>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 31 Jan 2019 19:03:25 +0000

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:[email-masked]]
Sent: Thursday, January 31, 2019 1:40 PM
To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
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=>

Regards,

-=-=-=-=-=-=-=-=-=-=-=-

thanks again,
Al

From: Heitor Ganzeli [mailto:[email-masked]]
Sent: Wednesday, January 30, 2019 11:43 AM
To: MORTON, ALFRED C (AL) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] IPPM Metric Registry Concept of Roles

Hi Al,

Thanks for your reply.

7.3.6  Role

-=-=-=-=-=-=-=-=-

Regards,

-=-=-=-=-=-=-=-=-

7.3.6  Role

-=-=-=-=-=-=-=-=-

Hello IPPM WG.

“7.3.6.  Role

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=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=QOPZTCihknPSVf5ZFftCv9_ay06SEk8rjmb3st5mkAk&e=>

---

From: Heitor Ganzeli <[email-masked]>
Date: Thu, 31 Jan 2019 18:18:32 -0200

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:
> *Sent:* Thursday, January 31, 2019 1:40 PM
> 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=>
>
> 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=>
>
>  
>
>     *To:* MORTON, ALFRED C (AL) <[email-masked]>
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     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
>         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:
>
>          
>
>         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.
>
>          
>
>         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
> <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=>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 31 Jan 2019 20:29:22 +0000

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:[email-masked]]
Sent: Thursday, January 31, 2019 3:19 PM
To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
Subject: Re: [ippm] IPPM Metric Registry Concept of Roles

Regards,

I think we should say:

Al

Hi Al,

Regards,

-=-=-=-=-=-=-=-=-=-=-=-

thanks again,
Al

Hi Al,

Thanks for your reply.

7.3.6  Role

-=-=-=-=-=-=-=-=-

Regards,

-=-=-=-=-=-=-=-=-

7.3.6  Role

-=-=-=-=-=-=-=-=-

Hello IPPM WG.

“7.3.6.  Role

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=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2hGiiEpJIC8A3jaYmWr17H1ypQeFeDJoYmo4VksLzdQ&s=j9NRs3Qg01ScMMrjZYHfzNfkNQC71N2aMey4K8O81ZU&e=>