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

Alvaro Retana <aretana.ietf@gmail.com> Mon, 10 May 2021 18:00 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 E128A3A2586 for <manet@ietfa.amsl.com>; Mon, 10 May 2021 11:00:56 -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, HTML_MESSAGE=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 IX-M8IpU1sqZ for <manet@ietfa.amsl.com>; Mon, 10 May 2021 11:00:52 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 AB2503A2584 for <manet@ietf.org>; Mon, 10 May 2021 11:00:51 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id y26so19764215eds.4 for <manet@ietf.org>; Mon, 10 May 2021 11:00:51 -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; bh=FmqredxaHR2xactTZC/bb5Y/fI44gaMPqvD22/ASt+k=; b=kayU2gVKd/I6kdgZTVUSa92IXPxQQ87vicsHV2gRzH6GzXPeTViPeXBvjWYijE31mN h7CsYzlODMC877cI9sKe35JX9qrGKSP7UQ8B1GFB8tgaFYEXs7uBBgcRaRjgKYhq86SU erQe81hYGtDQfLj7mGB/KzmA8vkquL3ONn8WpEZJijOFWl1fBl6SeFk9bYF2lppk/qBW G3zs9t4p167A3qH7EZktgyVEkH9kBFohkofuPi59ylbqtb769hgjVcjXjYE0W4c3Ha7F Tys15NbKkNTXVGY4B6iWjzwTWv4XKEYahqUJQPjFg/VSpLEUI0IDDiCdMoD3vrg7IR6Y 8Lvg==
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; bh=FmqredxaHR2xactTZC/bb5Y/fI44gaMPqvD22/ASt+k=; b=Xq9QKj3lMiEgMhsSQN57pRZDBIF4IpSNdKKcyr4wg7WmyBOy7xsvjNrYyWS6KbM3sq JjY6bcBRnWIZcl8/BJOlcKP4cWVjfcvcW6+/yOw7sZN8Vzfq51NzDDhBIxT7BRolRZpO UYK0vFJr85P612V4UH+tcfQYODShSeJ5//jbjTLOnCvmJXLvWnPlZ5nsUgJV9u8ffgAi uwt4oirol8hejx0dikI3imgweI4EGKY6M/6DhcKdAjckV8Teg/pEdsJIagfoSjFmlxTC WHcVA+xtQvCfm/L9U+xWrrt3pGeUd/Pt/XZOrA13auBZkA0SiQ9jk29OGJ4r+xTmK7Fc 2o9g==
X-Gm-Message-State: AOAM532QZ9J+DT1b/ajsaIEmfFNSfSD/VNJ4efk2lxOpVaSTE/wqCK+z RuKepzPvoL5H81djFkBm7AGmiSCYNiVRfDryn6o=
X-Google-Smtp-Source: ABdhPJzaA0albBJ6PYKeMmby+71b9fifD2v1pHWpItVsjJDxx9Nr1V+hvnvKqOmZN0/hTd32r8Pge86mH1FeJ08dR5I=
X-Received: by 2002:a50:9f8a:: with SMTP id c10mr31008495edf.65.1620669644861; Mon, 10 May 2021 11:00:44 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 10 May 2021 14:00:43 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESswrxmVZnUfxJNvutRfbesnQHp6kLmC=8+DN2LpjyqFw2g@mail.gmail.com>
References: <20210310160318.0D463F40762@rfc-editor.org> <38A5475DE83986499AEACD2CFAFC3F9801F5A43C5F@tss-server1.home.tropicalstormsoftware.com> <CAMMESswrxmVZnUfxJNvutRfbesnQHp6kLmC=8+DN2LpjyqFw2g@mail.gmail.com>
MIME-Version: 1.0
Date: Mon, 10 May 2021 14:00:43 -0400
Message-ID: <CAMMESsxTOegOpmuah9cdXaASRTX6t6PhC-Hi8C3Q8dPkDAnT8w@mail.gmail.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>, "ronald.intvelt@tno.nl" <ronald.intvelt@tno.nl>, "sjury@cisco.com" <sjury@cisco.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007af62205c1fd8ed4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/yzU9c6Xlx4fERfBg6pDW-kXA-Fs>
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, 10 May 2021 18:00:57 -0000

Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana (aretana.ietf@gmail.com)
wrote:

[- 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.