Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Rob Shakir <rjs@rob.sh> Tue, 02 August 2016 16:52 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBB612B04F for <netmod@ietfa.amsl.com>; Tue, 2 Aug 2016 09:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 n2N3gogwaPDs for <netmod@ietfa.amsl.com>; Tue, 2 Aug 2016 09:52:21 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C18C12D0E1 for <netmod@ietf.org>; Tue, 2 Aug 2016 09:52:20 -0700 (PDT)
Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1bUcv4-0006qM-Nd; Tue, 02 Aug 2016 17:51:54 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_7991D393-9020-4ABC-A331-FE6BBEF3DE5F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Rob Shakir <rjs@rob.sh>
In-Reply-To: <154e783b-9817-9d74-4af6-23f403db3fb2@ericsson.com>
Date: Tue, 02 Aug 2016 10:52:16 -0600
Message-Id: <EB8F2C12-E341-4F65-B6C3-C6541E53F785@rob.sh>
References: <bed9398c-0e6a-450e-d2ac-b381b6bebf87@cisco.com> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com> <m24m79c1ja.fsf@birdie.labs.nic.cz> <D3BF8708.72620%acee@cisco.com> <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com> <m260roedim.fsf@birdie.labs.nic.cz> <CABCOCHRF98sTa=MA1VTkZovOufL-=yQr9Gzy+ojnncjSfK1y0Q@mail.gmail.com> <e307c2fc-e621-b5c6-4fcc-67bbcdcb87b9@cisco.com> <20160729163220.GA3579@elstar.local> <154e783b-9817-9d74-4af6-23f403db3fb2@ericsson.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RGbE93scMqUg42t9xembTtAmgKE>
Cc: netmod WG <netmod@ietf.org>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 16:52:24 -0000

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we should state that other combinations e.g. trees spliting close to the leaves or a mix of 1) and 2) in the same module are not allowed (VERYYYY STRONGLY discouraged). 

What is the motivation for this very strongly discouraged statement? The problem I take with this is that you are not only getting zero consistency that will let a user determine how a model might look  (painful for those actually *using the models* rather than writing them - who are hugely under-represented in this discussion), but you’re also throwing out a bunch of models (both inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to see any justification why anything other than a solution that is already being implemented is preferable to this WG other than it seeming like the WG doesn’t like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it’s quite frankly lamentable that such a division is being created with no reasonable justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to applied config - the structure that is being objected to can be trivially implemented without those leaves if one wanted to.

r.