IETF Logo Mail Archive

Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-dtls-09: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 02 July 2020 00:20 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB23A1271; Wed, 1 Jul 2020 17:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 baXJpSekPKPX; Wed, 1 Jul 2020 17:19:59 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 B4E643A1270; Wed, 1 Jul 2020 17:19:58 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id d64so5917113vke.4; Wed, 01 Jul 2020 17:19:58 -0700 (PDT)
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=4Aj07n9EgcefUcah08AXrASlXUMb2Vrjwx2nQoZTfRI=; b=IRRcnhWj+alO5SC2owBrugnXxQh/tQ+nU4wmlMjnGUN9UrZnjScOr303IbCPZpolvF S2B+x3KDc7KIcWIEfGAJVqelxweqaiVOT9VvWCTCMn5IA2z0M5joWfv9gxL9dfZX9ER1 IypkB3BP/EYz9mLnZuSYuDQgqYPdVZp4TCdQ9jJP4NG/aK5b8rdzlf9ekyL3i/tup/9+ 2tYAoLneJJrBI7wY+qGoFxYmyqAYNb2jE50SFTIG60p5gz0AUJLTCr4mcTYbQQLJWabI p+f6F+Mm49577jgWXHMBRLTInYt3T2SVHmSPxHQlsEglUC0V2YFnFUvCBYJ8f4hVsf2b C8zA==
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=4Aj07n9EgcefUcah08AXrASlXUMb2Vrjwx2nQoZTfRI=; b=i8e8hulMHy3Nk7nWp0/vgmr/JZ6yi8KjaA5IwQkXQEzbmSCENtFv+ietot60XibH5c Cz6lqYofvt94qnphSOaAh4bEHqAKMkNgHKSemS99+tIRH+x0ChHKpqoJ8p+EBaOeD7sg 9v+7krF/1qEcIbGzWnnHaJ0LvxrzPfRI51/4ZDiMbLNbGS2Pb0CMCM2Tp8DO3tE0ELPY adxRWNBQhoAjtGxYCmRwVwnwvubrtuQbe1bpPBnb2787w8/sIdd0gJI+dxrr67rhGgbl x4V593xafCVzL87Qn5h9QRwNlmHGiyvT2fMtsASulwOffHUwu7/5DCz5J/JYNU+J3b92 NuuA==
X-Gm-Message-State: AOAM533BnIVsDOvR0ZJ9tPpe/zGN7IInh2cmSMPL259qKwQqWJu1zJwf NggaY/EvRK6H4KP0xOp+gcMT+K6v11nMsiVa1IM=
X-Google-Smtp-Source: ABdhPJzhaukg27C2i5Cy782S/DuA4i8W7Lt0if03qH0Fu+VfCTCzdl/c1+t5Zlvo5MjmOP6KUdOJOlRhILBv/icD4cQ=
X-Received: by 2002:ac5:c76e:: with SMTP id c14mr21408077vkn.60.1593649197550; Wed, 01 Jul 2020 17:19:57 -0700 (PDT)
MIME-Version: 1.0
References: <159329532285.23961.12116288483331623753@ietfa.amsl.com> <CAPDSy+4YQ2-6asFxRwAKP2awMxSoKaC-d2gFzY=yH34k-CH=5g@mail.gmail.com>
In-Reply-To: <CAPDSy+4YQ2-6asFxRwAKP2awMxSoKaC-d2gFzY=yH34k-CH=5g@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 01 Jul 2020 17:19:45 -0700
Message-ID: <CAL0qLwaY7B2Loee+yRUhz+xudz-Jqh1gdGrQgn47r3jdS8x33A@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-babel-dtls@ietf.org, babel-chairs <babel-chairs@ietf.org>, Babel at IETF <babel@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000511cee05a96a5e35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/40QR50q3_kjFTP9Vg2YUbdY4dNM>
Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-dtls-09: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2020 00:20:00 -0000

On Tue, Jun 30, 2020 at 4:01 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

>
>
>
>> * "Nodes SHOULD drop packets that have been reordered ..." -- Why would an
>> implementer not do this?  (i.e., why is it only a SHOULD?)
>>
>
> Tracking reordering like this is not a feature that is available in all
> DTLS stacks.
> Requiring Babel implementors to add features to DTLS stacks is not a
> realistic
> possibility, so we made this a SHOULD.
>

I would suggest mentioning this.  SHOULD leaves some interoperability
discretion to the reader, and I think it helps to provide guidance around
that discretion especially when you have a specific alternative in mind.


>>
>> Section 2.5:
>>
>> * Why is the stuff in the first paragraph only SHOULD/RECOMMENDED?  (The
>> answer
>> may lie in the second paragraph, but I'm uncertain.)
>>
>
> Because it's not required for the correctness or security of the protocol.
> For example,
> we do not need to mandate where implementors save their DTLS state.
>

Given the words of Section 6 of RFC 2119, I suggest you don't need to use
these key words here if that's the reason.

-MSK

v2.23.0 | Report a Bug | By Email