Re: WG Review: NETCONF Data Modeling Language (netmod)

Eric Rescorla <ekr@networkresonance.com> Tue, 22 April 2008 21:53 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40593A6E1B; Tue, 22 Apr 2008 14:53:07 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1303A6CE2; Tue, 22 Apr 2008 14:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRKFXvu7sOE9; Tue, 22 Apr 2008 14:53:05 -0700 (PDT)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id CE9923A6E1B; Tue, 22 Apr 2008 14:53:05 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 09FD05081A; Tue, 22 Apr 2008 14:56:41 -0700 (PDT)
Date: Tue, 22 Apr 2008 14:56:40 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Bert Wijnen - IETF" <bertietf@bwijnen.net>
Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
In-Reply-To: <NIEJLKBACMDODCGLGOCNCEGOEMAA.bertietf@bwijnen.net>
References: <20080422211401.303175081A@romeo.rtfm.com> <NIEJLKBACMDODCGLGOCNCEGOEMAA.bertietf@bwijnen.net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080422215641.09FD05081A@romeo.rtfm.com>
Cc: ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At Tue, 22 Apr 2008 23:16:02 +0200,
Bert Wijnen - IETF wrote:
> instead of discussing if there was consensus AT THE BOF
> (we all know that at this point in time we DO have 
> consensus between all the interested WORKERS in this space, 
> albeit that the current consensus was arrived at in further
> (smaller) meetings, in extensive DT work after the IETF and
> again after review on NGO list).

Which is why it is now returned to the broader community for
additional perspectives from those not already committed to a
particular path


> I propose that you list (again) your (technical) objections
> to the the current proposal.

Sure. Based on my knowledge of modelling/protocol description
languages, the techniques that Rohan described based on RNG and
Schematron seemed to me quite adequate to get the job done and the
relatively large baggage introduced by defining another language
(YANG) which is then translated into them seems wholly unnecessary.

I appreciate that some people believe that YANG is more expressive and
better suited for this particular purpose, but I didn't see any really
convincing arguments of that (I certainly don't find the arguments in
F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of
the complexity of designing such languages, and of their ultimate
limitations and pitfalls, this seems like a bad technical tradeoff.


> If all you can tell us is that
> we need to spend just more cycles on re-hashing the pros
> and cons of many possible approaches, then I do not
> see the usefulness of that discussion and with become 
> silent and leave your opion as one input to the IESG for
> their decision making process.

Unfortunately, it's not that simple. This is precisely the technical
discussion that needs to happen in a public forum, not on some design
team and then presented as a fait accompli.

That said, I think I've stated my position as best I can and that
while I understand yours, you and I just disagree about what the
IESG should do, so I'll take your advice to become silent at this
point.

-Ekr

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf