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

[Ted Lemon <[e-mail]>]

Thanks for the thorough review, Chris!

On Thu, Jul 29, 2021 at 8:04 PM, Chris Box <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>