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

"Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> Mon, 10 May 2021 20:35 UTC

Return-Path: <Ronald.intVelt@tno.nl>
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 1F17D3A2A2E for <manet@ietfa.amsl.com>; Mon, 10 May 2021 13:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tno.nl
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 LSbslCt17c7z for <manet@ietfa.amsl.com>; Mon, 10 May 2021 13:35:51 -0700 (PDT)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (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 269F43A2A2B for <manet@ietf.org>; Mon, 10 May 2021 13:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tno.nl; l=18024; s=mta1; t=1620678951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IKmP+GJ3zSF3V1rBu7WK2dL0fUYE1r2BfAOhD43sN08=; b=KebR3ero+buadSzpQmsJ/eZ1k6Z4l33rJkOVncUTK4H/DfIZw5eSkQ7O H5CcKPXo0aM1YumCrR9fIh5oxb99bITx9s4TC64npWSGoxhiMAmbkwtaC FNbJ7cwlI/tAqLUaiNb5Lzmouuf2xQ2UznjDSIEXMdEiqrBkK2eH8HwZ+ c=;
IronPort-SDR: IWGBuQdHzH4nfNi2qVBcKuzNMuacQXzaxk64+rE71nKLl9tLExCth8OFUk64m3BNtKSaU/IPgT hqU5HQG2lf5btLfh1xsu9griUcP6DJYhFRnkV/PR/yQV/04ouq6QDOBR4qTE1/8EHJvDIj+jhk KKYuqJeIkKjxx2IL5O+JWKrS2hEuVt2nsv7cSEBKPbYsL4Y1ivK1N3Cpcfd+J8zmWQzbUzncnP yTF7ZNrU9gRTCMr6vklhVfpK1X7KNcohWJh+hEEV94jtAUy+Owq2fHmIdLo8pAKhx9BKaQKCMC MvgkdeoEE2/xRqgY9Vi2VNcm
X-IronPort-AV: E=Sophos; i="5.82,288,1613430000"; d="scan'208,217"; a="28716882"
Received: from UCP13.tsn.tno.nl (134.221.225.173) by UCP14.tsn.tno.nl (134.221.225.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 10 May 2021 22:35:45 +0200
Received: from UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298]) by UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298%7]) with mapi id 15.01.2176.012; Mon, 10 May 2021 22:35:45 +0200
From: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl>
To: Alvaro Retana <aretana.ietf@gmail.com>, Rick Taylor <rick@tropicalstormsoftware.com>, "sjury@cisco.com" <sjury@cisco.com>
CC: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC8175 (6472)
Thread-Index: AQHXFcbydCVWoJUdpUeMYk+C4vu01Kp9Ue6AgB3s7wCAQgDXgIAALxUw
Date: Mon, 10 May 2021 20:35:45 +0000
Message-ID: <ae01b7e1925a4bf8981d6db8de4a1f0a@tno.nl>
References: <20210310160318.0D463F40762@rfc-editor.org> <38A5475DE83986499AEACD2CFAFC3F9801F5A43C5F@tss-server1.home.tropicalstormsoftware.com> <CAMMESswrxmVZnUfxJNvutRfbesnQHp6kLmC=8+DN2LpjyqFw2g@mail.gmail.com> <CAMMESsxTOegOpmuah9cdXaASRTX6t6PhC-Hi8C3Q8dPkDAnT8w@mail.gmail.com>
In-Reply-To: <CAMMESsxTOegOpmuah9cdXaASRTX6t6PhC-Hi8C3Q8dPkDAnT8w@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.221.225.191]
x-esetresult: clean, is OK
x-esetid: 37303A296F91A666617467
Content-Type: multipart/alternative; boundary="_000_ae01b7e1925a4bf8981d6db8de4a1f0atnonl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/AjwTYOn7ar2to9eSV2A39VkSEsY>
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 20:35:57 -0000

Hi,

I forwarded the message below to Henning Rogge in order to get one more datapoint on the question what current implementations do. (Maybe we should ask David Wiggins as well).

With respect to the text correction, I can see the issue with the double MUST. However, in the proposed alternative, there is no MUST at all, just a SHOULD (and a lower case ‘should’). Somehow, that does not seem entirely right to me. So far, I have not been able to come up with anything better, though. I’ll think about it some more. BTW, what about the phrasing of “If the Modem is not including IPv4 and IPv6 Connection Point Data Items …”; shouldn’t that read: “If the Modem is including neither an IPv4 Connection Point Data Item nor an IPv6 Connection Point Data Item …”? What if the Modem is including just a IPv6 Connection Point Data Item, but the Peer Discovery Signal was sent over IPv4 (or vice versa)? Should we elaborate here to stave off future errata?

Regards,
Ronald

From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <rick@tropicalstormsoftware.com>; Velt, R. (Ronald) in 't <Ronald.intVelt@tno.nl>; sjury@cisco.com
Cc: manet@ietf.org
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Ping!


On March 29, 2021 at 2:04:35 PM, Alvaro Retana (aretana.ietf@gmail.com<mailto: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.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.