Re: [DNSOP] request for adoption

Bjørn Mork <> Tue, 13 November 2018 12:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32A1C129619 for <>; Tue, 13 Nov 2018 04:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C7WikBOXtyrR for <>; Tue, 13 Nov 2018 04:30:54 -0800 (PST)
Received: from ( [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C38F1126DBF for <>; Tue, 13 Nov 2018 04:30:53 -0800 (PST)
Received: from ([IPv6:2a02:2121:2c3:5922:c8fa:53ff:fe7c:53d8]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id wADCUnmY009559 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Nov 2018 13:30:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=b; t=1542112250; bh=vwwZJnXPLVLhpmqsklyywMze68xP/x2Ef8OL9kZjmm4=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=Z/UWJwHxRxbKOBBwjqe49qgsEZuyes1Ddxz2nLw+xhjmpn1JPWQfivOGSaNYuicG5 KzcTmVYcc04kFHAWvdbEo5AqBnnr1KEZhSb5m2ONz6/Dq39jzVwGx0mL0RrG5wdz+l jVXVeO1dEaMeIoEMsVK7FjInVbRRLqpYoS1uLN34=
Received: from bjorn by with local (Exim 4.89) (envelope-from <>) id 1gMXq8-0007H5-DI; Tue, 13 Nov 2018 13:30:44 +0100
From: Bjørn Mork <>
To: Ladislav Lhotka <>
Cc: Paul Wouters <>, DNSOP WG <>
Organization: m
References: <> <> <>
Date: Tue, 13 Nov 2018 13:30:44 +0100
In-Reply-To: <> (Ladislav Lhotka's message of "Tue, 13 Nov 2018 13:07:55 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.2 at canardo
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] request for adoption
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: Tue, 13 Nov 2018 12:30:57 -0000

Ladislav Lhotka <> writes:
> Paul Wouters <> writes:
>> I am also confused by the difference between deprecated and
>> obsoleted. I guess the yang model interprets the IANA regitry, but the
>> registry has no official column designation for this. I wonder if it
>> should be given one. I also then suggest that the terms obsoleted and
>> deprecated be merged into one term.
> Actually, I copied the corresponding text from RFC 7224, but I am not
> sure whether the deprecated status is used at all in IANA registries. If
> not, we can remove that part and leave only "obsolete". Unless somebody
> knows the answer right away, I will ask IANA about it. 

Don't know if it is directly relevant to DNS, but the RFC6918 abstract
makes this a question of standardisation:

   A number of ICMPv4 message types have become obsolete in practice,
   but have never been formally deprecated.  This document deprecates
   such ICMPv4 message types, thus cleaning up the corresponding IANA

The corresponding ICMPv4 type registry does of course use the term
"deprecated" for these.

Translated to DNS, this would make MB etc "obsolete" until some future
standards track RFC officially "deprecates" them. Makes sense?