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

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Aug 2021 06:40:25 -0700

Thanks for the thorough review, Chris!

On Thu, Jul 29, 2021 at 8:04 PM, Chris Box <[email-masked]> wrote:

> *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?
>

The IPR has been around since <2009, so I'd say it's there to stay. You can
look at the IPR declaration for Apple's position on what to do if it gets
used in an RFC. Before I worked at Apple, I would have considered this
declaration Mostly Harmless, but since I'm now working at Apple, I think it
doesn't make sense to count my opinion since I'm not disinterested, so the
WG needs to make that call.

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?
>

The reason for the KEY having a different lease time is so that the domain
name can be claimed without being usable for service discovery. When the
other records expire, the KEY remains to hold the name until it expires, so
if the host renews before then, no other host can claim the name. We could
do this for some other record, but the KEY record has the virtue that it's
useful for authentication. It's true that this is currently only used by
SRP, though. We could make this apply to more records, but I don't know of
a use case for that, and if we come up with one later we can add another
EDNS0 option—the number space is not small.

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.
>

I have no idea what this means—can you elaborate?

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.
>

Good point. I think the server has to be in charge of this, but more text
about what that should look like would be good. E.g., in a constrained
environment, you might have devices that really only ought to check in
every day or even every week, and if the server limits leases to an hour,
that's not going to work out well.

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?
>

I'll have to discuss this with Stuart. My personal opinion is that less
prescriptive text is better, because we don't actually have a use case
other than SRP, and SRP already specifies constraints that contradict this.

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.
>

That sounds good.

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

Sounds like a good idea.

*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.
>

It's probably at least worth mentioning that issue, though.

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

That's a hyphenation thing, which apparently xml2rfcv3 doesn't support. I
think it should be taken out—text is no longer the canonical format, so
hyphenation specifically to support that format probably doesn't add much
incremental value.

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

Thanks!

On Thu, Jul 29, 2021 at 8:04 PM, Chris Box <[email-masked]> wrote:

> 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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>

---

From: Chris Box <[email-masked]>
Date: Wed, 4 Aug 2021 18:42:41 +0100

Ted,

Just picking up on some of the key points.

> EDNS0 option—the number space is not small.

Understood. I don't have a strong opinion; it's one for the working group
to ponder (along with the IPR).

> I have no idea what this means—can you elaborate?

This is
https://www.iab.org/activities/programs/evolvability-deployability-maintainability-edm-program/
.

I was particularly thinking of the "E" part:

Evolvability: Encourage protocols to design for extensibility and greasing,
and promote the use of extension points to prevent ossification. Make it
easy for people, especially those who aren’t steeped in IETF process, to
know which extension points are the right ones to use for a given protocol
(and which ones should be considered more stable/ossified), and make sure
there aren’t high allocation barriers to use those extension points.

This draft elaborates:
https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-01

Chris

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2021 13:16:39 -0700

Ah, okay. Thanks! I think we are covered: the availability of additional
edns0 options addresses the requirement stated in the iab document.

On Wed, Aug 4 2021 at 13:42, Chris Box <[email-masked]> wrote:

>> The reason for the KEY having a different lease time is so that the
>> domain name can be claimed without being usable for service discovery. When
>> the other records expire, the KEY remains to hold the name until it
>> expires, so if the host renews before then, no other host can claim the
>> name. We could do this for some other record, but the KEY record has the
>> virtue that it's useful for authentication. It's true that this is
>> currently only used by SRP, though. We could make this apply to more
>> records, but I don't know of a use case for that, and if we come up with
>> one later we can add another EDNS0 option—the number space is not small.
>>
>
> Evolvability: Encourage protocols to design for extensibility and
> greasing, and promote the use of extension points to prevent ossification.
> Make it easy for people, especially those who aren’t steeped in IETF
> process, to know which extension points are the right ones to use for a
> given protocol (and which ones should be considered more stable/ossified),
> and make sure there aren’t high allocation barriers to use those extension
> points.
>
>
> This draft elaborates:

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 23 Aug 2021 20:04:18 +0200

On Tue, 2021-07-27 at 23:01 +0000, Ted Lemon wrote:
> 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

Section 3 says:

> Encoding the Update Lease Lifetime in an OPT RR requires minimal
modification to a name server's front-end, and will cause servers that
do not implement this extension to automatically return a descriptive
error (NOTIMPL).

In queries and responses, servers normally ignore options they do not
recognise, so I suspect this sentence is wrong. The fix seems simple,
though - a client checks for the option in the response, and if it's
not there, the client knows that a lease limit has not been applied.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/