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

神明達哉 <> Fri, 08 March 2019 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A12F131429 for <>; Fri, 8 Mar 2019 12:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RkVp8r0VfDPT for <>; Fri, 8 Mar 2019 12:00:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BB80131445 for <>; Fri, 8 Mar 2019 12:00:52 -0800 (PST)
Received: by with SMTP id w2so22629914wrt.11 for <>; Fri, 08 Mar 2019 12:00:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=drgrJk6zscNZDF/vR2uGdvYqoKqf6hrs8t3Hna2x4ak=; b=IocYgzjGug8UgpV2hjkCaR8QM2IeLbsJH8nbwb80ZNwibhUdDEhHuSn7l2zyktVpFn B9hkyc8hn5yHhM2+k6yA1SY/uwza+3iZM2pL5Bg2h04mgEn8aPWky0nIhrvpNdn+Msmk 6E6XaE4u8FTRmomZJVkWM/n7IIy/CND1qgbmRJvsq2rJlpYTnAWYwNtnwaRPGAzva2aw msakVxOHqRq0rtqUtQ2CcSOZf25MRa3IDJnrQ7YgUGOal7wJlxBJje0Cj6KS0BvfSEEE 3ducG/YFcYWe11kLEJs264J+irALtoqju/efWbxBb0Ropb4dgBZo6RnpOLGEedqpBlXu yLGw==
X-Gm-Message-State: APjAAAXyCZ9kQo3rbSRqig/DtBZ5dD6uElcYKnMs1ulCZUMtiOoMMz9c YOD8u7DBl1CFlQ5E/6yu4jDtCzKVkCou/svSBgWfZtae
X-Google-Smtp-Source: APXvYqzI1J53xyXKzfgY7yy/ot7lS0lp3IrbvM6S6oKEplQmBkzXzyi3vMdRIOJtIEG0rXzwbrbCEZ8f7FZb5qYvp6s=
X-Received: by 2002:adf:f089:: with SMTP id n9mr6542076wro.313.1552075250136; Fri, 08 Mar 2019 12:00:50 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 8 Mar 2019 12:00:38 -0800
Message-ID: <>
To: Tom Pusateri <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000f2fb0805839aad75"
Archived-At: <>
Subject: Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Mar 2019 20:00:59 -0000

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

- 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

  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