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. > >
- [Last-Call] Opsdir last call review of draft-ietf… Dan Romascanu via Datatracker
- Re: [Last-Call] Opsdir last call review of draft-… mohamed.boucadair
- Re: [Last-Call] Opsdir last call review of draft-… mohamed.boucadair
- Re: [Last-Call] Opsdir last call review of draft-… Dan Romascanu