Re: [Dots] default port number RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

<mohamed.boucadair@orange.com> Wed, 03 July 2019 10:47 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 9629D120735; Wed, 3 Jul 2019 03:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EVVyh6fSj29t; Wed, 3 Jul 2019 03:47:05 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3061512021C; Wed, 3 Jul 2019 03:47:05 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 45dyTz3by8z5x7b; Wed, 3 Jul 2019 12:47:03 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45dyTz2tg8zDq7T; Wed, 3 Jul 2019 12:47:03 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([fe80::54f9:a664:e400:452a%21]) with mapi id 14.03.0439.000; Wed, 3 Jul 2019 12:47:03 +0200
From: <mohamed.boucadair@orange.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "dots@ietf.org" <dots@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: =?utf-8?B?ZGVmYXVsdCBwb3J0IG51bWJlciBSRTogW0RvdHNdICBNaXJqYSBLw7xobGV3?= =?utf-8?B?aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u?= =?utf-8?Q?el-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AdUxg6WgIQonMga/RXuzKVnxm7VKxf//5asA///T8oA=
Date: Wed, 3 Jul 2019 10:47:02 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB2CB1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EAB2BDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <747CDE21-58FB-4C6A-B0D8-2686FAA38CCD@kuehlewind.net>
In-Reply-To: <747CDE21-58FB-4C6A-B0D8-2686FAA38CCD@kuehlewind.net>
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/FHcAf-HbDStNyOY19vmuaSfLuZA>
Subject: Re: [Dots] =?utf-8?q?default_port_number_RE=3A___Mirja_K=C3=BChlewin?= =?utf-8?q?d=27s_Discuss_on_draft-ietf-dots-signal-channel-31=3A_=28with_D?= =?utf-8?q?ISCUSS_and_COMMENT=29?=
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: Wed, 03 Jul 2019 10:47:08 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Envoyé : mercredi 3 juillet 2019 12:08
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Cc : draft-ietf-dots-signal-channel@ietf.org; Konda, Tirumaleswar Reddy;
> dots@ietf.org; frank.xialiang@huawei.com; The IESG; dots-chairs@ietf.org
> Objet : Re: default port number RE: [Dots] Mirja Kühlewind's Discuss on
> draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> See below.
> 
> > On 3. Jul 2019, at 11:42, <mohamed.boucadair@orange.com>;
> <mohamed.boucadair@orange.com>; wrote:
> >
> > Re-,
> >
> > Let's recap:
> >
> > (1) The initial objection from the expert is to reuse default CoAP port
> (5684)
> > (2) We clarified why this is not an option
> > (3) You agreed "port 5684 is no alternative".
> > (4) You think that dynamic port would be preferable instead of "fixed"
> (assuming you meant default) because an IP address will be configured
> anyway.
> > (5) In the meantime you argued that protocols like SIP have "good reason
> for a fixed port", while RFC3261 says explicitly the following:
> >
> > ==
> >   A server SHOULD be prepared to receive requests on any IP address,
> >                                                     ^^^^
> >   port and transport combination that can be the result of a DNS lookup
> >   ^^^^
> >   on a SIP or SIPS URI [4] that is handed out for the purposes of
> >   communicating with that server.
> > ==
> 
> Yes SIP can also use dynamic ports. Anyway... no need to discuss SIP here.
> 
> >
> > (6) We provided two address selection logics that can be followed by a
> DOTS client to ease deployments ** without ** requiring configuring an IP
> address:
> >  - Assume the default gateway is the DOTS server. This is typically the
> case where a CPE embeds a DOTS gateway. For this case, the client does not
> need to be configured explicitly with an IP address/port. Internal
> hosts/CPE won't be required to be upgraded to support a mechanism to
> discover the DOTS server. An example of procedure to contact a server
> would be:
> >    --- use any server/port that use explicitly configured
> >    --- if not, try the default router.
> >  - Make use of anycast for DOTS: /draft-ietf-dots-architecture-
> 14#section-3.2.4 says the following:
> >
> >   "benefits, anycast signaling potentially offers the following:
> >
> >   o  Simplified DOTS client configuration, including service discovery
> >      through the methods described in [RFC7094].  In this scenario, the
> >      "instance discovery" message would be a DOTS client initiating a
> >      DOTS session to the DOTS server anycast Service Address, to which
> >      the DOTS server would reply with a redirection to the DOTS server
> >      unicast address the client should use for DOTS."
> >
> > Do you want us to include NEW text to discuss this in the draft?
> 
> Yes, these are good cases to request a default port. Thanks for
> clarifying. Unfortunately they are no discussed in this document. I did
> not read draft-ietf-dots-architecture in detail yet because it has not
> been in IESG evaluation yet. However, providing a pointer to draft-ietf-
> dots-architecture-14#section-3.2.4 in this document in section 4.1. would
> be certainly good. I also didn’t find any discussion in any document about
> the first case (use of default router). Please also add text in section
> 4.1 or provide a pointer respectively (maybe I just didn’t find it
> quickly).
> 

[Med] Great. Basically, we will update the draft to say these addresses are added to candidate address list provided as input to HE (RFC8305).

> Also looking that these documents it seem to me that draft-ietf-dots-
> architecture and draf-ietf-dots-server-discovery should probably both be 
> normative references.
> 
> And looking att he list of informative references I find it also weird to
> see draft-ietf-dots-data-channel, draft-ietf-tls-dtls13 (which is now RFC
> 8446) and draft-ietf-core-yang-cbor there. Looks like you simply put all
> drafts in the informative category.

[Med] We did already discussed this (draft-ietf-core-yang-cbor) as part of other DISCUSSes (Alissa/Alexey/Adam). No need to reopen the point. RFC8446 is already cited as normative. draft-ietf-tls-dtls13 is cited as informative because we don’t use any normative language when citing it. Unless I'm mistaken, we did already discussed the others with Ben during his AD review. 

 That’s not how this is supposed to
> work.
> 
> Ben, please double-check the references and provide advise!
> 
> Mirja
>