Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-00.txt

Jon Shallow <supjps-ietf@jpshallow.com> Mon, 24 August 2020 13:05 UTC

Return-Path: <supjps-ietf@jpshallow.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 EC3CE3A0DAF for <dots@ietfa.amsl.com>; Mon, 24 Aug 2020 06:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 OS9LwZLCc4_v for <dots@ietfa.amsl.com>; Mon, 24 Aug 2020 06:05:51 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 234D13A0CFF for <dots@ietf.org>; Mon, 24 Aug 2020 06:05:50 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1kACAT-0002I5-8P; Mon, 24 Aug 2020 14:05:45 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: 'kaname nishizuka' <kaname@nttv6.jp>, dots@ietf.org, Valery Smyslov <valery@smyslov.net>
References: <159774885713.10211.5341151302930796088@ietfa.amsl.com> <04af01d675f7$3cedd600$b6c98200$@smyslov.net> <7239960d-0de3-801a-dd9f-e82b93580ae9@nttv6.jp>
In-Reply-To: <7239960d-0de3-801a-dd9f-e82b93580ae9@nttv6.jp>
Date: Mon, 24 Aug 2020 14:05:39 +0100
Message-ID: <163901d67a17$440b5c40$cc2214c0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFlFbIRFtKZ/EtTi8c9PYs3hY/wigDAQ88tAhCoxESqE3oMMA==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/bfyrdncVSz00HpCoPfiHqwYc6GI>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-00.txt
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: Mon, 24 Aug 2020 13:05:54 -0000

Hi Kaname,

Well spotted!

I agree that 

           leaf attack-status {
             type iana-signal:attack-status;
             description
               "Indicates the status of an attack as seen by the
                DOTS client.";
           }
Should be moved up to just after (in the yang definition ietf-dots-signal-channel@2020-07-02.yang)
       leaf trigger-mitigation {
         type boolean;
         default "true";
         description
           "If set to 'false', DDoS mitigation will not be
            triggered unless the DOTS signal channel
            session is lost.";
       }

And will get corrected.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka
> Sent: 24 August 2020 08:28
> To: Valery Smyslov; dots@ietf.org
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-00.txt
> 
> Hi Med, all.
> 
> `attack-status` is now under server-to-client-only in RFC8782 bis, but I just
> want to clarify whether it's correct.
> 
> In 4.4.3, it is said:
>     The 'attack-status' parameter is a mandatory attribute when
>     performing an efficacy update.  The various possible values contained
>     in the 'attack-status' parameter are described in Table 4.
>              +-----------+-------------------------------------+
>              | Parameter | Description                         |
>              |     Value |                                     |
>              +===========+=====================================+
>              |         1 | The DOTS client determines that it  |
>              |           | is still under attack.              |
>              +-----------+-------------------------------------+
>              |         2 | The DOTS client determines that the |
>              |           | attack is successfully mitigated    |
>              |           | (e.g., attack traffic is not seen). |
>              +-----------+-------------------------------------+
> 
>                  Table 4: Values of 'attack-status' Parameter
> 
> 
> regards,
> Kaname Nishizuka
> 
> 
> On 2020/08/19 16:06, Valery Smyslov wrote:
> > Hi,
> >
> > according to the roadmap we discussed for the replacement
> > of RFC 8782, we are going to request yangdoctors
> > and opsdir reviews for the just adopted draft to double check
> > that all the changes in YANG module are fine with them.
> > We are going to issue WGLC shortly after the reviews are complete.
> >
> > Regards,
> > Frank & Valery.
> >
> >> 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           : Distributed Denial-of-Service Open Threat Signaling
> (DOTS) Signal Channel Specification
> >>          Authors         : Mohamed Boucadair
> >>                            Jon Shallow
> >>                            Tirumaleswar Reddy.K
> >> 	Filename        : draft-ietf-dots-rfc8782-bis-00.txt
> >> 	Pages           : 119
> >> 	Date            : 2020-08-18
> >>
> >> Abstract:
> >>     This document specifies the Distributed Denial-of-Service Open Threat
> >>     Signaling (DOTS) signal channel, a protocol for signaling the need
> >>     for protection against Distributed Denial-of-Service (DDoS) attacks
> >>     to a server capable of enabling network traffic mitigation on behalf
> >>     of the requesting client.
> >>
> >>     A companion document defines the DOTS data channel, a separate
> >>     reliable communication layer for DOTS management and configuration
> >>     purposes.
> >>
> >>     This document obsoletes RFC 8782.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-00
> >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-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