YANG Just crashed and burned AFAIC

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 08 December 2014 21:57 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0921ACFDE for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 13:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 q3VVtoIRkMsc for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 13:57:13 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDE01ACFB7 for <ietf@ietf.org>; Mon, 8 Dec 2014 13:57:13 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id z11so4396906lbi.24 for <ietf@ietf.org>; Mon, 08 Dec 2014 13:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=47rmXgMq4koF10AtspixCbGwLeaz43TM6whrM1o5Y6s=; b=M0Qg7mqGgOJvH63T9FGKT0SA08hhlEkDj6nhNRNkbFAC919T9Ay8PDSQFhP9uB0mL6 fARpao0TKuIEdP0FL6zyxFyp5gyO/QK4F2yvZI+YgW23tK2IGJZGb6a8TOLtGa4Oey5j vN6AGold9ivujmfjOxtVDyvC1psyMPJvxMyb6d+rfUrZi9tkgwo7XVAiXJr6Z2/s/rjp vqNS70a6/G2NdPVcLUIGcPNnLeIAt4CCCgk6nAoXQJgIi0MGX/RRf3qD6w3QNe/dZQT7 uKnxXubrjH3eImeUs1tOg5KP2DMuhdUuydhCCvCR4BcrX7OOJ5tmSJOrPWvKAFEHzyRz FTIw==
MIME-Version: 1.0
X-Received: by 10.152.22.97 with SMTP id c1mr18566402laf.85.1418075831595; Mon, 08 Dec 2014 13:57:11 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Mon, 8 Dec 2014 13:57:11 -0800 (PST)
Date: Mon, 08 Dec 2014 16:57:11 -0500
X-Google-Sender-Auth: Etbo_pWaeizhXoGVLUJpACPWtVI
Message-ID: <CAMm+LwjoWCF0fF2qkZJh0MUBv78QutjWMj4pOOeA39=i6ancDg@mail.gmail.com>
Subject: YANG Just crashed and burned AFAIC
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Benoit Claise <bclaise@cisco.com>
Content-Type: multipart/alternative; boundary="089e0158b86a34f91e0509bb822a"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/vtqmwQFutpAqxpOxynWpHX-AeB0
Cc: IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 08 Dec 2014 21:57:15 -0000

On Mon, Dec 8, 2014 at 4:32 AM, Benoit Claise <bclaise@cisco.com> wrote:

>  Hi Tom,
>
> In light of the numerous YANG models these days, there is the YANG doctors
> scaling issue. You're right, even if the number of YANG doctors recently
> increased, we need other venues to provide advice to YANG model designers.
> This should solve the issue of designing properly the YANG models.
> On the other hand, there is a bigger issue, IMO: the proper coordination
> of those YANG models. This is not the YANG doctors responsibility. This
> can't be: see the YANG doctors scalability issue.  So who's responsibility
> is this? Simply asserting "it's the community responsibility" is the easy
> answer, but I'm afraid it will not work.
>

Well that has lost me completely.

If you need a schema doctor then we are not talking about a data model that
should be allowed for any use other than describing past work with greater
formality.

The only thing I like in ASN.1 is that it did at least attempt to provide a
single encoding that would support the whole stack. What makes ASN.1 unfit
for purpose is the nonsense distinctions that are introduced with implicit,
explicit, tagging definite length encoding, SETs vs SEQUENCEs and all the
rest of the idiot distinctions that do nothing but create the need for a
consultant to use the thing.


We should have one data model with a text encoding and an option for
binary. JSON currently seems to be winning the encoding battle for text so
if we add a binary encoding that has identical semantics to the text
encoding (i.e. can round trip losslessly wrt the data model) we are done.

If we want to make things needlessly complex then lets make them Turing
complete.