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

From: Tom Pusateri <[email-masked]>
Date: Mon, 4 Mar 2019 19:45:02 -0500

DNSOP,

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.

To summarize the changes:

Add missing reference (Stuart Cheshire)
Modify presentation format of date/time to match RRSIG (Mark Andrews)
Remove HASH as a premature optimization and replace with actual RDATA (Ted Lemon)
Add more motivation for the need of the record (Joe Abley, Paul Wouters).
Allow multiple TIMEOUT records with the same owner name/class and simplify TIMEOUT record format to not include multiple expiry times (partly Tony Finch)

Note: going through the list, I realized that I missed the comment that we need to explain why individual records need cleaned up and not just the whole RRSet. We’ll open an issue for this and handle it in the next version.

Thanks,
Tom

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pusateri-dnsop-update-timeout-02.txt
> Date: March 4, 2019 at 7:26:58 PM EST
> To: "Tim Wattenberg" <[email-masked]>, "Tom Pusateri" <[email-masked]>
> 
> 
> 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.
> 
> Name:		draft-pusateri-dnsop-update-timeout
> Revision:	02
> Title:		DNS TIMEOUT Resource Record
> Document date:	2019-03-04
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:       https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-02
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records
>   with the same owner name, type, and class.  It is intended to be used
>   to transfer resource record lifetime state between a zone's primary
>   and secondary servers and to store lifetime state during server
>   software restarts.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Mar 2019 12:18:39 +0000

> Modify presentation format of date/time to match RRSIG (Mark Andrews)

I got some mail from github about this issue which was weirdly sent to
me personally rather than to the WG - see

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 5 Mar 2019 07:59:44 -0500

> On Mar 5, 2019, at 7:18 AM, Tony Finch <[email-masked]> wrote:
> 

Sorry if that freaked you out. I opened issues on github and included comments made on the mailing list to make sure we captured them correctly when the issue was resolved. I referenced participants github user names where applicable.

In your case this included:

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/27
https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24

I’ve already mentioned on the WG mailing list that the document is being edited here:

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout

and anyone is welcome to open issues if they like so I don’t think we need to replicate this info to the mailing list each time.

Thanks,
Tom

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Mar 2019 13:20:53 +0000

Tom Pusateri <[email-masked]> wrote:
>
> Sorry if that freaked you out.

I wasn't freaked out, I just thought the response was directed to the
wrong place. I didn't bring up the issue for a two-way discussion, I
wanted to see what other wg participants thought.

> and anyone is welcome to open issues if they like so I don’t think we
> need to replicate this info to the mailing list each time.

The wg mailing list is where group decisions are supposed to be taken.
I don't particularly want to have to poll another (counting the dnsop
drafts) 35 places to find out if maybe some discussion has happened.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole: South, veering northwest later, 6 to gale 8, perhaps severe
gale 9 later in Fitzroy. Rough or very rough, becoming high for a time in
southwest Fitzroy. Rain, then thundery showers. Moderate or poor, occasionally
good.

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 5 Mar 2019 08:32:09 -0500

> On Mar 5, 2019, at 8:20 AM, Tony Finch <[email-masked]> wrote:
> 

I agree with you on this. The issues are  for the authors and including the participants was a courtesy for them to be informed when the issue was resolved.

However, since you seem to object, I will discontinue this practice. 

Thanks,
Tom

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 Mar 2019 12:00:38 -0800

At Mon, 4 Mar 2019 19:45:02 -0500,
Tom Pusateri <[email-masked]> 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.

> > has been successfully submitted by Tom Pusateri and posted to the

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.

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

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

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

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

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

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

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

--
JINMEI, Tatuya

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 8 Mar 2019 16:36:48 -0500

> On Mar 8, 2019, at 3:00 PM, 神明達哉 <[email-masked]> wrote:
> 
> Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 

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

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

>   confusion; if it's intended to be normative, a valid RFC2119 keyword

Will fix.

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

>   removed" means...perhaps it's also related to how TIMEOUT is added

Will fix.

>   case-insensitive manner).

Good point.

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

>   This is deprecated by RFC2308.

Missed that. Thanks for pointing it out.

Great feedback!

Thanks,
Tom