Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[Tom Pusateri <[e-mail]>]

> On Mar 8, 2019, at 3:00 PM, 神明達哉 <[e-mail]> wrote:
> 
> At Mon, 4 Mar 2019 19:45:02 -0500,
> Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
> 
> > Thanks to the great feedback, we were able to update the document to
> > better match the preferences of the working group and address the
> > outstanding concerns.
> 
> > > A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt
> > > has been successfully submitted by Tom Pusateri and posted to the
> > > IETF repository.
> 
> I've read draft-pusateri-dnsop-update-timeout-02.  Personally, I'm not
> yet convinced that we need to provide this functionality in an
> "in-band" way (i.e., as a DNS resource record).  But I wouldn't
> be strongly opposed to it if the WG is willing to adopt it.  For now
> I'm just providing some technical comments on the draft content.

That feedback by itself is valuable. We need to make a better case for it. Most of the use cases relate to service discovery.

> - general: it's not clear to me when/how a TIMEOUT RR is added to a
>   zone?  Is it assumed that an update client includes it in its update
>   request?  Or is the primary server supposed to internally add/update
>   TIMEOUT(s) on handling update requests?  Or something else?  I think
>   the draft should explain it more clearly.

We list those ways but don’t specifically limit it.

Initially, if authoritative servers don’t yet manage TIMEOUT records, external applications could add and remove TIMEOUT records on behalf of the primary server.

Eventually, primary servers may want to manage them entirely internal and reject all outside interference. In this case, the lease update EDNS(0) option can be used to communicate the requested timeout value.

TIMEOUT records may also be included in the UPDATE message along with the records added as a hint to the primary server.

> 
> - Section 4
> 
>    If the expiry time is the same,
>    multiple records can be combined into a single TIMEOUT record with
>    the same owner name, class, and record type but this is NOT REQUIRED.
> 
>   'NOT REQUIRED' is not an RFC2119 keyword.  If this is not intended
>   to be a normative keyword, it's better to be lower-cased to avoid
>   confusion; if it's intended to be normative, a valid RFC2119 keyword
>   should be used.

Will fix.

> 
> - Section 4.1
> 
>    A 16-bit field containing the resource record type to which the
>    TIMEOUT record applies.  Multiple TIMEOUT records for the same owner
>    name, class, and represented type can exist.
> 
>   Is there any RR type that must not be specified here?  For example,
>   can TIMEOUT itself be specified?

We want to treat them like any other resource record so there are no special rules. Do you see any reason to limit it?

> 
> - Section 4.2
> 
>    If an additional TIMEOUT record exists with the same
>    owner name, class, and record type, it MUST be ignored and SHOULD be
>    removed.
> 
>   It's not clear to me exactly what "it MUST be ignored and SHOULD be
>   removed" means...perhaps it's also related to how TIMEOUT is added
>   to a zone.

Will fix.

> 
> - Section 4.3.2
> 
>    The record MUST be in canonical DNSSEC
>    form as described in Section 6 of [RFC4034].
> 
>   You might also want to state that the RDATA in TIMEOUT and the RDATA
>   of the actual RR that it covers must be compared in the canonical
>   form (i.e., some types of RRs have to be compared in the
>   case-insensitive manner).

Good point.

> 
> - Section 6
> 
>    A TIMEOUT resource record MUST be removed when the last resource
>    record it covers has been removed.
> 
>   This statement looks ambiguous about *who* removes the TIMEOUT.
>   According to the paragraph that follows I guess it's the primary
>   server implementation (rather than, e.g., a human administrator of
>   the server).  Perhaps it's better to use the active voice here, too:
> 
>     A primary server MUST remove a TIMEOUT resource record...
> 
> - Section 6/general: what should happen if an administrator manually
>   edit the zone file (and reload it to the primary server)?  Is it the
>   administrator's responsibility to adjust TIMEOUT accordingly, or is
>   the primary server implementation supposed to do it automatically?

Ok. I think we can make this more clear while still leaving a little wiggle room.

> 
> - Section 6
> 
>    As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of
>    the SOA for the zone is used as a lower bound of the TTL for all
>    records in the zone.
> 
>   This is deprecated by RFC2308.

Missed that. Thanks for pointing it out.

> 
> --
> JINMEI, Tatuya

Great feedback!

Thanks,
Tom