IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: RFC8499-bis

fujiwara@jprs.co.jp Wed, 11 November 2020 04:49 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12073A0A3B for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2020 20:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhFacgM8Eu1Z for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2020 20:49:02 -0800 (PST)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A79F3A0A25 for <dnsop@ietf.org>; Tue, 10 Nov 2020 20:49:01 -0800 (PST)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id 0AB4msX3030145; Wed, 11 Nov 2020 13:48:55 +0900
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id BBABF6024FCD; Wed, 11 Nov 2020 13:48:53 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id A40CC6024D23; Wed, 11 Nov 2020 13:48:53 +0900 (JST)
Date: Wed, 11 Nov 2020 13:48:53 +0900
Message-Id: <20201111.134853.954368397002712101.fujiwara@jprs.co.jp>
To: dot@dotat.at
Cc: dnsop@ietf.org
From: fujiwara@jprs.co.jp
In-Reply-To: <alpine.DEB.2.20.2011101342180.32156@grey.csi.cam.ac.uk>
References: <alpine.DEB.2.20.2011101342180.32156@grey.csi.cam.ac.uk>
X-Mailer: Mew version 6.8 on Emacs 24.5
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1231-8.6.0.1013-25780.000
X-TM-AS-Result: No--5.899-5.0-31-10
X-imss-scan-details: No--5.899-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1231-8.6.1013-25780.000
X-TMASE-Result: 10--5.898600-10.000000
X-TMASE-MatchedRID: RowX92bJu8RCXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYEWm ZqYrA0q9CujquDdjAzYnCd//babdxcEUL31hpkkHL5ZTfuFZpeduIDhu3McX23phbZRDpaPyXa9 +3ZJzfMJRncgP0qeRrD6KDKqSBiRZOo+uTHchhPl7396uJNSvqgeCHewokHM/gkEp7tXGI0osgd kHScxUMUZ3vfo4WrWV5tPA3/kabXrlRxm3A2wKujl/1fD/GopdyJ1gFgOMhOnrpxhAaj4pfqRJi L+iL2tOC24oEZ6SpSkj80Za3RRg8Bm6T9T+6oGuAiUi1CdL45PR6wGWVsbnTlpfmJFomENPKY4/ poj6XZE=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fAopdUTnVS2mDF71eiGsRdu9zco>
Subject: Re: [DNSOP] Call for Adoption: RFC8499-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 04:49:05 -0000

> From: Tony Finch <dot@dotat.at>
> I recently noticed that the bailiwick-related definitions are wrong and
> muddled.
> 
> I have always understood in-bailiwick to mean that a nameserver name is a
> subdomain of its zone apex. That is, exactly the cases where glue is
> required by the DNS protocol. The term comes from the discussion of
> gluelessness at http://cr.yp.to/djbdns/notes.html - "RFC 1034 specifically
> requires glue for referrals to in-bailiwick DNS servers."
> 
> RFC 8499 seems to use "in-domain" for this situation

Yes.

Before RFC 8499, "in-bailiwick" had two meanings. 
    in-bailiwick to mean that a nameserver name is a subdomain of its zone apex.
 and 
    "in-domain" http://cr.yp.to/djbdns/notes.html

>, which is not a term
> I have seen anywhere else.

  Yes.
  I borrowed the words "in-domain" and "sibling" from
  draft-koch-dns-glue-clarifications.
  (submitted in 2010, draft only)

  There are no "in-bailiwick" and "out-of-bailiwick" definitions
  before RFC 7719.

  We need four types of glue names.
  In RFC 8499, "out-of-bailiwick", "in-bailiwick", "in-domain", "sibling".

  Please propose new names.

# And I missed a term related to domain name: Occluded Name [(RFC6936].

-- 
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>

v2.23.0 | Report a Bug | By Email