Re: Yang update from IESG ?

Lou Berger <lberger@labn.net> Mon, 18 November 2019 23:13 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5AD120B69 for <ietf@ietfa.amsl.com>; Mon, 18 Nov 2019 15:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 EA4vurlEofCp for <ietf@ietfa.amsl.com>; Mon, 18 Nov 2019 15:13:28 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 CC549120919 for <ietf@ietf.org>; Mon, 18 Nov 2019 15:13:28 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 5E5101AB211 for <ietf@ietf.org>; Mon, 18 Nov 2019 16:13:28 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id WqD2igf65lpxgWqD2iCRWF; Mon, 18 Nov 2019 16:13:28 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=EqD8UxUA c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=MeAgGD-zjQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=HLvPDLHGFjgA:10:nop_election2020_name_subject a=r77TgQKjGQsHNAKrUKIA:9 a=N7iCXatbAAAA:8 a=xznE5cbMHULSWwh1f14A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=pGLkceISAAAA:8 a=L6ZISBKyaqXi0tA97AcA:9 a=aiyMSXjIhsM1i6Yh:21 a=_W_S_7VecoQA:10:nop_html a=96hUrU2xWrTe0OLsCvyc:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=ODNR8B9nDn9s694E0m14XwM06cmRQhO1aQd9NSVB0NI=; b=k+DMvk4U5uvzSKKv702/wYK67I zGmsZHNTl2xoKnMa/vYnFDWAusZiqOfk/t6VL1MNvNLz9U3MeDGynPkDcAxTLR6bBBqgKcapn+zS6 hSwO2OQ60WaWC9ynl3JH34OkC;
Received: from [127.0.0.1] (port=41635 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1iWqD1-002GSK-NB; Mon, 18 Nov 2019 16:13:28 -0700
Subject: Re: Yang update from IESG ?
To: Tim Wicinski <tjw.ietf@gmail.com>, Ladislav Lhotka <lhotka@nic.cz>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Paul Wouters <paul@nohats.ca>, "iesg@ietf.org" <iesg@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>
References: <alpine.LRH.2.21.1911131435240.22669@bofh.nohats.ca> <359EC4B99E040048A7131E0F4E113AFC01E70B0061@marchand> <alpine.LRH.2.21.1911180102380.9256@bofh.nohats.ca> <10541.1574083581@dooku.sandelman.ca> <e745d480c113b09eb4f6761cf48ef1e997fc3e6c.camel@nic.cz> <CADyWQ+Eh3ULpfRp-Bg6R9V6veWS3d0Ry_zEgP7FuL2L6djhDjA@mail.gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <6f5a54ca-98fb-e510-9fcf-2a98e2735e6d@labn.net>
Date: Mon, 18 Nov 2019 17:13:23 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CADyWQ+Eh3ULpfRp-Bg6R9V6veWS3d0Ry_zEgP7FuL2L6djhDjA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------48A47D1866B58E8B048F6EBD"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1iWqD1-002GSK-NB
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:41635
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-ltGXD8_YwxtRzq3SXD1KDvyRoU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 23:13:34 -0000

We do have a working group that is chartered to deal with general/common 
issues with YANG -- NetMod.  I suggest that this be hashed out there. -- 
Of course the ADs need to concur...

Lou

NetMod Co-chair

On 11/18/2019 8:49 AM, Tim Wicinski wrote:
>
>     IANA has been doing it for more than five years for a couple of
>     YANG modules
>     (six by now), and I am not aware of any troubles so far.
>
> But that's work put onto the IANA pile, and some I* organization may 
> want to understand the
> commitment.
>
> On Mon, Nov 18, 2019 at 10:08 PM Ladislav Lhotka <lhotka@nic.cz 
> <mailto:lhotka@nic.cz>> wrote:
>
>     On Mon, 2019-11-18 at 21:26 +0800, Michael Richardson wrote:
>     > Paul Wouters <paul@nohats.ca <mailto:paul@nohats.ca>> wrote:
>     >     >>> During a plenary at the last or second last IETF, I
>     raised an issue
>     >     >>> about people stuffing incomplete and obsolete/deprecated
>     partial IANA
>     >     >>> registiries in yang drafts/RFCs. The IESG confirmed this
>     as a problem
>     >     >>> to me and one of the IESG members said they were aware
>     and would get
>     >     >>> back on this.
>     >     >>>
>     >     >>> I have not heard anything. The issue is still a problem.
>     Originally,
>     >     >>> this came up in i2nsf/ipsecme, and has now resurfaced
>     for me in
>     >     >>> dnsop.
>     >
>     >     >> The IESG talked about this issue during the last IETF
>     meeting.  See
>     >     >> attached.
>     >     >>
>     >     >> The outcome of this discussion was that there is no
>     single "right
>     >     >> answer" and individual ADs should intervene on specific
>     instances as
>     >     >> appropriate.
>     >
>     >     > Thanks for the answer. Unfortunately, it is not much of
>     guidance and
>     >     > does not really address the issue I raised, namely that we
>     are putting
>     >     > snapshots of IANA registries in RFC documents. One of your
>     three Design
>     >     > Patterns still does this.
>     >
>     > I also am unhappy with this situation.
>     >
>     > As far as I can tell it means that IANA will be maintaining YANG
>     modules.
>     > I don't understand how this is going to work for real products.
>
>     IANA has been doing it for more than five years for a couple of
>     YANG modules
>     (six by now), and I am not aware of any troubles so far.
>
>     Lada
>
>     >
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>