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

From: [email-masked]
Date: Tue, 18 Aug 2020 04:07:37 -0700

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/

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 19 Aug 2020 10:06:14 +0300

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.

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 24 Aug 2020 16:27:30 +0900

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

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 24 Aug 2020 14:05:39 +0100

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 [email-masked])
       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: [email-masked]] On Behalf Of kaname nishizuka
> Sent: 24 August 2020 08:28
> To: Valery Smyslov; [email-masked]
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-00.txt
> 
> Hi Med, all.
>

---

From: <[email-masked]>
Date: Thu, 27 Aug 2020 09:25:47 +0000

Hi all,

Yes, this should be fixed. The updated tree would look like: 

OLD: 
           |     +-- (direction)?
           |        +--:(server-to-client-only)
           |           ...
           |           +-- attack-status?
           |                   iana-signal:attack-status

NEW:
           |     +-- (direction)?
           |        +--:(server-to-client-only)
           |        |  ...
           |        +--:(client-to-server-only)
           |           +-- attack-status?
           |                   iana-signal:attack-status

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : lundi 24 août 2020 15:06
> À : 'kaname nishizuka' <[email-masked]>; [email-masked]; Valery
> Smyslov <[email-masked]>
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-00.txt
> 
> Hi Kaname,
> 
> Well spotted!
> 
> I agree that
> 
>            leaf attack-status {
> > `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:
> > > 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.
> > >> 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
> > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-
> bis-0
> > >> 0
> > >>
> > >>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 31 Aug 2020 09:38:57 +0000

Hi Kaname, all, 

FWIW, this is now fixed in the working copy available at: https://github.com/boucadair/rfc8782-yang-update/blob/master/draft-ietf-dots-rfc8782-bis.txt

The change to the YANG module can be tracked using this diff: https://github.com/boucadair/rfc8782-yang-update/commit/ac41fb1c496c5586cb461a7f3efacbabc28fbdca 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 27 août 2020 11:26
> À : Jon Shallow <[email-masked]>; 'kaname nishizuka'
> <[email-masked]>; [email-masked]; Valery Smyslov <[email-masked]>
> > Envoyé : lundi 24 août 2020 15:06 À : 'kaname nishizuka'
> > <[email-masked]>; [email-masked]; Valery Smyslov
> <[email-masked]>
> > > >>     Signaling (DOTS) signal channel, a protocol for signaling
> the
> > need
> > > >>     to a server capable of enabling network traffic mitigation
> on
> > behalf
> > > >> Please note that it may take a couple of minutes from the time
> of
> > > submission
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 1 Sep 2020 14:14:21 +0900

Thanks!

kaname