[dnssd] Paul Wouters' Discuss on draft-ietf-dnssd-update-lease-08: (with DISCUSS and COMMENT)

Paul Wouters via Datatracker <noreply@ietf.org> Wed, 09 August 2023 16:47 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E736FC151988; Wed, 9 Aug 2023 09:47:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnssd-update-lease@ietf.org, dnssd-chairs@ietf.org, dnssd@ietf.org, chris.box.ietf@gmail.com, chris.box.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 11.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <169159964293.4845.11487620908544106396@ietfa.amsl.com>
Date: Wed, 09 Aug 2023 09:47:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Gp42x8a1nrzdc04-aLiFz5cxZNg>
Subject: [dnssd] Paul Wouters' Discuss on draft-ietf-dnssd-update-lease-08: (with DISCUSS and COMMENT)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 09 Aug 2023 16:47:23 -0000

Paul Wouters has entered the following ballot position for
draft-ietf-dnssd-update-lease-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I wonder why there is no method for a "leaving client" to cleanup and delete
its record. Eg a laptop's "lid down" event could be used to delete the records
it has a LEASE on. It could do this without any wire changes by requesting a
LEASE value of 0. It could even use a KEY_LEASE value of non-zero to still keep
a claim to the name but signal that it is currently not available. Is there a
reason this was left out of the draft? As the stated goal of the draft is a
more up to date DNS zone, this seems like a logical part of the solution to me.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

        The Update Lease option SHOULD specify a time interval that is no
        shorter than 1800 seconds (30 minutes). Requestors MAY specify a
        shorter lease if they anticipate that the records being updated
        will change sooner than 30 minutes.

I feel this section tries to impose a restriction that it immediately breaks.
As implementer there is nothing I can do with this section except ignore this
text.

There is also no way of deleting by setting an update with 0 seconds (as one
"SHOULD" not use < 3600).



        If the Update Lease of a resource record elapses without being
        refreshed, the server MUST NOT return the expired record in
        answers to queries. The server MAY delete the record from its
        database.

The meaning here is open to interpretation. If the record is in the "database",
one could assume it is also being served. And if the record must not be returned
why is there a MAY to keep it in a "database". I think the second sentence is better
just removed and left to implementations to handle.


NIT: [I-D.ietf-dnssd-srp]  is not pointing to the latest version