Re: [dnssd] draft-sekar-dns-ul

Ted,

As promised in the meeting, I've now reviewed the draft. Here's my thoughts.

*Questions and comments*
The -01 version of this draft has an associated patent. The IPR disclosure
is https://datatracker.ietf.org/ipr/1236/. What does this mean for -03?

In Section 4, it strikes me as odd that KEY RRtype is treated specially
here. I know why, because that's what SRP needs. But in the context of this
single draft, is there a rationale as to why KEY, and only KEY, needs a
different lease time?

Is it worth looking at the draft through the lens of the EDM program? For
example should it be extensible to separate out other RRtypes? Should
greasing come into the picture? The answer might be "not in this case", but
I thought it worth at least thinking about.

Either section 4 or 5 should be explicit about what the client
MUST/SHOULD/MAY do when the server insists on a different lease period to
the one the client requested. It is not currently clear to me if the server
is always right, or if the client can impose bounds on what is acceptable.

In Section 5.2, refresh messages are asked to set a prerequisite of "RRSet
exists (value dependent)". I don't have much experience of prerequisites.
It sounds like it creates a risk that in some situations the prerequisite
will be unsatisified, resulting in the failure to refresh and the record
ultimately being deleted on expiry. Is this a genuine risk or am I missing
something?

Section 5.3 would benefit from adding a sentence along the lines of  "If at
least one record in the Refresh Request has completed at least 50% of its
lease, the server SHOULD refresh all of the records.".This is because
implementors might misinterpret "If no records", as "If any records ",
creating problems with coalescing.

In Section 7, do we need to ask IANA to update the status of Option Code 2
from on-hold to standard?

*Editorial suggestions*

Section 4
Personally I would drop the part in brackets here:
Leases are expected to be sufficiently long as to make timer discrepancies
(due to transmission latency, etc.) between a client and server negligible.

Section 5
Don't we normally use the spelling "retry" rather than "re-try"?

That's all. Overall it's clearly a useful capability, so I would support
eventual publication.

Chris

On Wed, 28 Jul 2021 at 00:01, Ted Lemon <mellon@fugue.com> wrote:

> As was discussed in the meeting today,  one of the normative references
> in the Service Registration Protocol document is to draft-sekar-dns-ul,
> which describes the DNS Update Lease option. For those who are challenged
> by parsing this, as I tend to be, that's the EDNS0 option for declaring a
> lease on a DNS Update.
>
> There was some question as to whether this was an appropriate document for
> the working group, so that's one question. However, whether it is or not,
> it would be good if it got some review, and this working group probably has
> a lot of the most qualified people to look at it.
>
> So, please take a look at the document and comment here. You can find a
> copy of the document here:
> https://www.ietf.org/archive/id/draft-sekar-dns-ul-03.html
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>