Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

Jonathan Hui <jonhui@google.com> Sat, 19 December 2020 16:06 UTC

Return-Path: <jonhui@google.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 C10D23A0AE5 for <dnssd@ietfa.amsl.com>; Sat, 19 Dec 2020 08:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PCZidFY9Agf2 for <dnssd@ietfa.amsl.com>; Sat, 19 Dec 2020 08:05:58 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 073F03A0AE1 for <dnssd@ietf.org>; Sat, 19 Dec 2020 08:05:58 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id q25so4920376otn.10 for <dnssd@ietf.org>; Sat, 19 Dec 2020 08:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZPyashs4Q0dHh+kqQFai2gSFowDA/OX4Pc/jQlvNJlE=; b=k6QdgI2icvwnIpewdsVaLbT/tFxcKciRfOKaweLR8uITIywNRhJ9cM9yqenuw5X0Uj rTjn6+dgWFS9T5lU5pQWr2BnUlIYbXqky7RTkr3IzgEw91CIqH9Jo7lqMWme3WzTFlh5 QoFFywbylwq8D8QdWMBIzChaKS/wTKBLmfcCWl1s1dyJzV8VKlKSiYnCB9f/+PCT3sRD S2BlRE1RZNyLHoN11Oorwp+tzIc6z5OrNfPvfFUgKS/LwQ5WPTp9cVI8lpcc3Yj7+xgh Uqj9Hfu+chW7SJ4NDgRXOCy+TTKjjBDq+y01Bb3XVRiswZpZcS59BVDqJ9FUCikM8ADr GLTg==
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=ZPyashs4Q0dHh+kqQFai2gSFowDA/OX4Pc/jQlvNJlE=; b=miSkM8GlKm8UWVaWIz5rN+BZIwq0JOk3o2k0ar6b6QLkR3HcbQCx5xnT4//ydvDeN8 GEJ/OR3/bhbrQ9QV1Lx9l0o1Izb52z1TLGWthzhiB0ppzN5TbfuuaydnJAYkgKvgyOG/ mXqdKwp+PvMDPnfTv/98roIQ9d40C5kl1ddFOFJ9drwJAJaGuB/1zzRReeWM4InKwlKn tEYhjGfk5SHqvDOX5mjA77wXjLAlED1FIHiyTKILwPuGcQDL3n2Aq+2+ZiS7BxJiiIkY +6cFBjf5mVuCg5CZ5oKQrVeEJ+/3K6DF+Ce4EiVvtq743AvNsr7D17CfCa7lMIopZbfC EtJw==
X-Gm-Message-State: AOAM530u23CWatJTGNcOY956jhuULmJoMXHZeDYNn82azGkiANDN1WnW fiqavBdXwETZ56ms5+0LKDlyiBorM66nSLu9H4eIxQ==
X-Google-Smtp-Source: ABdhPJy5kPICKP38m8ya//H4T1yZJYQ/EjrsZgOBw1fg9IN63F0BPrm13Q65vQ/daHQ90yKjRopRYjKhsoqrZLNIdiY=
X-Received: by 2002:a05:6830:204b:: with SMTP id f11mr6362969otp.372.1608393956990; Sat, 19 Dec 2020 08:05:56 -0800 (PST)
MIME-Version: 1.0
References: <CACce4dTbWCVwBityepJpb5FF4Rv43+DUev_0Ka+rVT9exZrJzA@mail.gmail.com> <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <CACce4dQZ708aaMdvmwhEurHDSdFAvLbzwpDWz=viig_2cX75Dw@mail.gmail.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <CAJ5Rr7bDSMv1uPDPXppG9e4OUEU7oriK9tVKD20=P3Kgb2q=0g@mail.gmail.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <CAJ5Rr7Yw33y2k=wo-ZXzFNP77=bucRcr2LxJxf+98e5oqK+fsw@mail.gmail.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <CACce4dToa2+FiYgzp5AvZjO7-UfHy5VSSZ4ED+PkHMVPBZTQAA@mail.gmail.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> <CAJ5Rr7ZmVWRp8H1Kg2QVXFJKnrUK09J2iPHsVTDvSxFioAznUQ@mail.gmail.com> <CAJ5Rr7btf6iRnWWqVRhUAOHLotF3ntamNZt9MnACbPEOtXSGhQ@mail.gmail.com>
In-Reply-To: <CAJ5Rr7btf6iRnWWqVRhUAOHLotF3ntamNZt9MnACbPEOtXSGhQ@mail.gmail.com>
From: Jonathan Hui <jonhui@google.com>
Date: Sat, 19 Dec 2020 08:05:46 -0800
Message-ID: <CAGwZUDsiK-gfXGPFepMuQdO_xvT44i1w4KtitkZAh6K+bAH7=A@mail.gmail.com>
To: Kangping Dong <wgtdkp@google.com>
Cc: Ted Lemon <mellon@fugue.com>, Abtin Keshavarzian <abtink@google.com>, DNSSD <dnssd@ietf.org>, Rongli Sun <rongli@google.com>
Content-Type: multipart/alternative; boundary="00000000000077810705b6d366a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/gGmei-dxYZgDKoGv4Cc9SrWq0WY>
Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Dec 2020 16:06:01 -0000

On Sat, Dec 19, 2020 at 7:34 AM Kangping Dong <wgtdkp@google.com> wrote:

>
> In section 2.3.1. Validation of Adds
> <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-validation-of-adds>,
> we have:
>
>  SRP Updates consist of a set of *instructions* that together add or
>> remove one or more services.
>
> Each instruction consists either of a single add, a single delete, or a
>> delete optionally followed by an add.
>
> When an instruction contains a delete and an add, the delete MUST precede
>> the add.
>
>
> What is the use case of the "single add"? To my understanding,  the
> "delete + add" pattern is
> for resetting the service to our current SRP update. So the "single add"
> pattern is for updating
> the existing service, for example, adding one more AAAA RR, right?
>
> I think, for most SRP clients, it will be more convenient for them to
> track all IP Addresses and
> always update with the whole IP addresses list rather than depending on
> this "update" model
> and register the addresses separately. The server, I think can also be
> simplified. Thoughts?
>
> Another issue with this sentence is that, the Service & Host Description
> Invalidation requires:
>
>> exactly one "Delete all RRsets from a name" RR,
>
> Seems disallowing the "single add" pattern?
>

I believe the "single add" refers to a given instruction in the SRP Update.
Section 2.3.1.1 Service Discovery Instruction allows exactly one "Add to an
RRSet".

Maybe the "Validation of Adds" section name should be updated given that
the draft now supports "remove-only" instructions?

--
Jonathan Hui