Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)

Ladislav Lhotka <ladislav.lhotka@nic.cz> Thu, 03 June 2021 13:17 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 5A93C3A10CA; Thu, 3 Jun 2021 06:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, 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 4V0e_crdfX88; Thu, 3 Jun 2021 06:17:21 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 AF9AC3A10CC; Thu, 3 Jun 2021 06:17:17 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8] (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 9A294140A37; Thu, 3 Jun 2021 15:17:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1622726234; bh=fk6VkBzikCq+FvUXEm+vII5Wbquy7+7NruvwdQH+0uo=; h=To:From:Date; b=TyCiZEJpkS52nz/lvw/Wf+8XiXAGayzL0noypgEpUEHyYEltOkJMQ3JTW/GNbZRHC 4Ghr9D/BPpAhvZTMP1WCdCTPOd2bLxcQs3xrKDaB2gO+2HeA+dDXu1wK3d8Ua00spv 0Kz8Vrj5fFyvI9+BNLyVEvOMcUhW6Lnc9WalitwQ=
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-iana-class-type-yang@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, benno@NLnetLabs.nl
References: <162271898741.9722.1347203006737053876@ietfa.amsl.com>
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
Organization: CZ.NIC
Message-ID: <b7d76095-e82d-4152-4a1e-865545e589a9@nic.cz>
Date: Thu, 03 Jun 2021 15:17:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162271898741.9722.1347203006737053876@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1Xwzd2bgafnFth_7GB9awzYQ-5A>
Subject: Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)
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: Thu, 03 Jun 2021 13:17:27 -0000

Hi Rob,

On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote:

...

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> One issue that I think we should should discuss and resolve (sorry for the late
> discuss ballot):
> 
> In section 4, it states:
> 
>    "status":  Include only if a class or type registration has been
>       deprecated or obsoleted.  In both cases, use the value "obsolete"
>       as the argument of the "status" statement.
> 
> I know that we have had some previous discussion on this on Netmod, but, if
> draft-ietf-netmod-yang-module-versioning-02 gets standardized then it will
> effectively evolve YANG's "status deprecated" into "must implement or
> explicitly deviate" and YANG's "status obsolete" into "must not implement".  It
> wasn't clear to me that marking one of these fields as being deprecated in an
> IANA registry would mean that existing implementations must stop using it if
> they migrate to a new version of the generated YANG module.  Hence, I think
> that at this stage, it may be safer to map IANA "deprecated" into YANG's
> "status deprecated"?
> 

Yes, this was discussed repeatedly in NETMOD and DNSOP WGs. I think we
currently have to use RFC 7950 for the status definitions, and so in YANG

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

This is incompatible with the meaning of "deprecated" in IANA
registries, which is per RFC 8126: "use is not recommended".

I agree that this discrepancy should be solved in a new version of YANG,
possibly along the lines of draft-ietf-netmod-yang-module-versioning-02,
but we can't wait for that with this draft.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Thanks for this document.  I think that documenting this fields in YANG is a good thing.
> 
> One minor nit:
> 
> In an couple of places you have used 'analogically' but perhaps meant 'analogously' instead?

Yes, I will change all occurrences.

Thanks, Lada

> 
> Thanks,
> Rob
> 
> 
> 

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