IETF Logo Mail Archive

RE: Yang update from IESG ?

Paul Wouters <paul@nohats.ca> Mon, 18 November 2019 06:10 UTC

Return-Path: <paul@nohats.ca>
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 BA50112086C; Sun, 17 Nov 2019 22:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 GaTDOECJfeXc; Sun, 17 Nov 2019 22:10:53 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7E2A5120086; Sun, 17 Nov 2019 22:10:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47Gdqb1nsvz3Fn; Mon, 18 Nov 2019 07:10:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1574057451; bh=7ahwNKvHvYpIi1kJDby32Ohov01KDtun2PH2DhYJz6I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LgWMzh5ShUQoW2iHdDSuNpLZwyliNwfuExa16XEA5H5hMdjZCWN/JClqwu4epJqjU CVDxKJnuxmRfznGHNVpc/SBMtSp9XnBVCnR4pgrdsab1Kk6QFD0KRz4Soz/XMAFVp7 mLTmrMRmH4byr7vMCtcA9kX1Ps0ZXQyZN1q/Ofuw=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id o2e2kghp7tVF; Mon, 18 Nov 2019 07:10:50 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 Nov 2019 07:10:49 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9AFFB60011A1; Mon, 18 Nov 2019 01:10:48 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9622382DF4; Mon, 18 Nov 2019 01:10:48 -0500 (EST)
Date: Mon, 18 Nov 2019 01:10:48 -0500
From: Paul Wouters <paul@nohats.ca>
To: Roman Danyliw <rdd@cert.org>
cc: "iesg@ietf.org" <iesg@ietf.org>, ietf@ietf.org
Subject: RE: Yang update from IESG ?
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01E70B0061@marchand>
Message-ID: <alpine.LRH.2.21.1911180102380.9256@bofh.nohats.ca>
References: <alpine.LRH.2.21.1911131435240.22669@bofh.nohats.ca> <359EC4B99E040048A7131E0F4E113AFC01E70B0061@marchand>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="172770717-923614470-1574057448=:9256"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/j5x8mCkRUFQV-CUn6Rh9EdayIzM>
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 06:10:55 -0000

On Mon, 18 Nov 2019, Roman Danyliw wrote:

[ cc:ing ietf@ietf.org for wider discussion, see attachment for Design Patterns ]

> Paul Wouters 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.

Note also that Design Pattern #1 you quote is exactly the one I am
trying to avoid from happening and Design Pattern #2 happened because
I _did_ convince those people not to do Design Pattern #1.

I would like to see the IESG discourage/forbid Design Pattern #1. The
"yang native" advantage of this Design Pattern seems odd to me, because
as far as I know there will be specific yang documents created elsewhere
anyway that are supposed to be updated and used by automation tools?

Paul

v2.23.0 | Report a Bug | By Email