Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 25 July 2023 13:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6044C14CE52 for <anima@ietfa.amsl.com>; Tue, 25 Jul 2023 06:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 KOLT2eYZ4b7v for <anima@ietfa.amsl.com>; Tue, 25 Jul 2023 06:07:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 C0E73C14CE2B for <anima@ietf.org>; Tue, 25 Jul 2023 06:07:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A79738993; Tue, 25 Jul 2023 09:07:22 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OaeWNDzhH_kg; Tue, 25 Jul 2023 09:07:21 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:40a:34ff:fe10:f571]) by tuna.sandelman.ca (Postfix) with ESMTP id 492E238991; Tue, 25 Jul 2023 09:07:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1690290441; bh=VsuFyeiIMpSAZeXvbRyeuiPMxYxMA1YxAkS5OS3YYRM=; h=From:To:Subject:In-Reply-To:References:Date:From; b=rNsqVC+tAgrt/fnAvRkmsMJgX7zq+rV1NmdhtouEbfSx8ykDK1fgkhJpVSkTBpb3Q 6X8riU/4g/A9dicFmAcyjJEmnrMkkSf85Cx35PaOrmMrrBgVHZmkl+qsOK+VgkhItU +mRnFGgth6Ovdxv4L5NRfOQiaFngPQZyaQnNInAz+r0042Uf8Nxwx8P1sompPbYa6T CiKoo+iZq4xOSWMPVDS5J/j2P43C+PdGIPmkKbeoIxNvUXPKxxWap3InA4c4ph+keE 1rBDoo6vH4bTxa3SXmDjP7FaWyvIhSHVTDDv2vudVJ254GXQWHMWHgxMdswZ9C39eS cAV1R9TzZC6Ww==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 195B9479; Tue, 25 Jul 2023 09:07:21 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <6c2888e7-a2bd-b5ba-2aea-04dc26e95173@gmail.com>
References: <DB9PR10MB63549176EF0E405161B85649F33BA@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <1808d3ce-c03a-6871-a208-0845ad691427@gmail.com> <4024.1689630438@localhost> <DB9PR10MB63543A608EA0141A9860F65EF302A@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <6c2888e7-a2bd-b5ba-2aea-04dc26e95173@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 25 Jul 2023 09:07:21 -0400
Message-ID: <2512.1690290441@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/6YHCYlEIXAD9M8jnUvDZz2LNMvw>
Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2023 13:07:29 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > Yes, but you can map them in CBOR just as
    > draft-eckert-anima-grasp-dnssd already describes. (Think JSON but code
    > CBOR.) My only real concern is how to extend the objective for the
    > AN_join_registrar. It seems lame to use plain text when a JSON-style
    > map would be much nicer for the programmer. My prototype code for
    > grasp-dnssd has to parse DNS records to change them into Python
    > maps. But once that's done, sending or receiving them as CBOR is
    > trivial.

so far we are sending multiple objective values:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-join-proxy-14.html#name-grasp-discovery
and
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.html#name-grasp-discovery

   [M_FLOOD, 51840231, h'fda379a6f6ee00000200000064000001', 180000,
   [["AN_join_registrar", 4, 255, ""],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443],
    ["AN_join_registrar", 4, 255, "BRSKI_JP"],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5684],
    ["AN_join_registrar", 4, 255, "BRSKI_RJP"],
    [O_IPv6_LOCATOR,
    h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

I have resisted suggestions that we put an array for the objective-value, and
also that it have a string that needs to be parsed like "mode=prm,foo=1,bar=2"...
This is because I think that the protocol and port numbers, and maybe even
the IP addresses will be different.
(IP addresses could change not because different machines, but because in
IPv6, why not, and it also makes use of containers easier)

I regret we didn't write "BRSKI_EST" on the first one.
I am asking now if we should have a registry for this.
It could be RFC Required, as at this point, everything is in WG documents.
Since we are doing this in std track documents (so they get the ultimate
considerations, of IESG action, in effect), the value of the registry is that
it lets people find the document that goes with the value.

If we do want a registry, it needs to go into one of the two above documents,
I think.   I don't want to drag this on longer than it needs to be, because
these documents have taken too long already.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide