IETF Logo Mail Archive

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-iana-class-type-yang

Ladislav Lhotka <ladislav.lhotka@nic.cz> Fri, 16 October 2020 08:23 UTC

Return-Path: <ladislav.lhotka@nic.cz>
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 B88263A0DDB for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2020 01:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 CUgrHzEGWXbD for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2020 01:23:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 876EB3A0DDA for <dnsop@ietf.org>; Fri, 16 Oct 2020 01:23:42 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 32D83140842; Fri, 16 Oct 2020 10:23:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1602836620; bh=aOFyxHsyInf10eEKnE/AfWrZ4tLsgn8a71tqa512LRE=; h=From:To:Date; b=yUadzlTTCrrLAvTM/1lR9lceQi8YliY1fjNzgQ8tqnX6w6ZTNIn/V3PZSwGRDgv3D Qb1moKmvMvhQvy0J/G+Ig11hb+obHghtmVBC7eaeKFTVDoLfrmvuiCQ7iPypQYGsp9 I+9/EPb0HjpVEgVg8Q9ZR5l+M8CP8HQ7fnIqTtzw=
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: Paul Wouters <paul@nohats.ca>, Benno Overeinder <benno@NLnetLabs.nl>
Cc: DNSOP Working Group <dnsop@ietf.org>
In-Reply-To: <alpine.LRH.2.23.451.2010151506440.2187900@bofh.nohats.ca>
References: <BF15012C-DB7D-47DB-973F-5745715521E8@NLnetLabs.nl> <alpine.LRH.2.23.451.2010151506440.2187900@bofh.nohats.ca>
Date: Fri, 16 Oct 2020 10:23:39 +0200
Message-ID: <87y2k6tw8k.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e0v133r4UwC2bqXvp3zULXBVoFQ>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-iana-class-type-yang
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: Fri, 16 Oct 2020 08:23:46 -0000

Paul Wouters <paul@nohats.ca> writes:

> On Thu, 15 Oct 2020, Benno Overeinder wrote:
>
>> This starts a Working Group Last Call for draft-ietf-dnsop-iana-class-type-yang.
>>
>> Current versions of the draft are available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/
>
> This looks good to me.
>
> One minor item. Is it possible to add text in a way that instructs
> implementer they SHOULD NOT add "Obsolete" entries when populating?

I think we need to assume that an implementer is familiar with the YANG spec, and this is just one of the rules to follow. Specifically, RFC 7950 says:

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

This should IMO be sufficient and we needn't repeat in in this document.

>
> Or maybe that could be an instruction to IANA or whoever runs the
> "the initial revision" of the yang module?
>
> The idea is that we want to try and stop the proliferation of decades
> old stuff into new code/documents just because it has an IANA entry.

Such items will be clearly labelled in both the IANA registry and YANG module.
If they are used in new implementations, it might mostly be, I suspect, due to some external pressures rather than implementers' ignorance.

Ladislav

>
> Paul
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

v2.23.0 | Report a Bug | By Email