[OPSAWG] Ops AD office hours

[Joe Clarke (jclarke)]

Rob Wilton (our newest AD) asked that we pass this on concerning Ops AD office 
hours for IETF 108:

Warren and I appreciate that the current COVID situation is tricky for 
everyone.  Added to that, I am also a new AD and many of you may not know me.

Normally at the IETF meetings you have the opportunity to find us during the 
week if you have anything informal to discuss, but in the current climate that 
isn't so easy.

Hence, if you have something that you would like to discuss with Warren and I, 
then we will happily schedule OPS ADs Hours, possibly during the scheduled IETF 
108 week, or at another time if that isn't practical.

We will only schedule based on any requests that we receive by the end of next 
week (Friday 17th July, 23:59 UTC).

Please reply directly back to Warren and I, copying ops-ads, if you have 
something that you wish to discuss with us at this time.

Regards,
Rob (and Warren)

===

Joe


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

[Joe Clarke (jclarke)]

Thanks, Rob.  Maybe it’s just me, but your email is truncated as you can see 
below.  I also didn’t see any attachment.

Joe

> On Jul 10, 2020, at 12:52, Rob Wilton (rwilton)  wrote:
> 
> Apologies for the delay, but please find my AD review of the TACACS+ YANG 
> module draft.
> 
> I would like to thank the authors for their work on this document, and the WG 
> for providing reviews and input in this document.
> 
> I believe that the document is in good shape but propose some minor changes 
> to some of the wording in places.
> 
> One particular question that I would like to pull to the top is the naming of 
> the module and identifiers:
> These generally use "tacacsplus", but I think that "tacacs-plus" might be 
> better and more readable.
> 
> 
> Full comments are inline in the document below (marked as #)
> 
> 
>   The YANG model can be used with network management protocols such as
>   NETCONF[RFC6241] to install, manipulate, and delete the configuration
>   of network devices.
> 
>Abstract
> 
>   This document defines a YANG module that augment the System  
>   Management data model defined in the RFC 7317 with TACACS+ client
>   model.  The data model of Terminal Access Controller Access Control
>   System Plus (TACACS+) client allows the configuration of TACACS+
>   servers for centralized Authentication, Authorization and Accounting

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

[Rob Wilton (rwilton)]

Apologies for the delay, but please find my AD review of the TACACS+ YANG 
module draft.

I would like to thank the authors for their work on this document, and the WG 
for providing reviews and input in this document.

I believe that the document is in good shape but propose some minor changes to 
some of the wording in places.

One particular question that I would like to pull to the top is the naming of 
the module and identifiers:
These generally use "tacacsplus", but I think that "tacacs-plus" might be 
better and more readable.


Full comments are inline in the document below (marked as #)


   The YANG model can be used with network management protocols such as
   NETCONF[RFC6241] to install, manipulate, and delete the configuration
   of network devices.
   
Abstract

   This document defines a YANG module that augment the System  
   Management data model defined in the RFC 7317 with TACACS+ client
   model.  The data model of Terminal Access Controller Access Control
   System Plus (TACACS+) client allows the configuration of TACACS+
   servers for centralized Authentication, Authorization and Accounting.

#
Perhaps tweak the first paragraph of the abstract slightly to:

This document defines a TACACS+ client YANG module, that augments the
System Management data model, defined in RFC 7317, to allow devices to
make use of TACACS+ servers for centralized Authentication,
Authorization and Accounting.


   This document defines a YANG module that augment the System
   Management data model defined in the [RFC7317] with TACACS+ client
   model.
# augment -> augments
# with TACACS+ client -> to support the configuration and management of TACACS+ 
clients.

   TACACS+ provides Device Administration for routers, network access
   servers and other networked computing devices via one or more
   centralized servers which is defined in the TACACS+ Protocol.
   [I-D.ietf-opsawg-tacacs]
# TACACS+ provides -> "TACACS+ [I-D.ietf-opsawg-tacacs] provides" [and remove 
the reference at the end of the paragraph].
# networked computing devices -> networked devices
# centralized servers which ... -> delete from which ... to the end of the 
sentence.

   The System Management Model [RFC7317] defines two YANG features to
   support local or RADIUS authentication:
#two YANG features -> separate functionality
#or -> and

   o  User Authentication Model: Defines a list of usernames and
  passwords and control the order in which local or RADIUS
  authentication is used.
# I suggest modifying this to ->
o  User Authentication Model: Defines a list of usernames with associated
   passwords and a configuration leaf to decide the order in which local or 
RADIUS
   authentication is used.

   o  RADIUS Client Model: Defines a list of RADIUS servers that a
  device uses.
# device uses. -> devices uses to manage users.

   Since TACACS+ is also used for device management and the feature is
   not contained in the System Management model, this document defines a
   YANG data model that allows users to configure TACACS+ client
   functions on a device for centralized Authentication, Authorization
   and Accounting provided by TACACS+ servers.
# I suggest rewording this paragraph to something like:
The System Management Model is augmented with the TACACS+ YANG module defined 
in this document to allow the use of TACACS+ servers as an alternative to 
RADIUS servers or local user configuration.


Zheng, et al.   Expires December 22, 2020   [Page 2]
Internet-Draft TACACS+ YANG model  June 2020

   The YANG model can be used with network management protocols such as
   NETCONF[RFC6241] to install, manipulate, and delete the configuration
   of network devices.
# I would suggest deleting "to install ..." to the end.

   The ietf-system-tacacsplus module is intended to augment the
   "/sys:system" path defined in the ietf-system module with the
   contents of the"tacacsplus" grouping.  Therefore, a device can use
   local, Remote Authentication Dial In User Service (RADIUS), or
   Terminal Access Controller Access Control System Plus (TACACS+) to
   validate users who attempt to access the router by several
   mechanisms, e.g. a command line interface or a web-based user
   interface.
#intended to augment -> augments
#I think that you should just use RADIUS and TACACS+ here rather then spelling 
our the full names.

   The "server" list is directly under the "tacacsplus" container, which
   holds a list of TACACS+ servers and uses server-type to distinguish
   between the three protocols.  The list of servers is for redundancy.
# I was confused by "the three protocols" (thought you meant RADIUS, TACACS+ 
and local), hence suggest explicitly listing the AAA elements here.

   Most of the parameters in the 

