IETF Logo Mail Archive

Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Thomas Fossati <tho.ietf@gmail.com> Thu, 02 April 2020 10:19 UTC

Return-Path: <tho.ietf@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76653A0F31 for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 03:19:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wqWkDPs_-AWU for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 03:19:49 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 641823A0F2E for <core@ietf.org>; Thu, 2 Apr 2020 03:19:49 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id o3so3066044ioh.2 for <core@ietf.org>; Thu, 02 Apr 2020 03:19:49 -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=AQvS/8EkJ7qyLSOPYUjBjunS6HhhZMbNLVLnMOTua+Q=; b=cNKTIQQyAxs5gJOxcAE4dG80UsGYUtIIUcBtxJxes49GXbmjaO3OPccY8ZoH1HJcQJ pV/C409sX8IuWNH7yDJ21AlfdMpktMOArDW9L9p+XVUnrquHWcSU/f8mclxQlFROVNsZ dALKrY6lYwEl1alh5mcmeT2Cvhpth8x1+5k/UWTuYuehpej4T9p59rIml15RyelF5mET BTtI3dwtYaQGDJvKRljCsc3ya6Fl4KJcFKex5l+CAc6NcLCC0n+yxlRQm0QrkE1xjKdg oWpnONBaqt/Gh7nb1mXBD6HFs1oT9eGUL4FsYEfd31ZLIeyiE0ZEkMp9EZ5b3gjCal+r 0Zaw==
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=AQvS/8EkJ7qyLSOPYUjBjunS6HhhZMbNLVLnMOTua+Q=; b=t0ZqUEVDjpICaVw1K70QfSWIsxfcbw6tPWjg6a9C04pau1GzXVUA7tqXPstnZfgDsS eFiMDqZGdHkFqWvtsb95a4YE9IyMakAKxUW9raeljGCaBcCqGktfhtHCarsVg5Pi3tBi aDzKw9f2pQxiRCwXcm02RNWT0/no3NMAv0MpG4i2mdjd0XKY9P0T2GpQmPLVK9iQmh/z rP5Hv/UXq8X8mKC/CsNKnidNbYG+2BU6athqlAnXoLduq6AFBdJ26TxapjKOaCo29PjG nYv3BF/rXXtyDoi1tzNw/JITpwa1A6NS6QHpksldDloLbUdxXu1TTflSleFjQ8hKlYa2 vhSA==
X-Gm-Message-State: AGi0PuYPxpuT0Ud+BA8rbO6gxxttyBVuvwyTyhgM3sMkWpNhj0tK3V83 9MIn57aOEOdz/pAAg40aAn9ooMv8Lt6mR0wGVY5sMef2evA=
X-Google-Smtp-Source: APiQypLAs/KNoZvJUFYhb37geDi1wyeifGCWsH0t/nFMUuXxFn8eF9yUshi1AGGfr63zdmKHMPX9ZxD3EiyGsUqHGqY=
X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr2087529iod.109.1585822788584; Thu, 02 Apr 2020 03:19:48 -0700 (PDT)
MIME-Version: 1.0
References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <AM5P190MB027536259A44102F7AB9E058FDC80@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Thu, 02 Apr 2020 11:19:37 +0100
Message-ID: <CAObGJnOJ1x9uw8E44+7GhPZVc32RGTCby4Yh1qvEPuEi1e1iyw@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Jim Schaad <ietf@augustcellars.com>, Klaus Hartke <hartke@projectcool.de>, "core@ietf.org" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CVBrQpeyL26SovYVcAfLujkr_38>
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 10:19:51 -0000

On Wed, Apr 1, 2020 at 9:19 AM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
> Because (to me) this is not fully compatible with the definitions of
> "endpoint" and messaging model in RFC 7252 that I quoted, it would be
> good to clarify this aspect more in draft-ietf-core-groupcomm-bis i.e.
> refine the RFC 7252 endpoint definitions for the multicast case and
> clarify the multicast messaging model.

+1

Ideally, this new "multicast CoAP endpoint" definition should also
include an explanation why source address and port of the unicast
response are irrelevant to the successful processing at the client.

If we can express that clearly I don't think we need "SHOULD keep the
same UDP port": an implementation is left with its own local choice.

As a bonus we could also have implementation (in which scenario port
translation is a useful technique) as well as operational considerations
(Achim's wireshark filtering argument).

My two cents,
cheers!

v2.23.0 | Report a Bug | By Email