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

Dan Romascanu <dromasca@gmail.com> Tue, 17 November 2020 16:53 UTC

Return-Path: <dromasca@gmail.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 59F8B3A0DE9; Tue, 17 Nov 2020 08:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 gvSV8oX7lOpE; Tue, 17 Nov 2020 08:53:03 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21623A0DCE; Tue, 17 Nov 2020 08:53:02 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id x18so5295625ilq.4; Tue, 17 Nov 2020 08:53:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nUNEqy1JctNy7Ouc6PmMvv+TeSrhg9acKDnK3fT8q5U=; b=AKJJNdAZ89q6y/BJsN7aWHbLJLA4dawio1FwIK/tgA+UhyWYxZ26r9ul9a9tD+gn9F NopmCvzwd4YfHxAMJOvdSLd1g4v7hkbe4cVIi2LU7uvKJ0+gGTgShSOTojlFIQXnUzsY 9yFA+fGoRH+rJ/kAnFtGuXRBXOpaqJmTLKKJBAXhFCwLeEbzWZ50XoNbV/laEfa13B6w TBrihVOZq4mJ7n5tR2E+EF83mMVf7xbWbFgheYQdZ1vn0nAp5JYtsWMf3b2HQhZTWTTw M0lJa8ugXVBmWAGdIY+LhJMICf7lK1LWxp1wPtCIKT+0Vxd4rdqqp51qu4lAkAG0JM9W PYsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nUNEqy1JctNy7Ouc6PmMvv+TeSrhg9acKDnK3fT8q5U=; b=XSGyPzCrcTSsw1q2HLdJr5riBfoJ/LA9u04icRIBrqa4lNqzpiTwe8cG84WJyLnoDD hWZ/fBpet41jO3lI06+KdOwqAQBzh9uTsh1LAAsubquQWJjrjfCZrmVh1/pPV5Pmp+se lbjeLPtyqnRmJ7++PM4m0C57RpGSaf/Giwib+BUmx1WTLYBFtuIlT9laiRwJKr0LtcYL j22E7xo47CG183mRkvb7S5FAl9WpUTD/bTBIdHPmPZ0pJOWyUmOdk10CHT9P9uqxAxdj TqniEt0r45YFSGSKih+JBAW3rcwB4eCvudwN2RHLe92IwjRYNsxvDqYmauI9CBfwwXkK Fz8g==
X-Gm-Message-State: AOAM532lx31wFzUpDnCZQUkkL0wZWd9/HwI2zkvRyjmgCY/AaUOweUyG XMI/P2CqWwQ16FrrJV7xONn7lyhZ33GXGjIZPOQ=
X-Google-Smtp-Source: ABdhPJwVkApDM4nC88bMklDx+7MxE8BHwlY7EnORswQ0C4vFRVcvnLnwz2xapx8hNTlFPQonNWuXQa1g8H7E5hcM1es=
X-Received: by 2002:a92:50e:: with SMTP id q14mr12379727ile.306.1605631981888; Tue, 17 Nov 2020 08:53:01 -0800 (PST)
MIME-Version: 1.0
References: <160517996946.10959.4421104962013499250@ietfa.amsl.com> <16809_1605182453_5FAD23F5_16809_7_5_787AE7BB302AE849A7480A190F8B933031578A18@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21351_1605631040_5FB3FC40_21351_109_1_787AE7BB302AE849A7480A190F8B93303157E7DD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <21351_1605631040_5FB3FC40_21351_109_1_787AE7BB302AE849A7480A190F8B93303157E7DD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 17 Nov 2020 18:52:49 +0200
Message-ID: <CAFgnS4V9iUN3cEt4cuTqwjkwPne3MV2h_RfSifTbd=E00xhyew@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "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>
Content-Type: multipart/alternative; boundary="000000000000eba8fb05b4505317"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Nq3_TPyZ4FT4wyuRdabJeIZ8ZEU>
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: Tue, 17 Nov 2020 16:53:06 -0000

Thank you. Looks good.

Regards,

Dan


On Tue, Nov 17, 2020 at 6:37 PM <mohamed.boucadair@orange.com> wrote:

> 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.
>
>