Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Alvaro Retana <aretana.ietf@gmail.com> Mon, 29 March 2021 18:04 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE5A3A1CF2 for <manet@ietfa.amsl.com>; Mon, 29 Mar 2021 11:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 M_qBPAniyJk7 for <manet@ietfa.amsl.com>; Mon, 29 Mar 2021 11:04:38 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 A3E7A3A1CF1 for <manet@ietf.org>; Mon, 29 Mar 2021 11:04:38 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id u9so20840426ejj.7 for <manet@ietf.org>; Mon, 29 Mar 2021 11:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=eEH75bMbbdw7Uz/fsZomUgq8mdnIIatBaMgb8OZr8D0=; b=IJVB8rzJK7pKyOrD49vAzZ327j1xXv5oY52Ks2E4IGKJcn8FUVTU44Z5fxzFwbM2Sx vLGT2GXcJIZXjsBt2DUjx5MKeQMsqVr1BvfTxpPwrFmR95NTp9sHtyCw8USXadZUF5Ww Zch9NblZHxWga8WFERUxPFNdxCQGuSZtuRWeYPFLIu4cKha+td8dRK/K9sNFH1HgHboX 1Z8AdKSTf8MQT0Y7tpTKczlg5tnmehPBpQXR3fr/KaZ0dvuyUTpnSX7hPvUUq6uEJUpB QM9+LhWKIz84p3aAxxd3k2QkhW5C12l6X6/+GwLMKNx0UwY8ZNOdAoNdkDU2UwbQcggz 8KNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=eEH75bMbbdw7Uz/fsZomUgq8mdnIIatBaMgb8OZr8D0=; b=TFpoQDudk1qF3OcqPxtPW6ZCgSxT6yEJAKwxLmZF9CpXZVNhW5xx5WmgcIODc2Idkg hCVegpuDkgeBnAmnZOS3jQ3xHk9Nrt3qiHCcIDX8s6dblNpMyCXpPMiwYhk3S/MPYIKq 4P4NcymUUSvfW3hq/b/MkejJ+KoRCM9v/DJ3Suab/DcgljDRgZlU5u03DyFbTEIHDtW6 Akl/EbNdlyA4tsO558gurJhR/YnzQva2sAjH03Deng+gEGwhxmzq4nBGaoIVw5B2P4At ULHVmDwyEnkLsRXY4KO4G9GdKj+CZ8YoxFAFMiHrMB38CaN/t32rJzb+SxRVUKyqLT7R kuRw==
X-Gm-Message-State: AOAM532vl8vVz/gGQL0k/W+Ax6XxjUAVtQ8sPk0PXVyT8IeRlNlTxOck fIYdyO7KYsq0zSW6LAwt8/ZW3GFXx91UI5gGVuY=
X-Google-Smtp-Source: ABdhPJzAwhzY69vpU1yMGLuDz+KlqdpL+fHlwgPsnK7NXXMmbHZSsO0lOgLmAmj75wML5IDTox5tXGmCd42VBynUfyY=
X-Received: by 2002:a17:906:d554:: with SMTP id cr20mr30027547ejc.61.1617041075822; Mon, 29 Mar 2021 11:04:35 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Mar 2021 11:04:35 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801F5A43C5F@tss-server1.home.tropicalstormsoftware.com>
References: <20210310160318.0D463F40762@rfc-editor.org> <38A5475DE83986499AEACD2CFAFC3F9801F5A43C5F@tss-server1.home.tropicalstormsoftware.com>
MIME-Version: 1.0
Date: Mon, 29 Mar 2021 11:04:34 -0700
Message-ID: <CAMMESswrxmVZnUfxJNvutRfbesnQHp6kLmC=8+DN2LpjyqFw2g@mail.gmail.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>, "sjury@cisco.com" <sjury@cisco.com>, "ronald.intvelt@tno.nl" <ronald.intvelt@tno.nl>
Cc: "manet@ietf.org" <manet@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/2S_hQ3RLGdEeGtQno9765fu4Aac>
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 18:04:40 -0000

[- Rick’s additional address, RFC Editor, other ADs.]


On March 10, 2021 at 11:05:03 AM, Rick Taylor wrote:


Hi!

I'm processing this report...but I have a question.  What do current
implementations do?  See move below.


...
> > Section: 12.4, para 2
> >
> > Original Text
> > -------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. The IP source
> > and destination fields in the packet MUST be set by swapping the values
> > received in the Peer Discovery Signal. The Peer Offer Signal completes the
> > discovery process; see Section 7.1.
> >
> > Corrected Text
> > --------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. If the Modem is
> > not including IPv4 and IPv6 Connection Point Data Items in the Peer Offer
> > Signal, then the IP source field in the packet MUST be set to the unicast
> > address the router must use when connecting the DLEP TCP session,
> > otherwise any valid local address MUST be used. The IP destination field
> > in the packet MUST be set to the IP source field value received in the
> > Peer Discovery Signal. The Peer Offer Signal completes the discovery
> > process; see Section 7.1.
> >
> > Notes
> > -----
> > The original text will not result in a valid unicast IP packet.


The new text is this:

   If the Modem is not including IPv4 and IPv6 Connection Point Data Items in
   the Peer Offer Signal, then the IP source field in the packet MUST be set
   to the unicast address the router must use when connecting the DLEP TCP
   session, otherwise any valid local address MUST be used.

I am having an issue with the double MUST.  Regardless of whether a
Connection Point Data Item is present, why wouldn't it be required (or
at least recommended) to always use the TCP-related IP address?

Proposal (to replace the new text)>
   The source IP address SHOULD be the address the peer should use when
   connecting the DLEP TCP session.  If a Connection Point Data Item is
   included, any valid local address MAY be used instead.


??

Thanks!

Alvaro.