Re: [OPSAWG] Timeline to decide to go with the common module in L3NM/L2NM, upload and present current version?

[Oscar González de Dios]

Hi Tom, Tianran,

Thanks for all the suggestions!

We are preparing now the draft so the common module proposal 
can be properly reviewed.

Best Regards,

   Oscar

De: Tianran Zhou 
Enviado el: viernes, 10 de julio de 2020 14:21
Para: tom petch ; Oscar González de Dios 
; opsawg 
Asunto: RE: [OPSAWG] Timeline to decide to go with the common module in 
L3NM/L2NM, upload and present current version?


Hi Tom,



Yeap. That's what we've suggested the authors.



Thanks,

Tianran

--
Sent from WeLink
发件人：tom petch mailto:ie...@btconnect.com>>
收件人：Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;opsawg
 mailto:opsawg@ietf.org>>
时 间：2020-07-10 18:28:27
主 题：Re: [OPSAWG] Timeline to decide to go with the common module in L3NM/L2NM, 
upload and present current version?

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>
Sent: 09 July 2020 12:34

Hi Joe, Tianran,

During las weeks we’ve been working in the common module proposal. There have 
been many interactions with cross-reviews of each proposal (more than 50 pull 
requests in the last weeks) It has been already shared with the list. We have 
also ready a new version of the draft including the proposed change.

This version using the common module also solves several issues raised in the 
Yang doctor review and reviews in the mailing list.

