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

"Randy Presuhn" <> Fri, 25 April 2008 21:21 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 669833A6AAD; Fri, 25 Apr 2008 14:21:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2288B3A6835 for <>; Fri, 25 Apr 2008 14:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CsZHgM7L1kxo for <>; Fri, 25 Apr 2008 14:21:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 662103A6D12 for <>; Fri, 25 Apr 2008 14:21:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=GEF5pfYi5RUtMmUlszrx7Q8zepgFUtg313f9HYZySW7CMvFK6bf7X33o0AJvJC6a; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=oemcomputer) by with esmtpa (Exim 4.67) (envelope-from <>) id 1JpVLr-0002N1-Mh for; Fri, 25 Apr 2008 17:21:04 -0400
Message-ID: <001401c8a711$e6d10600$6801a8c0@oemcomputer>
From: "Randy Presuhn" <>
To: "IETF Discussion" <>
References: <>
Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
Date: Fri, 25 Apr 2008 14:21:09 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117ecb8db37f43ecf4410fa700d9eba9535350badd9bab72f9c350badd9bab72f9c
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi -

> From: "Bernard Aboba" <>
> To: <>
> Sent: Thursday, April 24, 2008 6:40 PM
> Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
> I echo Tom Petch's concern.
> Given the level of deployment success of IETF management efforts
> for the last 5-10 years, I'd suggest that we need both customer
> "pull" as well as technical community "push" for such an effort
> to succeed.  While there have been arguments made for the latter,
> I don't see enough evidence of customer (in particular, operator)
> involvement to feel confident that the former has been addressed.

Whether we like it or not, the last five years have been devoted largely to
NETCONF.  RFC 4741 is already published on the standards track.
During that time, the community has been forbidden to work on data models
in the IETF.  Without data models, NETCONF's utility is rather limited, to
say the least.  Consequently, a lack of perceived "pull" should hardly be

The choice before us is pretty simple:

   - allow work to continue on standardized data models, so there will be
     some hope of interoperability

   - ignore the need, rely on the continued proliferation of proprietary
     approaches, and hope someone else figures out how to interoperate
     (though some may consider the lack of interoperability to be a sales-
     enhancing feature rather than a problem to be overcome)

   - hope some other organization will give the work a home if the people
     willing to do the work are not allowed to do it on IETF turf.

The question now is whether the IETF wants NETCONF protocol to succeed.
Yes, more operator input is desirable.  But in the case of NETCONF,
the protocol itself is far removed from what the operators asked for
at the IAB workshop. These leaves me wondering whether more input
would really change anything.

Based on my understanding of the operator input at the IAB workshop,
the Yang proposal, of all the ones mentioned at the CANMOD BOF,
is by far the best-aligned with the concerns the operators voiced,
which were, in a word, "readability".  (For the data itself, terms like
"screen scraping" came up a lot.)

I'm certain something better is possible, but no one has bothered
to write an i-d.  At some time we have to stop waiting for something
better to magically appear and go with something that will be good
enough that has the support of implementors.

This work should have been undertaken five years ago.  How much


IETF mailing list