Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue

<mohamed.boucadair@orange.com> Fri, 26 April 2019 13:08 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B151203A5 for <dots@ietfa.amsl.com>; Fri, 26 Apr 2019 06:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 pesq9Ii3RWzl for <dots@ietfa.amsl.com>; Fri, 26 Apr 2019 06:07:58 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3271201DA for <dots@ietf.org>; Fri, 26 Apr 2019 06:07:57 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 44rDqv1fnCz5wvF; Fri, 26 Apr 2019 15:07:55 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 44rDqv0Wbxz1xpP; Fri, 26 Apr 2019 15:07:55 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM21.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 26 Apr 2019 15:07:54 +0200
From: <mohamed.boucadair@orange.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "Jon Shallow" <supjps-ietf@jpshallow.com>, 'kaname nishizuka' <kaname@nttv6.jp>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
Thread-Index: AdT6ZmI8uG0f606MQBW+/9uvcTWn6QA3ueOAAAD5v4AAAuISAAACLWCwAASh2bAAAFNQMAAALZggAB/gx7AADZnDQAAB9k5g
Date: Fri, 26 Apr 2019 13:07:54 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA6649C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <c3c9614f-908a-c132-cd35-6c627e341f2b@nttv6.jp> <012601d4fb49$3328c000$997a4000$@jpshallow.com> <BYAPR16MB279020119E24ADCB54B339E3EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6591A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27903D8D208FA3AC951FDEE4EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA65AD6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB279013E8029BE0294293A333EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6623D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790146175B845622B2EF438EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB2790146175B845622B2EF438EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/64z98PFZiHbbgmSzvwFk6Suz04Y>
Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 13:08:00 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : vendredi 26 avril 2019 14:20
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka'; dots@ietf.org
> Objet : RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> > -----Original Message-----
> > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: Friday, April 26, 2019 11:22 AM
> > To: Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > dots@ietf.org
> > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> >
> > This email originated from outside of the organization. Do not click links
> or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> >
> > Hi Tiru,
> >
> > The question then is: How knowing these stats will help in softening the
> > impact on the "business of the victim" other than observing that traffic is
> > being rate-limited (which is already known to the client)? That information
> > will be made available anyway once the DOTS data channel is functional
> again.
> 
> While the DDOS attack is progress (it may last for few weeks), the ACL stats
> can help the client learn the scale of the DDoS attack, and can identify
> alternate mitigation providers capable of handling the attack scale.

[Med] Wouldn't that be inferred from the aggregate stats returned in the signal channel and local observation?

> 
> >
> > An example to soften such impacts could be: A DOTS client can manipulate
> > ACLs with different rate-limit policies that it can activate/deactivate
> based on
> > local available information AND/OR status/aggregate stats received via the
> > signal channel without relying on ACL-specific stats received from the
> server.
> 
> If the server can provide the aggregate stats, it can also provide ACL-
> specific stats.

[Med] If it can do so, it can do it also for any ACL. 

 ACL-specific stats and mitigation stats will give a clear
> picture of the traffic rate-limited, bad traffic dropped by the DDoS
> mitigation system, and using these stats the DOTS client can heuristically
> determine the amount of legitimate traffic dropped because of rate-limit and
> the impact of the attack on its service.

[Med] The impact can be observed locally (e.g., bad QoS, inability to access a service, instable connectivity, etc.). I still don’t see how sharing the ACL stats will be helpful here. 

A DOTS client can preinstall the same rate-limit filter with but with different policies. It can select the appropriate ACL to activate/deactivate based on local experience. 

