Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)

mohamed.boucadair@orange.com Thu, 29 October 2020 06:55 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 7A6A53A0920; Wed, 28 Oct 2020 23:55:24 -0700 (PDT)
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 ynv94JnCKAN3; Wed, 28 Oct 2020 23:55:23 -0700 (PDT)
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 B9B2A3A08CF; Wed, 28 Oct 2020 23:55:22 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CMGRF0TqMz5vvs; Thu, 29 Oct 2020 07:55:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603954521; bh=Mnoy3JPj/r/bS9orX0WD73EUeJDIkLiQPo6ea6NwCIQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=h1u3b0oBUn6fcrC0NVMIgUWY6nFEahwB+mGPvkizVZfekcMlqJ3TBTUFjK93U7eoI IKvIU1BtuQKIADq/7yfchjd8xFLWZFR0wnyAAhA3s75+xete/fwRpZt2xvxCpGTrP8 hMV5ENz3BOBJAUeA8kVvMtF2LvLyAwwF+95P6TE5ikaxAo+fcCnyHfBGxTYlCP5tyw piDcgCX6wra5ChnU5wZcBT0ME7dbwySuQBHxbFkyQDm5Cg55pe1w6VzHIAdXgrrlCw /atHfZPlOlsOfg6wMRbSnapfq+ikGpVZrhiWG4zczRJqCQuBV33Tpuuf7kd9/XqjkE AKIiUczez+mIQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4CMGRD6mjVzFpWf; Thu, 29 Oct 2020 07:55:20 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-server-discovery@ietf.org" <draft-ietf-dots-server-discovery@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>, Valery Smyslov <valery@smyslov.net>
Thread-Topic: Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)
Thread-Index: AQHWrXLu59qgZV3TGUSV9ZZIRKrnyKmuIcAQ
Date: Thu, 29 Oct 2020 06:55:20 +0000
Message-ID: <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160392121572.3395.6848068643884505857@ietfa.amsl.com>
In-Reply-To: <160392121572.3395.6848068643884505857@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/dots/-EgICDoLrS0JZA8lTMAp2_yA-cA>
Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)
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: Thu, 29 Oct 2020 06:55:24 -0000

Hi Barry, 

Thanks you for the comments.

I updated the draft to address the review. You can track the changes at: https://tinyurl.com/dots-discovery-iesg. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba via Datatracker [mailto:noreply@ietf.org]
> Envoyé : mercredi 28 octobre 2020 22:40
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-dots-server-discovery@ietf.org; dots-
> chairs@ietf.org; dots@ietf.org; Valery Smyslov <valery@smyslov.net>;
> valery@smyslov.net
> Objet : Barry Leiba's No Objection on draft-ietf-dots-server-
> discovery-14: (with COMMENT)
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-dots-server-discovery-14: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/
> 
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> Overall discussion question (but not at blocking DISCUSS level):
> Does it make sense for DOTS clients to proactively discover
> appropriate DOTS servers *before* a DDoS attack hits, to avoid the
> issue of discovery being blocked by the attack that the client is
> trying to report?  Should this document discuss that?
> 

[Med] This is already covered in the text as the discovery is triggered by new network attachments (which includes bootstrapping). The discovery information is thus available independently of the attack conditions. 

> Other comments, all minor:
> 
> — Section 1 —
> 
>    This approach allows to
>    reduce the impact of an attack and leads to more efficient
> defensive
> 
> Nit: “allows to” isn’t proper English, as it lacks a subject:
> “allows <some
> entity> to”.  I think the subject you want here is DOTS, so maybe
> this works?:
> 
> NEW
>    With this approach, DOTS can
>    reduce the impact of an attack and lead to more efficient
> defensive END
> 

[Med] Fixed. Thanks.

> — Section 2 —
> 
>    The reader should be familiar with the terms defined in
> [RFC8811],
>    [RFC3958], and [I-D.ietf-dots-signal-call-home].
> 
> I think this makes RFC 8811 and draft-ietf-dots-signal-call-home
> normative references, as they define require terminology.  Certainly
> 8811 is normative in any case, as the architecture needs to be
> understood.
> 

[Med] As we don't deal with how DOTS sessions are handled nor we interfere with the internal DOTS signalling machinery, we don't cite 8811 (but also 8782, 8783) as normative ones. Of course, having the required background is useful but implementing the discovery process does not require these pieces.

I understand the references in the terminology section may suggest that knowledge is required. To avoid that, the terminology section is updated to list the terms used in the document. 

> — Section 3 —
> 
>    It is tempting to specify one single discovery mechanism for
> DOTS.
>    Nevertheless, the analysis of the various use cases sketched in
> 
> Nit: Ignore this if you’re happy with the text as it is, but I would
> remove the first sentence and just start this as “Analysis of the
> various use cases…”.

[Med] Went with your proposal. 

> 
> Please expand “CPE” on first use — especially as it’s confusingly
> and contradictorily described as “Customer Premises Equipment”
> (provided by the
> operator) and “Customer Provided Equipment” (not provided by the
> operator), so we need to know which you mean.
> 

[Med] Done. 

> — Section 4 —
> 
>    These may be
>    specified either as IP addresses or the DNS name of a DOTS
>    server.
> 
> The first half of the sentence is plural and the second singular.
> Should both be plural, “…either as IP addresses or DNS names of DOTS
> servers.” ?  If it’s intentional that it can be multiple IP
> addresses but only one DNS name,

[Med] I confirm.

 it would be better to be more
> explicit about that.
> 

[Med] Changed to "a list of IP addresses" 

> — Section 5 —
> 
>    and server while accommodating for the current best practices
> 
> Nit: not “accommodating for”: just “accommodating”.

[Med] Fixed. 

> 
> — Section 5.1.1 —
> 
>    o  dots-agent-name: A fully qualified domain name of the peer
> DOTS
>       agent.  This field is formatted as specified in Section 10 of
>       [RFC8415].
> 
> As all Section 10 of 8415 does is send us to Section 3.1 of 1035,
> why not just point to the latter directly, rather than making the
> reader follow an extra reference?
> 
> And it wouldn’t be bad to append to the “an example” sentence as
> follows:
> 
> NEW
>    An example of the dots-agent-name encoding is shown in Figure 4.
>    This example conveys the FQDN "dots.example.com.”, and the
>    resulting Option-length field is 18.
> END
> 

[Med] Agree. Done. 


_________________________________________________________________________________________________________________________

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.