Re: [Dots] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01

mohamed.boucadair@orange.com Tue, 17 November 2020 16:37 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 1BFA43A14A4; Tue, 17 Nov 2020 08:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 H0COJ2lB10E5; Tue, 17 Nov 2020 08:37:24 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FD33A14AD; Tue, 17 Nov 2020 08:37:24 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CbBS0593Yz5vYx; Tue, 17 Nov 2020 17:37:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1605631040; bh=qRP2Nq68yKprjVa0ztSnmXXicaP6BcW/k5C0XKNO/d0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sWRCCQcTM10pvz+UtCP85krNeX3E2ez39xM/gxGtlSbhWDvXEFHfr+PCxJRdYWPDk 3/YaC+8MveV+1/NMRcMT+Bt8aljUVc+JrIkgq8LmtSTUZedufghVtuXHnsKbNQT6JG M669HHdET8q7zzU76QQtU9xdCXbuyXqhAGZeYhMFzy5aEGyUuD0MSvzB58YwbydGXr gbHy/ozq0FN+1IJYjFlgC1uyOT9YbMOQAhWIdj4I9ES1Mb9O9h36O+z8/h/ILDYE4s s0gzKXORouWQ9H7AZgvvdJhJiG5pIcfGF1DGkjNUelPB3qYyhXb4V1WXycrOUZOt1z xbN4id9N31Kgw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CbBS04NWDzDq84; Tue, 17 Nov 2020 17:37:20 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Dan Romascanu <dromasca@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dots-rfc8782-bis.all@ietf.org" <draft-ietf-dots-rfc8782-bis.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
Thread-Index: AQHWuOWxRsfmZIp+rUWjjXxYIVFGhKnEYHoQgAgsZxA=
Date: Tue, 17 Nov 2020 16:37:20 +0000
Message-ID: <21351_1605631040_5FB3FC40_21351_109_1_787AE7BB302AE849A7480A190F8B93303157E7DD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160517996946.10959.4421104962013499250@ietfa.amsl.com> <16809_1605182453_5FAD23F5_16809_7_5_787AE7BB302AE849A7480A190F8B933031578A18@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <16809_1605182453_5FAD23F5_16809_7_5_787AE7BB302AE849A7480A190F8B933031578A18@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/jb65QYRvpqxVaJe7TTvPFQq-0CY>
Subject: Re: [Dots] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
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: Tue, 17 Nov 2020 16:37:26 -0000

Hi Dan, 

We moved the text that I already quoted from the appendix to the main text and updated with more text to better address your issue #1. 

The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-02 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Envoyé : jeudi 12 novembre 2020 13:01
> À : Dan Romascanu <dromasca@gmail.com>; ops-dir@ietf.org
> Cc : last-call@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org;
> dots@ietf.org
> Objet : RE: Opsdir last call review of draft-ietf-dots-rfc8782-bis-
> 01
> 
> Hi Dan,
> 
> Thank you for the review.
> 
> There are no changes to the on wire protocol because the YANG
> modeled data is mapped to CBOR (Section 3):
> 
>    This document specifies a YANG module for representing DOTS
>    mitigation scopes, DOTS signal channel session configuration
> data,
>    and DOTS redirected signaling (Section 5).  All parameters in the
>                                                ^^^^^^^^^^^^^^^^^^^^
>    payload of the DOTS signal channel are mapped to CBOR types as
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    specified in Table 5 (Section 6).
>    ^^^^^^^^^^^^^^^^^^^^
> 
> and that we managed the update with the following in mind (Appendix
> A.  Summary of Changes From RFC8782):
> 
>    These modifications are made with the constraint to avoid changes
> to
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    the mapping table defined in Table 5 (Section 6).  A DOTS signal^
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    channel attribute that may be present in both requests and
> responses
>    will thus have the same CBOR key value and CBOR major type.
> 
> Even if an implementation relies on the YANG module to generate the
> mapping table, it must anyway to comply with Table 5 (RFC8782):
> 
>       Note: Implementers must check that the mapping output provided
> by
>       their YANG-to-CBOR encoding schemes is aligned with the
> content of
>       Table 5.  For example, some CBOR and JSON types for
> enumerations
>       and the 64-bit quantities can differ depending on the encoder
>       used.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dan Romascanu via Datatracker [mailto:noreply@ietf.org]
> Envoyé :
> > jeudi 12 novembre 2020 12:19 À : ops-dir@ietf.org Cc :
> > last-call@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org;
> > dots@ietf.org; dromasca@gmail.com
> > Objet : Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
> >
> > Reviewer: Dan Romascanu
> > Review result: Has Issues
> >
> > 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. The DOTS data channel is defined in an
> associated
> > document. The document updates RFC 8872.
> >
> > The document is almost Ready from an OPS perspective, but there
> are a
> > couple of issues worth clarification before approval.
> >
> > 1. Appendix A describes the changes from RFC 8782. I could not
> find
> > however any information in the document concerning backwards
> > compatibility and the path of upgrade that an operator should be
> aware
> > about when migrating an existing client, server or the whole
> network
> > from RFC 8782 support. If I missed it, please point and maybe
> detail
> > this information in the Appendix. If not, it would be useful to
> add.
> >
> > 2. I could not find any information about the supplementary
> overload
> > that the changes in signaling brought by this update may bring. If
> > such an analysis was made, it would be useful to mention its
> results.
> > No significant extra-load is fine. If anything different, it would
> be
> > useful to add more details.
> >
> 
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> 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.


_________________________________________________________________________________________________________________________

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.