> 
> Cheers,
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > Envoyé : jeudi 25 avril 2019 16:26
> > > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka';
> > > dots@ietf.org Objet : RE: [Dots]
> > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > >
> > > > -----Original Message-----
> > > > From: mohamed.boucadair@orange.com
> > > > <mohamed.boucadair@orange.com>
> > > > Sent: Thursday, April 25, 2019 7:48 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > > > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > dots@ietf.org
> > > > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > Stats issue
> > > >
> > > >
> > > >
> > > > Re-,
> > > >
> > > > Why it would be useful to share stats for ACLs activated via the
> > > > signal
> > > channel
> > > > but not for (pre-installed) ACLs that are automatically activated
> > > > during mitigations ?
> > >
> > > The rate-limit ACL activated via the signal channel is a last resort
> > > employed by the DOTS client to mitigate the volumetric attack, it has
> > > an adverse effect of blocking not just the attack traffic but also
> > > legitimate traffic, and potentially impacts the business of the victim
> > > (e.g. good users cannot leverage its service), hence it's stats look more
> > critical to me.
> > >
> > > -Tiru
> > >
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > Envoyé : jeudi 25 avril 2019 16:13 À : BOUCADAIR Mohamed TGI/OLN;
> > > > > Jon Shallow; 'kaname nishizuka'; dots@ietf.org Objet : RE: [Dots]
> > > > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mohamed.boucadair@orange.com
> > > > > > <mohamed.boucadair@orange.com>
> > > > > > Sent: Thursday, April 25, 2019 5:37 PM
> > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > > > > > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > > > dots@ietf.org
> > > > > > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > > > Stats issue
> > > > > >
> > > > > >
> > > > > >
> > > > > > Tiru,
> > > > > >
> > > > > > Even if we assume that ACL-specific stats can be communicated
> > > > > > via the
> > > > > signal
> > > > > > channel (which we don't have an agreement on it so far), this is
> > > > > > not
> > > > > specific
> > > > > > to the filter-control spec but the same reasoning would apply
> > > > > > for all ACLs instructed by the DOTS client (not only those that
> > > > > > are adjusted during
> > > > > attack
> > > > > > times).
> > > > >
> > > > > My point is, If the ACL is activated using the signal channel,
> > > > > since the ACL is part of the mitigation request, only the
> > > > > activated ACL stats needs to be conveyed in the mitigation status.
> > > > > Other ACLs activated using data channel are not part of mitigation
> > > > > request, so no need to convey their stats using the signal channel.
> > > > >
> > > > > -Tiru
> > > > >
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > Envoyé : jeudi 25 avril 2019 13:04 À : Jon Shallow; 'kaname
> > > > > > > nishizuka'; BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet :
> > RE:
> > > > > > > [Dots]
> > > > > > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of Jon Shallow
> > > > > > > > Sent: Thursday, April 25, 2019 2:58 PM
> > > > > > > > To: 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > > > > > mohamed.boucadair@orange.com; dots@ietf.org
> > > > > > > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control)
> > > > > > > > ACL Stats issue
> > > > > > > >
> > > > > > > > This email originated from outside of the organization. Do
> > > > > > > > not click links
> > > > > > > or
> > > > > > > > open attachments unless you recognize the sender and know
> > > > > > > > the content is safe.
> > > > > > > >
> > > > > > > > Hi there,
> > > > > > > >
> > > > > > > > The advantage of separating out the counters for the
> > > > > > > > different ACLs is that the DOTS client can then determine
> > > > > > > > what is being effective or
> > > > > not.
> > > > > > > However,
> > > > > > > > if (signal) data is able to get from the DOTS server to the
> > > > > > > > DOTS client,
> > > > > > > then it
> > > > > > > > is likely that the data channel will still be operable and
> > > > > > > > can be used to
> > > > > > > get
> > > > > > > > these numbers so I still do not think that this should be
> > > > > > > > over the signal channel.
> > > > > > > >
> > > > > > > > I think that that the GET response (or observe response)
> > > > > > > > bytes-dropped
> > > > > > etc.
> > > > > > > > should be the total dropped - i.e. the sum of the ACls and
> > > > > > > > what the DMS is otherwise doing as it refers to the mitigation
> > request.
> > > > > > >
> > > > > > > If the DOTS server knows the traffic dropped by ACLs and the
> > > > > > > traffic dropped by DMS, why can't it provide this statistics
> > > > > > > separately instead of summing it.  If the incoming link is
> > > > > > > saturated, data channel will not function  but signal channel
> > > > > > > (using UDP) will work and there is a good possibility that one
> > > > > > > of the GET responses periodically sent will reach the client
> > > > > > > (As you already know, DOTS signal
> > > > > > channel is tolerant to high packet loss in one direction).
> > > > > > >
> > > > > > > -Tiru
> > > > > > >
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Jon
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
> > > > > > > > > kaname nishizuka
> > > > > > > > > Sent: 25 April 2019 10:00
> > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org
> > > > > > > > > Subject: Re: [Dots]
> > > > > > > > > (draft-ietf-dots-signal-filter-control)
> > > > > > > > > ACL Stats issue
> > > > > > > > >
> > > > > > > > > Hi Med, all,
> > > > > > > > >
> > > > > > > > > Regarding with the issue, I'm not convinced of the benefit
> > > > > > > > > to return the activated ACL statistics over signal-channel.
> > > > > > > > >
> > > > > > > > > The idea of this draft is based on this situation (quoted
> > > > > > > > > from Jon's
> > > > > > > > > comment):
> > > > > > > > > (It is) very unreliable when the inbound pipe is running
> full.
> > > > > > > > > If the pipe is not running full, then this information can
> > > > > > > > > be obtained over the
> > > > > > > data
> > > > > > > > channel.
> > > > > > > > >
> > > > > > > > > ACL stats can be get over the data-channel. I don't see
> > > > > > > > > any reason to reproduce the same function.
> > > > > > > > >
> > > > > > > > > Further more, I don't think the DOTS server should notify
> > > > > > > > > that DOTS client with the change by including the
> > > > > > > > > corresponding
> > > > > > > > > acl-* parameters in an asynchronous notification.
> > > > > > > > > The basic behavior is already written in the draft:
> > > > > > > > >     This specification does not require any modification
> > > > > > > > > to the
> > > > > efficacy
> > > > > > > > >     update and the withdrawal procedures defined in
> > > > > > > > >     [I-D.ietf-dots-signal-channel].  In particular,
> > > > > > > > > ACL-related
> > > > > clauses
> > > > > > > > >     are not included in a PUT request used to send an
> > > > > > > > > efficacy update
> > > > > and
> > > > > > > > >     DELETE requests.
> > > > > > > > >
> > > > > > > > > If so, the server need not to store any resource about
> > > > > > > > > acl-* per mitigation request, which make the function of
> > > > > > > > > the signal-filter-control
> > > > > > > > simple enough.
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > > Kaname
> > > > > > > > >
> > > > > > > > > On 2019/04/24 15:24, mohamed.boucadair@orange.com wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > We do have one pending issue to be resolved for this draft.
> > > > > > > > > > The issue is
> > > > > > > > > available at:
> > > > > > > > > > https://github.com/boucadair/filter-control/issues/1
> > > > > > > > > >
> > > > > > > > > > We need your feedback on this.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Med
> > > > > > > > > >
> > > > > > > > > >> -----Message d'origine----- De : Dots
> > > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de
> > > > > > > > > >> internet- drafts@ietf.org Envoyé : mercredi 24 avril
> > > > > > > > > >> 2019
> > > > > > > > > >> 07:34 À
> > > > > :
> > > > > > > > > >> i-d-announce@ietf.org Cc : dots@ietf.org Objet : [Dots]
> > > > > > > > > >> I-D
> > > > > Action:
> > > > > > > > > >> draft-ietf-dots-signal-filter-control-00.txt
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> A New Internet-Draft is available from the on-line
> > > > > > > > > >> Internet-Drafts directories.
> > > > > > > > > >> This draft is a work item of the DDoS Open Threat
> > > > > > > > > >> Signaling WG of the
> > > > > > > > > IETF.
> > > > > > > > > >>
> > > > > > > > > >>          Title           : Controlling Filtering Rules
> Using
> > > > > > > Distributed
> > > > > > > > > >> Denial-of-Service Open Threat Signaling (DOTS) Signal
> > Channel
> > > > > > > > > >>          Authors         : Kaname Nishizuka
> > > > > > > > > >>                            Mohamed Boucadair
> > > > > > > > > >>                            Tirumaleswar Reddy
> > > > > > > > > >>                            Takahiko Nagata
> > > > > > > > > >> 	Filename        : draft-ietf-dots-signal-filter-
> control-
> > > 00.txt
> > > > > > > > > >> 	Pages           : 23
> > > > > > > > > >> 	Date            : 2019-04-23
> > > > > > > > > >>
> > > > > > > > > >> Abstract:
> > > > > > > > > >>     This document specifies an extension to the DOTS
> > > > > > > > > >> signal
> > > > > channel
> > > > > > so
> > > > > > > > > >>     that DOTS clients can control their filtering rules
> > > > > > > > > >> when an
> > > > > attack
> > > > > > > > > >>     mitigation is active.
> > > > > > > > > >>
> > > > > > > > > >>     Particularly, this extension allows a DOTS client
> > > > > > > > > >> to activate or
> > > > > > > de-
> > > > > > > > > >>     activate existing filtering rules during a DDoS
> attack.
> > > The
> > > > > > > > > >>     characterization of these filtering rules is
> > > > > > > > > >> supposed to be
> > > > > > > conveyed
> > > > > > > > > >>     by a DOTS client during an idle time by means of
> > > > > > > > > >> the DOTS
> > > data
> > > > > > > > > >>     channel protocol.
> > > > > > > > > >>
> > > > > > > > > >> Editorial Note (To be removed by RFC Editor)
> > > > > > > > > >>
> > > > > > > > > >>     Please update these statements within the document
> > > > > > > > > >> with the
> > > > > > RFC
> > > > > > > > > >>     number to be assigned to this document:
> > > > > > > > > >>
> > > > > > > > > >>     o  "This version of this YANG module is part of RFC
> XXXX;"
> > > > > > > > > >>
> > > > > > > > > >>     o  "RFC XXXX: Controlling Filtering Rules Using
> > > > > > > > > >> Distributed
> > > > > > > Denial-
> > > > > > > > > >>        of-Service Open Threat Signaling (DOTS) Signal
> > > > > > > > > >> Channel";
> > > > > > > > > >>
> > > > > > > > > >>     o  reference: RFC XXXX
> > > > > > > > > >>
> > > > > > > > > >>     o  [RFCXXXX]
> > > > > > > > > >>
> > > > > > > > > >>     Please update these statements with the RFC number
> > > > > > > > > >> to be assigned
> > > > > > > > to
> > > > > > > > > >>     the following documents:
> > > > > > > > > >>
> > > > > > > > > >>     o  "RFC SSSS: Distributed Denial-of-Service Open
> > > > > > > > > >> Threat
> > > > > Signaling
> > > > > > > > > >>        (DOTS) Signal Channel Specification" (used to be
> > > > > > > > > >>        [I-D.ietf-dots-signal-channel])
> > > > > > > > > >>
> > > > > > > > > >>     o  "RFC DDDD: Distributed Denial-of-Service Open
> > > > > > > > > >> Threat
> > > > > Signaling
> > > > > > > > > >>        (DOTS) Data Channel Specification" (used to be
> > > > > > > > > >>        [I-D.ietf-dots-data-channel])
> > > > > > > > > >>
> > > > > > > > > >>     Please update the "revision" date of the YANG module.
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> The IETF datatracker status page for this draft is:
> > > > > > > > > >> https://datatracker.ietf.org/doc/draft-ietf-dots-signal
> > > > > > > > > >> -fil
> > > > > > > > > >> ter-
> > > > > > > > > >> cont
> > > > > > > > > >> rol/
> > > > > > > > > >>
> > > > > > > > > >> There are also htmlized versions available at:
> > > > > > > > > >> https://tools.ietf.org/html/draft-ietf-dots-signal-filt
> > > > > > > > > >> er-c
> > > > > > > > > >> ontr
> > > > > > > > > >> ol-0
> > > > > > > > > >> 0
> > > > > > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-s
> > > > > > > > > >> igna
> > > > > > > > > >> l-fi
> > > > > > > > > >> lter
> > > > > > > > > >> -control-
> > > > > > > > > >> 00
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> Please note that it may take a couple of minutes from
> > > > > > > > > >> the time of
> > > > > > > > > submission
> > > > > > > > > >> until the htmlized version and diff are available at
> > > > > tools.ietf.org.
> > > > > > > > > >>
> > > > > > > > > >> Internet-Drafts are also available by anonymous FTP at:
> > > > > > > > > >> ftp://ftp.ietf.org/internet-drafts/
> > > > > > > > > >>
> > > > > > > > > >>
> > _______________________________________________
> > > > > > > > > >> Dots mailing list
> > > > > > > > > >> Dots@ietf.org
> > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Dots mailing list
> > > > > > > > > > Dots@ietf.org
> > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Dots mailing list
> > > > > > > > > Dots@ietf.org
> > > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Dots mailing list
> > > > > > > > Dots@ietf.org
> > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots