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

mohamed.boucadair@orange.com Thu, 12 November 2020 12:01 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EA3A0418; Thu, 12 Nov 2020 04:01:03 -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 uF7u-re1V7XD; Thu, 12 Nov 2020 04:00:59 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDBA3A03FB; Thu, 12 Nov 2020 04:00:56 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4CX0YL0CpMzCrCn; Thu, 12 Nov 2020 13:00:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1605182454; bh=2luna/FZqLi75V3BJDFVE1gPa2oykFrXbv80dIPfSi0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CkWql5EK7/rQgSidXhDktdpUYcZwEO/+ANWnYWSAZGVCCNO2qRcJ4nFqdHPM6zrxf UGSu4Zzziqj8eEXNRwCiDFi///JEY3hRNbrFvUnjF1d4sKW99GVI6i7w+4GpH8IT4K g2FJgSCOtVXNiCXe/hs1gWUoDyCrKnD67qwkx+u5dgdYYAHm0d/F7eiCxPENTYhkhy OUieOrwTAggdzK+TdErLOuMDULTGOdAz2/9sHaWzkEJv7erL7j5D1u0MDlo/OKvp/1 thOk5loaWX12P9juxN2hlArFXo0wxjnxh3ukp//MgoxH/b3NBBXnUF2joq+aOm0xVU z/j6YXD2sQhbw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CX0YK6V3XzDq7P; Thu, 12 Nov 2020 13:00:53 +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+rUWjjXxYIVFGhKnEYHoQ
Date: Thu, 12 Nov 2020 12:00:52 +0000
Message-ID: <16809_1605182453_5FAD23F5_16809_7_5_787AE7BB302AE849A7480A190F8B933031578A18@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160517996946.10959.4421104962013499250@ietfa.amsl.com>
In-Reply-To: <160517996946.10959.4421104962013499250@ietfa.amsl.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/last-call/yNLWFxPuiR4GPGmKq_JI5sR3vf4>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 12:01:03 -0000

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.