As the deadline to submit the new drafts is approaching (13th July), we would 
like to agree with you on how to proceed. Do we upload the draft with the 
common module proposal, ask formally for review, present it in next IETF 
meeting and send it to Yang doctor, as his comments were addressed?


For myself, I prefer plain text I-D and see that as part of the IETF's 
successes, making information available in a standard, but simple, format.  So 
another alternative is to publish an individual I-D which can be adopted by the 
WG, copied into an all-embracing I-D, binned, .

Tom Petch

If you have some time, we can have a short call on how to 
proceed,

Best Regards,


   Oscar





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the 

Re: [OPSAWG] RADIUS Extension, Getting Started

[Alan DeKok]

On Jul 10, 2020, at 8:08 AM, Massameno, Dan  wrote:
> Thank you for your thorough review.  I am completely new to the IETF process 
> (I don't even know what a "nit" is) and I'm looking forward to the process.

  "nitpick".  i.e. minor point which should be fix, but isn't very important.

  The IETF process is long, but generally worth it.

> I did want to dive into one of the last comments you made.  
> 
>Even if the various nits and and issues above were fixed, this 
> proposal would have serious security issues.  Even 
>if those security issues were addressed, I believe that load balancing 
> is simply not appropriate for 
>the NAS.  Even if it was appropriate for the NAS, the vendors have 
> spoken: NAS implementations 
>are simple, and server implementations are complex.
>As such, load balancing more properly belongs in the server.
> 
> If I have N number of RADIUS servers, how are the servers supposed to load 
> balance if the load balancing function "belongs in the server"?

  You run a load-balancer.  This is either a hardware device which does UDP 
load balancing, or a dedicated RADIUS server which does nothing more than load 
balancing.

>  Won't the NAS need to know about all the RADIUS servers?  If yes, how does 
> it decided on which one to user for any one particular session?

  The NAS knows about one server: the load balancing one.  Typically the load 
balancer can be set up in an HA pair, using VRRP to share an IP address.

  My experience is that this scenario is robust, stable, and gives the admin a 
great amount of control over the system.  My experience also has been that you 
just can't rely on the NAS to do anything sane with RADIUS.  The 
implementations are terrible, naive, simplistic, etc.  Just give up on fixing 
them, and patch over the problem with a RADIUS server that's under your control.

  It's easier for me to say, of course, having written a RADIUS server.  That 
does bias me a bit, I think.  But practical experience validates this approach.

  A different explanation for the NAS behaviour is that the NAS vendors are 
incentivized to make the core functionality work well.  e.g. switching, WiFi, 
etc.  Features such as RADIUS are an after-thought.  Issues with RADIUS are 
only fixed if a sufficient number of customers demand changes.

  In contrast, a RADIUS server vendor is strongly incentivized to implement 
RADIUS correctly.  And, to do load balancing correctly.  With many parameters 
that can be tweaked for your exact situation.

  So independent of anything else, NAS vendors simply aren't motivated to 
implement complex RADIUS load balancing.  Whereas RADIUS server vendors have 
been shipping it for decades.

> My experience with Cisco devices indicates that if multiple RADIUS servers 
> are listed it simply uses the first one exclusively until it fails.  So, 
> there is failover, but no load balancing.  The list of RADIUS servers are 
> also statically configured via CLI, which is cumbersome when there is a large 
> fleet of devices to configure.  These two overly sophomoric features were the 
> ones I was endeavoring to fix.

  Most RADIUS clients behave the same way.  My recommendation for a long time 
has been to just punt on the problem of fixing the NAS.  Instead, run a RADIUS 
server that you control.

  One benefit is that you can upgrade the NAS, or change vendors without 
changing the way that load balancing works.

  And to re-iterate... RFC 5080 Section 2.1 defines retransmission behaviour 
for RADIUS clients.  Implementing this would make customers lives easier.  It 
would make RADIUS systems better and more stable.  But the incremental benefit 
is simply not high enough for NAS vendors to implement it.  So instead, they 
use fixed-count and fixed-time retransmission behaviours which were first 
implemented in 1993.

  In order for your proposal to gain traction, the NAS vendors MUST have strong 
incentive to implement it.  And I'm not sure what that incentive is.  Right 
now, they can just say "buy a load balancer", or "download FreeRADIUS and run 
it in a VM".  Problem solved.

  Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Timeline to decide to go with the common module in L3NM/L2NM, upload and present current version?

[Tianran Zhou]

Hi Tom,


Yeap. That's what we've suggested the authors.


Thanks,

Tianran

--
Sent from WeLink

发件人：tom petch 
收件人：Oscar González de Dios ;opsawg 

时 间：2020-07-10 18:28:27
主 题：Re: [OPSAWG] Timeline to decide to go with the common module in L3NM/L2NM, 
upload and present current version?

From: OPSAWG  on behalf of Oscar González de Dios 

Sent: 09 July 2020 12:34

Hi Joe, Tianran,

During las weeks we’ve been working in the common module proposal. There have 
been many interactions with cross-reviews of each proposal (more than 50 pull 
requests in the last weeks) It has been already shared with the list. We have 
also ready a new version of the draft including the proposed change.

This version using the common module also solves several issues raised in the 
Yang doctor review and reviews in the mailing list.

As the deadline to submit the new drafts is approaching (13th July), we would 
like to agree with you on how to proceed. Do we upload the draft with the 
common module proposal, ask formally for review, present it in next IETF 
meeting and send it to Yang doctor, as his comments were addressed?


For myself, I prefer plain text I-D and see that as part of the IETF's 
successes, making information available in a standard, but simple, format.  So 
another alternative is to publish an individual I-D which can be adopted by the 
WG, copied into an all-embracing I-D, binned, .

Tom Petch

If you have some time, we can have a short call on how to 
proceed,

Best Regards,


   Oscar





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RADIUS Extension, Getting Started

[Massameno, Dan]

Alan,
Thank you for your thorough review.  I am completely new to the IETF process (I 
don't even know what a "nit" is) and I'm looking forward to the process.

I did want to dive into one of the last comments you made.  

Even if the various nits and and issues above were fixed, this proposal 
would have serious security issues.  Even 
if those security issues were addressed, I believe that load balancing 
is simply not appropriate for 
the NAS.  Even if it was appropriate for the NAS, the vendors have 
spoken: NAS implementations 
are simple, and server implementations are complex.
As such, load balancing more properly belongs in the server.

If I have N number of RADIUS servers, how are the servers supposed to load 
balance if the load balancing function "belongs in the server"?  Won't the NAS 
need to know about all the RADIUS servers?  If yes, how does it decided on 
which one to user for any one particular session?

My experience with Cisco devices indicates that if multiple RADIUS servers are 
listed it simply uses the first one exclusively until it fails.  So, there is 
failover, but no load balancing.  The list of RADIUS servers are also 
statically configured via CLI, which is cumbersome when there is a large fleet 
of devices to configure.  These two overly sophomoric features were the ones I 
was endeavoring to fix.

--Dan 

-Original Message-
From: Alan DeKok  
Sent: Monday, July 6, 2020 16:16
To: Massameno, Dan 
Cc: opsawg@ietf.org; rad...@ietf.org; OpsAWG-Chairs ; 
Benjamin Kaduk ; radext-cha...@ietf.org
Subject: Re: [OPSAWG] RADIUS Extension, Getting Started

On Jul 6, 2020, at 11:40 AM, Massameno, Dan  wrote:
> 
> Dear Ops and Management Area WG,
> 
> There have been a number of great suggestions on where to post this document 
> (Thanks Stefan!).   I'm now emailing opsawg@ietf.org and cc'ing 
> rad...@ietf.org.  
> 
> The draft is posted here... 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00data=02%7C01%7Cdan.massameno%40yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637296633820432892sdata=diYmvpvWJyIfYY%2FCerbLRHgniQbbkgp%2BWxoLm9h9k5c%3Dreserved=0
> 
> Do I need an official IETF sponsor?  Would it help to try and get a vendor 
> interested in implementing the protocol?  Cisco is our primary vendor at Yale 
> University.  I was wondering if there is anyone on either of these working 
> groups that communicates with Cisco people on a regular basis?

  There are lots of Cisco people.  I'm sure some of those people have opinions.

  There are a few things ongoing here.  The RADEXT WG is still alive, but 
inactive.  There is a still an open discussion in the WG about previous 
documents which addressed shortcomings in the base RADIUS protocol.  The polite 
version is that the long-term RADEXT participants supported one draft.  Many 
people who had never been involved with RADEXT supported a competing draft.  
There was never any resolution.  The RADEXT WG was left in limbo.

  I'll avoid the subject of the best place for this draft.

  Overall, I would oppose this draft.  For the simple reason that brains belong 
in the RADIUS server, not in the NAS.  NAS vendors haven't even implemented the 
retransmission behaviours suggested in RFC 5080 Section 2.1, which is well over 
a decade old at this point.  If they can't do that, how can they implement an 
even more complex load-balancing system?

  Further, there is no standard in RADIUS for load-balancing with fail-over and 
fail-back.  Every NAS vendor and RADIUS vendor does something different.  While 
this document tries to address that issue, it does not address a number of key 
points.


  I do have a review, as follows.  Many of these issues given below are nits, 
and can be fixed by rewording the document, or moving to an approach which 
follows existing standards (RFC 6158, RFC 6929, RFC 8044).  However, for 
reasons given above, I don't think it's useful to move ahead with this document.


* Section 2 - Message Summary

   I recommend deleting this part.  The RADIUS packet format is well known.  
There's no need to repeat the definition here.  Just refer to RFC 5997.

* Section 2.2 - nitpick: 191 is not defined, so it's likely best to leave this 
attribute value as TBD, even if IANA is likely to choose 191.

  Further, RADIUS definitions use consistent names for attributes.  The names 
do not change when they're used in different packet types.  The attribute 
should just be called something like "Load-Balance-Status"

* Section 2.3.2 - the text here is simply wrong.  The Request-Authenticator is 
not "hashed with the identity material from the calling-station
   and the RADIUS shared secret."

   RFC 5997 Section 5 already mandates the use of Message-Authenticator with 
Status-Server.

  I suggest deleting 2.3.2 entirely.

* Section 3 - the definition of the LB-Request does 

Re: [OPSAWG] Timeline to decide to go with the common module in L3NM/L2NM, upload and present current version?

[tom petch]

From: OPSAWG  on behalf of Oscar González de Dios 

Sent: 09 July 2020 12:34

Hi Joe, Tianran,

During las weeks we’ve been working in the common module proposal. There have 
been many interactions with cross-reviews of each proposal (more than 50 pull 
requests in the last weeks) It has been already shared with the list. We have 
also ready a new version of the draft including the proposed change.

This version using the common module also solves several issues raised in the 
Yang doctor review and reviews in the mailing list.

As the deadline to submit the new drafts is approaching (13th July), we would 
like to agree with you on how to proceed. Do we upload the draft with the 
common module proposal, ask formally for review, present it in next IETF 
meeting and send it to Yang doctor, as his comments were addressed?


For myself, I prefer plain text I-D and see that as part of the IETF's 
successes, making information available in a standard, but simple, format.  So 
another alternative is to publish an individual I-D which can be adopted by the 
WG, copied into an all-embracing I-D, binned, .

Tom Petch

If you have some time, we can have a short call on how to 
proceed,

Best Regards,


   Oscar





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg