Re: [dnssd] feedback on draft-sekar-dns-ul-02

The reason the KEY-LEASE value is included in this option is that we know
now that we need it; the 4-byte version of the option is for backwards
compatibility.   If, in the future, we need more information, the solution
is to add another OPT RR option, not to extend this one.   Personally my
preference would be to make this 8 bytes all the time, and not have the
option of only sending 4 bytes.   If we were concerned at that time about
wasting space in the packet, the new OPT RR option could subsume the values
included in this option.   But I really don't think that's going to be an
issue.

On Thu, Jan 24, 2019 at 3:20 PM Tom Pusateri <pusateri@bangj.com> wrote:

> Since this is an individual contribution yet it is related to work going
> on here, I’m sending this to the WG. I expect this draft to get adopted by
> the working group in the future if this work continues.
>
> This version of Update Leases adds a new field to the UPDATE-LEASE option
> that provides a KEY lease in seconds. The length of the OPT is either 4 or
> 8 depending on if the KEY-LEASE is present.
>
> While I understand the need to solve a specific problem, I don’t think
> this format is general enough for future extensions. While the authors may
> not believe there is a need for future extensions, the addition of the
> KEY-LEASE is a counter example. Therefore, I think some method of
> determining which extra options are included is needed. If a future
> extension adds a new field but the KEY-LEASE is not included, it will be
> difficult to tell how to interpret the OPT value. In this case, a new OPT
> code will be needed. It is certainly possible to get a new OPT value in the
> future should a new extension arise but it seems wasteful to not just
> handle a slightly more general case at the time of writing.
>
> Thanks,
> Tom
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>