Re: [Dots] draft-ietf-dots-discovery: Valery's Comment in Montreal

"Valery Smyslov" <valery@smyslov.net> Fri, 02 August 2019 08:55 UTC

Return-Path: <valery@smyslov.net>
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 28B3012004E for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 01:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 pTZL_u3k1Ofb for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 01:55:11 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4659312001B for <dots@ietf.org>; Fri, 2 Aug 2019 01:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IFYwkbbD6/LGLkXAH4XdoEyx/hUXIkjWYK5UlCrE3Z8=; b=i60NkAUcdztOSVOukt5sNLxoKP Cc9eUsKpR58dQorvxsmwins2zJi455yashcpEBQT8luM1xsfi8ir05XPCY6kD9YfOUBWXXzTRD1Mj QdibANAnyWPQdRT6o0s0ftuj14/o1pgLaOWHnbWLxzD4CZ9au5v0/lPetmcdfmcb6XvjGSToc/Of1 IGeQ6ddLitWGJyKCe2a1GpJEG9B3krdyvSWuH0VEeS9P+XsFTajDxy8aqh0MZejgC/M87quLKEXWR t5hrq1N941/+AL3BxcQOQk85243rqffyKbXaDhYg4yu7fL+L6xGSVEwCLU6IwtT5v8er6jOTD7imG vVnVJlPg==;
Received: from [82.138.51.4] (port=59735 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from <valery@smyslov.net>) id 1htTL9-0000G0-JL; Fri, 02 Aug 2019 04:55:08 -0400
From: "Valery Smyslov" <valery@smyslov.net>
To: <mohamed.boucadair@orange.com>
Cc: <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B9330312EB910@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EB910@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 2 Aug 2019 11:54:59 +0300
Message-ID: <019301d5490f$f8a57df0$e9f079d0$@smyslov.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0194_01D54929.1DF5C330"
X-Mailer: Microsoft Outlook 14.0
Content-Language: ru
Thread-Index: AQLgkaoOo1Vlc6htpCqkNtP2imU+oqTPzCfQ
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/gSxgf6Vyc7MEsSoMdhDO3gY3K8w>
Subject: Re: [Dots] draft-ietf-dots-discovery: Valery's Comment in Montreal
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: Fri, 02 Aug 2019 08:55:13 -0000

Hi Med,

 

Hi Valery, 

 

You said during the meeting that you are not "happy" with the language used in section 4 (if I'm not mistaken). Are you referring to
this text: 

 

   All DOTS clients MUST support at least one of the three mechanisms

   below to determine a DOTS server list.  All DOTS clients SHOULD

   implement all three, or as many as are practical for any specific

   device, of these ways to discover DOTS servers, in order to

   facilitate the deployment of DOTS in large scale environments:

 

Can you please clarify your concern? 

 

yes, I meant this very text, but it was just an example of my concerns.

in general, I found using normative language in the document 

a bit chaotic and I think that sometimes it is used improperly. Note, that

the main purpose of using normative keywords is to help interoperability.

 

 

More concretely.

 

   All DOTS clients MUST support at least one of the three mechanisms

   below to determine a DOTS server list.  All DOTS clients SHOULD

   implement all three, or as many as are practical for any specific

   device, of these ways to discover DOTS servers, in order to

   facilitate the deployment of DOTS in large scale environments:

 

Why normative language is ever used here? Obviously, clients

must somehow know server's address to establish a connection, 

but is it essential for interoperability between DOTS implementations

how they got it? I don't think so. Even if you persuade me that 

it is essential, I still think that the language is used here 

improperly, since SHOULD is almost equal to MUST and 

you doesn't provide any excuses for not doing MUST.

If you use SHOULD, please describe when it's OK not to follow it.

But I still think that normative language is not needed here.

 

Another point. I'd rather recommend always provide a means

for local/manual configuration, as it us the easiest and most reliable way 

to configure server's address. All other mechanisms may fail if attack

is already in progress when the client is being configured...

 

 

   On hosts with more than one interface or address family (IPv4/v6),

   the DOTS server discovery procedure has to be performed for each

   combination of interface and address family.  A client MAY choose to

   perform the discovery procedure only for a desired interface/address

   combination if the client does not wish to discover a DOTS server for

   all combinations of interface and address family.

 

The same question - why MAY is used here instead of "may"?

 

   The above procedure MUST also be followed by a DOTS gateway.

   Likewise, this procedure MUST be followed by a DOTS server in the

   context of DOTS Signal Channel Call Home

   [I-D.ietf-dots-signal-call-home].

 

    The discovery method MUST be reiterated upon the following events:

 

The same question for MUST.

 

 

   1.  A DNS domain name is retrieved for each combination of interface

       and address family.  A DOTS client has to determine the domain in

       which it is located relying on dynamic means such as DHCP

       (Section 5) . Implementations MAY allow the user to specify a

       default name that is used, if no specific name has been

       configured.

 

The same question about normative language - why MAY instead of "may"?

 

 

And apart from using normative language: doesn't the text

 

   If the DHCP client receives more than one instance of

   OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use

   only the first instance of that option.

 

contradicts to the previous one

 

   To return more than one DOTS agents to the requesting DHCPv6 client,

   the DHCPv6 server returns multiple instances of

   OPTION_V6_DOTS_ADDRESS.

 

In other words, why to return several instances if only the first is always used?

Am I missing something?

 

Regards,

Valery.

 

 

 

 

Thank you. 

 

Cheers,

Med