Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal

Balazs Lengyel <balazs.lengyel@ericsson.com> Fri, 07 September 2007 16:17 UTC

Return-path: <ngo-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgVx-0004dR-H4; Fri, 07 Sep 2007 12:17:01 -0400
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1ITgVw-0004dI-92 for ngo-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 12:17:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgVv-0004d9-Vh for ngo@ietf.org; Fri, 07 Sep 2007 12:16:59 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITgVu-0004UF-90 for ngo@ietf.org; Fri, 07 Sep 2007 12:16:59 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 91E5820061; Fri, 7 Sep 2007 18:16:57 +0200 (CEST)
X-AuditID: c1b4fb3c-b067fbb0000007e1-57-46e179792b47
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FDA520058; Fri, 7 Sep 2007 18:16:57 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:16:57 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:16:56 +0200
Message-ID: <46E17978.6080505@ericsson.com>
Date: Fri, 07 Sep 2007 18:16:56 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
Subject: Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal
References: <46E03BD1.4010702@andybierman.com> <20070906184430.GA2882@elstar.local> <46E05160.50503@andybierman.com> <20070906195555.GA3040@elstar.local> <46E0630B.2030908@andybierman.com> <20070906211658.GA3081@elstar.local> <46E07909.1060209@andybierman.com> <20070907063232.GA3394@elstar.local> <46E15034.30309@andybierman.com>
In-Reply-To: <46E15034.30309@andybierman.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2007 16:16:56.0959 (UTC) FILETIME=[82F9E0F0:01C7F16A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: NETCONF Goes On <ngo@ietf.org>
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Errors-To: ngo-bounces@ietf.org

Hello,
You seem to want to describe everything around a data model just not the data model itself.

See also below!

regards Balazs

Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
>> On Thu, Sep 06, 2007 at 03:02:49PM -0700, Andy Bierman wrote:
>>
>>>> So you suggest to standardize data models in assembler code?
[BALAZS]: Kill me, but I have 23 years of programming behind me, and I never really knew 
assembler. I don't want to start now. Give me something better then XSD. I will never be able 
to convince Ericsson to start working in XSD.
>>> I am suggesting that XSD continue to be used for the foreseeable future.
>>
>> It is hard for me to understand you. You sometimes argue that XSD is
>> human unreadable and you point to the NETCONF experience with bugs in
>> the XSD not being detected and a moment later you argue that XSD is
>> kind of assembler code but then you also seem to tell me that XSD is
>> the way to publish standard data models.
> 
> XSD is problematic, but it is the only robust DML that
> has decent tools support.
> 
> The IETF is way too clueless to develop a suitable XSD replacement
> from scratch.  Even if there were enough cluefull people to
> do the work, it would take 5+ years to finish.
[BALAZS]: I think we should NOT speak of an XSD replacement. A NETCONF data modeling language 
must be much more simple then XSD. That would be the main reason to have a new language, to 
make it smaller, more understandable. I agree that if we would want the full power of XSD, then 
we would have a difficult job, but we don't.
> 
> IMO, this is just a less-than-clever way to put off creating
> any standard data models for configuration.  Just publish cryptic
> XSDs with no documentation, and claim that XSD is too hard to read.
> Just claim that no data models can possibly be standardized until
> a brand new DML is 'done', and since the SMIng WG showed how well
> the IETF can agree on a new DML, that could be never.
> 
> 
>>
>>>> Or do you suggest to standardize informal englisch prose information
>>>> models that everybody can turn into their favourite NETCONF data
>>>> modeling language to produce some assembler that hopefully is
>>>> interoperable?
>>> I am suggesting that data models be clearly documented, instead
>>> of just putting an XSD into an xml2rfc template and publishing it.
>>> I think an SMI document is needed that addresses many details
>>> that need to be supported for long-term module management,
>>> and interoperability between modules, which I address in the 
>>> ncx-smi-00 draft.
[BALAZS]: Your draft was very interesting for me with a number of good proposals, but you will 
need a way  to formally describe some of the topics, like max-access. In which modeling language?
>>>
>>>> Something else?
>>> I think new DMLs should be considered experiments,
>>> and experiments are good for achieving the long term goals.
>>
>> I guess I do not really understand the difference between "an SMI
>> document is needed that addresses many details that need to be
>> supported for long-term module management, and interoperability
>> between modules" and a new DML which would be an experiment.
> 
> How is a module allowed to change over time?
> What does the use of the same namespace URI over time mean?
> How does the manager discover modules and versions?
> How does a manager compare versions?
> How does a manager know the difference between
[BALAZS]: As an example when you start to define which parts can be changed in a 
compatible/incompatible way you will need to go into data modeling details. You will use the 
XSD terminology or something new. Now you can say that you are happy with XSD, but a number of 
people are not.
Either way if we delay defining the Netconf DML for another 5 years two things can happen:
1) People will not use Netconf because they don't know how to describe their data models
2) People will hate XSD so they avoid Netconf or use a proprietary DML
3) People start to learn XSD, but as some people have indicated they didn't learn XSD until 
now, so a sudden change is not certain.
> a read-create row and a read-only row (or column)?
> How does a manager know what an agent is supposed to
> implement to claim a certain level of conformance?
> 
> These are some of the open issues that NETCONF needs to
> address, just as SMIv2 addresses these issues for the SNMP protocol.
> 


_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo