Re: [dnssd] Should DNSSD meet at IETF 120?

David Schinazi <dschinazi.ietf@gmail.com> Sat, 27 April 2024 00:53 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1164EC151557 for <dnssd@ietfa.amsl.com>; Fri, 26 Apr 2024 17:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 2avTASXbbrqY for <dnssd@ietfa.amsl.com>; Fri, 26 Apr 2024 17:53:02 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 8EC1DC14F726 for <dnssd@ietf.org>; Fri, 26 Apr 2024 17:53:02 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a58d0aea14cso155982566b.2 for <dnssd@ietf.org>; Fri, 26 Apr 2024 17:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714179180; x=1714783980; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ioBU7g3xVPF1QBgiONLZSzHU6/JFTxEM7sCI2fi/Tkc=; b=dQ0m0T+pkM7WJl0W8nwPIxBr4nWxli3BMUqM4WfB5VaTlBixyYUYAeFC8QnMpc3Evr S2IDE3Rmqu2zr/OPxSDPO2DdNwnrL8sYblljJ6ozzzeEuWuHAM+ZanUtOc44LeV95gxX TcbvleoeaBK8EWsKDCXwOe1FB6UGRUZSOCOkp14R7W3gZxbp1gDlH+e2169pbomJowR1 KFD0GuagVQPbpjWxgGLN9Tw8dsIRbfbhtl7ji1uXoBWpWaxOX+lS67EGmd/sewIFrjRx b3Vrn4EOFfCEEaVRtXrVDxPze6FGnWeA1jIoAQKiAciBGYadq1bzs0icAGhXWBsjyy1x QPtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714179180; x=1714783980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ioBU7g3xVPF1QBgiONLZSzHU6/JFTxEM7sCI2fi/Tkc=; b=UQt+aNCiaU9uM7c9/Zap6jM7BT6gFt6oWJJXqPgAXHZDCM31qo3bG2nPnOwL+oYDq/ 4zl9MtPJP/HbVzaNBuGQx0lft3ek8yQcWlqAREXmj+G6wYNVR8SYz44sRQSmAv1owWXA AYZLrYdzJ+GAVEaFD1CdVtiQJDRD5AKg08/qzog1N6xM0dVpDb7F/rJsHa26mDoseoro ErC1+dHZ9esDq49jLlBSLT71bNy1y5ZIasRC3N8znLA5JdHJ3I+XjHhJJGajcBbgDRFL e5p7XSSFRMSCFDay/J8QPV3bRBWDA3Wuvc4vHLcHNXhGFRTtNZ390il/bH3V+xwXGjIW Tw3g==
X-Gm-Message-State: AOJu0Yz3jgLOeya6Z+6ti/GFgPiyohXUYTm7JPS5b02/0LDipa5Dpx9q azXKSY9iHGryvV0wCvKF3DAJ5yO0GQt4DSom4MKPw7WoFvs8fx8LdveBF5FSAq8yGsYY4Dn/Rvv CcsKibT+pVH/nR5SC3SbhlggtuxQ=
X-Google-Smtp-Source: AGHT+IGVUXHfRe0FKxI0V42GGT8luooPaPnPTpnT8nXBHbSk5kjMPIb3z3Fzzkvo4qNH1qRFc0s9hSM8Gd4pNXxoxKY=
X-Received: by 2002:a17:906:2549:b0:a58:7249:25df with SMTP id j9-20020a170906254900b00a58724925dfmr2796186ejb.49.1714179180204; Fri, 26 Apr 2024 17:53:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAPDSy+7gZpCm=jXizvKwx9Lm_dB+7fb1OMyWmyL89TiYoEdCjg@mail.gmail.com> <CAPt1N1mJ7SLXab4zzC5Ngm98bp-g8fksK_hCRJLkA-pSuzbaQA@mail.gmail.com> <CAPDSy+7N1=g6j-hTt8YO7vSpkZ0UE+X_dMA5j+QmfphbFoFsJQ@mail.gmail.com> <CAPt1N1=-akjFKdnW9Gw+77q9d+2SOE6R+tgXfxpNDjmmLne_+g@mail.gmail.com>
In-Reply-To: <CAPt1N1=-akjFKdnW9Gw+77q9d+2SOE6R+tgXfxpNDjmmLne_+g@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 26 Apr 2024 17:52:48 -0700
Message-ID: <CAPDSy+7VSvLCr_W8FZT762=1-s6mXy_64F2Pztm1N-hgKmFYdg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: DNSSD <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001e1ab1061709713c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/fAPgpoiU4Og26gFzsS6oDYRnOtc>
Subject: Re: [dnssd] Should DNSSD meet at IETF 120?
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2024 00:53:05 -0000

On Fri, Apr 26, 2024 at 3:44 PM Ted Lemon <mellon@fugue.com> wrote:

> Fifteen minutes each with some slop in the schedule ought to be enough.
>

Thanks, that sounds good to me.

The problem with prioritizing working group documents is that what I work
> on is driven by what's causing problems. The challenge with e.g.
> Advertising Proxy, which is adopted, is that it's working as it is, and so
> I haven't had time to actually implement the new proposal because it's not
> urgent, so even though it's working group work it winds up getting short
> shrift. :(
>

I totally understand (and fully sympathize with the fact) that there are
only so many hours in the work day. That said, if we take your point to its
natural conclusion, we would never publish anything. Practically, all you
need to do to have a working multi-vendor system is put a protocol spec on
a website. The IETF datatracker gives you the added benefit of the note
well, in particular the IPR policy facilitates adoption of the spec by
other companies and SDOs. But at that point, we don't really need an IETF
working group, we could just create a matter@ietf.org mailing list, discuss
individual drafts there and never publish them. I really do get it,
publishing documents is a lot of work. But if the output of the WG isn't
going back into products, why are we spending the energy?

Hopefully you'll excuse my odd use of the Premack principle here. If the
chairs don't apply some level of pressure to actually finish documents, I
worry we'll end up with a pile of half-finished drafts when you get
reassigned to the next hard engineering problem. For what it's worth, the
best solution we've devised is finding co-authors to help you carry the
document over the finish line. But, as you point out, part of the work is
applying the document updates back into your implementation, and that's not
something we can easily help you with.

If you have ideas for how we can have the pressing conversations you
requested while still ensuring forward progress, I'd love to hear them. I'm
open to any other potential solution that still ensures we don't abandon
half-finished drafts because they work well enough.

David


On Fri, Apr 26, 2024 at 6:36 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Thanks Ted! Do you have a rough estimate of how much time you'd like for
>> each of these?
>> As usual, we'll focus meeting time on adopted items before considering
>> individual drafts or other topics.
>>
>> David
>>
>> On Fri, Apr 26, 2024 at 2:06 PM Ted Lemon <mellon@fugue.com> wrote:
>>
>>> I think so. We actually have at least four things I want to talk about:
>>>
>>> 1. A report/discussion on the EDNS(0) TSR update and implementation
>>> 2. A discussion about compressing SRP updates for constrained networks
>>> (has suddenly become topical)
>>> 3. DNS Push additional data update (has also suddenly become topical)
>>> 4. Updated Advertising Proxy document (stretch goal)
>>>
>>> A fifth topic that's sort of crossover between DNSSD and SNAC is
>>> automatic centralization of SRP/DNSSD on home/SOHO networks. This has
>>> become a hot topic for home routers and it would be nice if we had a way
>>> for home routers to announce that they can act as centralized DNSSD servers
>>> and for SNAC routers to take advantage of the centralized SRP/DNSSD
>>> service. This last bit is nothing new—it's on the SNAC charter—but I've had
>>> people asking me more urgently than had previously been the case to figure
>>> out how to do this, so...
>>>
>>> On Fri, Apr 26, 2024 at 4:50 PM David Schinazi <dschinazi.ietf@gmail.com>
>>> wrote:
>>>
>>>> Hi DNSSD enthusiasts,
>>>>
>>>> Planning for IETF 120 has started. The chairs are wondering whether
>>>> DNSSD should meet at IETF 120 in Vancouver this July. Please share requests
>>>> for agenda items (including expected durations) in response to this email.
>>>> If there are sufficient requests, we will schedule a session. The requested
>>>> length will also depend on the agenda requests we receive.
>>>>
>>>> Additionally, we would like to hear feedback about our session at IETF
>>>> 119 in Brisbane. As a reminder, we tried something new by having a joint
>>>> session with SNAC. We're interested in any thoughts you might have about
>>>> that experiment. In particular, is this something that we should consider
>>>> repeating?
>>>>
>>>> Thanks,
>>>> David
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> dnssd@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>
>>>