Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)

mohamed.boucadair@orange.com Thu, 17 December 2020 15:22 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 423563A097C; Thu, 17 Dec 2020 07:22:36 -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 OMS5C0N6JGZz; Thu, 17 Dec 2020 07:22:34 -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 5FF9A3A0992; Thu, 17 Dec 2020 07:22:34 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4CxbMr5H9BzyZh; Thu, 17 Dec 2020 16:22:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608218552; bh=wWSZuUuK12ijZaC7i0pgk2xVa1oplN0VPLJTyhaEwmg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IgxgaTcP78sOkOcWuYSSxWuBXAOpUqBbcZROUfJ5Yfm9pMsOG8DQrtQgMkP0aak8y nhzchCvq3961NLRsOjHtnOS9bmy8jYt3cWlYhCVsjO+6neQ3OJJhKuE57yz8wU11aV O/rP5SSg/4m1+3LJ0CoQ0pCeEdGeuAdpP0XYOjQgNaGBvSUxdqFX48jQsx2GCVA+LU EK+b5VK2YjAhwh4LmpC0x+/+2QumjfcBmwYuhgrO9TbH/VdrbvoipoGEahf+6elNRR ppMEUyQiBgOo+eERWRQHmSGl9+1KbDT+nXPBwt2v7rVaVjjlIOM3YPoP0895PMufDU pqx9qJWI1h61w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4CxbMr4RH6z8sYH; Thu, 17 Dec 2020 16:22:32 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-signal-call-home@ietf.org" <draft-ietf-dots-signal-call-home@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>, Valery Smyslov <valery@smyslov.net>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)
Thread-Index: AQHW1IEG8/aDaVHfFEKHhsf7enK9U6n7Z1VQ
Date: Thu, 17 Dec 2020 15:22:32 +0000
Message-ID: <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160821536495.8335.5498062431481972966@ietfa.amsl.com>
In-Reply-To: <160821536495.8335.5498062431481972966@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.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/mXraS7bPUoRicqRPJcNQT2N_CTA>
Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)
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, 17 Dec 2020 15:22:36 -0000

Hi Magnus, 

I wonder whether you had a chance to read this message where explain why this is a new service, not a variant of an existing service: https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Magnus Westerlund via Datatracker [mailto:noreply@ietf.org]
> Envoyé : jeudi 17 décembre 2020 15:29
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-dots-signal-call-home@ietf.org; dots-
> chairs@ietf.org; dots@ietf.org; Valery Smyslov <valery@smyslov.net>;
> valery@smyslov.net
> Objet : Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS)
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-dots-signal-call-home-11: Discuss
> 
> 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-signal-call-home/
> 
> 
> 
> --------------------------------------------------------------------
> --
> DISCUSS:
> --------------------------------------------------------------------
> --
> 
> Section 7.1: Port request for DOTS signal for home.
> 
> I think the WG has failed to take the assignment principles in RFC
> 6335 to
> heart:
> 
> >From Section 7:
> 
>    "The basic principle of service name and port number registry
>    management is to conserve use of the port space where possible."
> 
>    o  IANA strives to assign only one assigned port number per
> service
>       or application.
> 
>       Note: At the time of writing of this document, there is no
> IETF
>       consensus on when it is appropriate to use a second port for
> an
>       insecure version of a protocol.
> 
>    o  IANA strives to assign only one assigned port number for all
>       variants of a service (e.g., for updated versions of a
> service).
> 
>    o  IANA strives to encourage the deployment of secure protocols.
> 
>    o  IANA strives to assign only one assigned port number for all
>       different types of devices using or participating in the same
>       service.
> 
>    o  IANA strives to assign port numbers only for the transport
>       protocol(s) explicitly named in an assignment request.
> 
>    o  IANA may recover unused port numbers, via the new procedures
> of
>       de-assignment, revocation, and transfer.
> 
> After having reviewed Appendix A I think the WG has made the wrong
> choice and also not considered all the available choices for
> enabling DOTS signal and call home to be colocated on the same port.
> Several options exists:
> 
>         - URI name space so that it is the same protocol just making
> requests
>         with different URIs depending on mode - Use the already
> existing
>         settings negotiation to determine the mode of operation. -
> Using ALPN
>         on (D)TLS connection establishment
> 
> >From my perspective the DOTS WG have multiple choices that are
> quite
> >simple to
> solve there colocation issue that would not incur significnat cost
> or overhead.
> Using an additional port do incur a cost of consuming a resource
> that is endless and not easily recoverable. I do share the IANA port
> experts team's verdict that this port assignment should be denied
> and alternative solution found as the motivation appears very weak.
> 
> 
> 
> 


_________________________________________________________________________________________________________________________

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.