IETF Logo Mail Archive

[Dance] some thoughts/questions from IETF113 meeting (recording)

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 14 May 2022 06:21 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46393C14F72C for <dance@ietfa.amsl.com>; Fri, 13 May 2022 23:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.44
X-Spam-Level:
X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8ZvYo4n4FGL for <dance@ietfa.amsl.com>; Fri, 13 May 2022 23:21:07 -0700 (PDT)
Received: from relay.sandelman.ca (unknown [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C20CC14F72A for <dance@ietf.org>; Fri, 13 May 2022 23:21:06 -0700 (PDT)
Received: from dooku.sandelman.ca (port-212-202-221-10.static.as20676.net [212.202.221.10]) by relay.sandelman.ca (Postfix) with ESMTPS id CF23E1F480 for <dance@ietf.org>; Sat, 14 May 2022 06:21:02 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id ABDDC1A0460; Sat, 14 May 2022 02:21:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dance@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 14 May 2022 02:21:01 -0400
Message-ID: <207928.1652509261@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/In8E2n6zqWtk-IaMXRS-nWv0Q7M>
Subject: [Dance] some thoughts/questions from IETF113 meeting (recording)
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2022 06:21:08 -0000

Alas the conflict with LAMPS was a problem for me at IETF113.
I have finally watched the recording.

A question about slides-113-dance-dane-hackathon-results-00 slide 9, which is
about the Join Request/Join Accept.
This looks an awful lot like RFC9031 Constrained Join Protocol (CoJP), which
is presently PSK authenticated over OSCORE.  I think that slide 9 is
describing an existing LoraWAN protocol, but I'm unclear if that's the case,
and if so, I don't know what terms to plug into google to find out more about
it.

About the discussion about the use-case document.

I am in favour of earlier adoption of documents by WGs, and so I would
suggest that we do that.  Adopting a document, to me, means the WG wants to
work on it, not that it's ready for publication.
Nor even that the document will be published.
Also: what Barry said, and the WG did not object.  
I did not yet see an adoption call?

I'm fine with 1hr slot in the future, but I also suggest that a higher
cadence via monthly virtual interim meetings would be helpful.

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email