Re: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap

Martine Sophie Lenders <m.lenders@fu-berlin.de> Wed, 01 September 2021 13:38 UTC

Return-Path: <mlenders@zedat.fu-berlin.de>
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 7984D3A11EA for <core@ietfa.amsl.com>; Wed, 1 Sep 2021 06:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yt3lizQ4iiJE for <core@ietfa.amsl.com>; Wed, 1 Sep 2021 06:38:00 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 6C15E3A11E5 for <core@ietf.org>; Wed, 1 Sep 2021 06:38:00 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from <mlenders@zedat.fu-berlin.de>) id 1mLQRA-002eWr-TY; Wed, 01 Sep 2021 15:37:56 +0200
Received: from [5.61.188.191] (helo=[192.168.101.10]) by inpost2.zedat.fu-berlin.de (Exim 4.94) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from <m.lenders@fu-berlin.de>) id 1mLQRA-001khm-M9; Wed, 01 Sep 2021 15:37:56 +0200
To: Carsten Bormann <cabo@tzi.org>
Cc: "core@ietf.org" <core@ietf.org>
References: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de> <DD9BA64D-E265-47C7-A799-AB304A98F6C3@tzi.org>
From: Martine Sophie Lenders <m.lenders@fu-berlin.de>
Message-ID: <a1471849-f560-0429-e368-9b693b5db7a2@fu-berlin.de>
Date: Wed, 1 Sep 2021 15:37:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <DD9BA64D-E265-47C7-A799-AB304A98F6C3@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Original-Sender: m.lenders@fu-berlin.de
X-Originating-IP: 5.61.188.191
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/uTrnHAENASXNUAYUpcapySldDXQ>
Subject: Re: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap
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: Wed, 01 Sep 2021 13:38:06 -0000

Hi Carsten,

Am 01.09.21 um 15:19 schrieb Carsten Bormann:
> [...]
>
>> On 1. Sep 2021, at 13:52, Martine Sophie Lenders <m.lenders@fu-berlin.de> wrote:
>>
>>   (c) There is one concern regarding FETCH. Various CoAP implementations
>> do not support FETCH [4] (maybe because FETCH was added later to CoAP).
>> This could hinder deployment of DoC or could lead DoC implementations
>> that are not spec-compliant, because implementers just use GET or POST
>> when FETCH is not available.
> CoAP implementations that do not support FETCH need to be fixed.
> If applications were to wait until everyone has implemented FETCH, there never would be an application that uses FETCH, so there would be no need to implement it.
>
> Since implementing FETCH is near trivial if you already have implemented POST, maybe getting a list of CoAP implementations that still don’t do FETCH and generating fixes for them would be a good parallel activity to standardising DoC.

I came prepared [1] (but did not want to include this table initially to 
not overwhelm everyone with the info dump ;-))! Our preliminary 
judgement call was that there are for the most part 2 types of CoAP 
implementations that are in that state: (1) who have a stale development 
status anyways (last change >1 year ago) or (2) where it is not needed 
fort the use-case anyways (e.g. wakaama). Of the one remaining, I agree 
with your proposal to generate fixes for FETCH support down the line.

Best Regards,
Martine

> Grüße, Carsten
[1] https://gist.github.com/miri64/48d83316afd1d5e600ed2ec0bbab3624