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

[Tomoyuki Iijima <[e-mail]>]

Hello,

> On the other hand, I really don't want to wait 5+ years
> for a new DML.  New work like the partial locking and ACM
> are using XSD, and so will all other new DM work.
> I don't see how one can avoid learning XSD, even if a new DML
> is on the horizon.  And what about the free tools for the DML?
> How long will those take to get established?  Will there be any?

I totally agrew with Andy's comments. We talked about XSD's superiority
at the 68th IETF meeting in Prague. The slide related to this issue is
found below.
http://www3.ietf.org/proceedings/07mar/slides/opsarea-6/sld15.htm

In addition, I mentioned following things.
http://www3.ietf.org/proceedings/07mar/slides/opsarea-6/sld5.htm
IMO, since data models written by XML is transformable into another one
thanks to the XML technology including WSDL, rough data modeling is
enough as long as meaning of each parameter inside data model is well
defined.

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> 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.
> 
> There are tools that help do it for you, just
> like there are C compilers that do the ASM for you.
> BTW, I have 24 years, and a few of them writing
> device drivers in x86 ASM.
> 
> What about writing MIBs and translating them to XSD?
> Your engineers can handle that right?
> 
> Well, this certainly is a problem, that's for sure.
> If people are not willing or able to learn XSD,
> then no WGs can ever really effectively standardize
> data models that use XSD to define the XML syntax.
> 
>>>>> 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.
> 
> 
> Who is 'we'?
> We (the NETCONF WG) has already used complex XSD features
> for the protocol spec and for the notification data model,
> which are the only 2 data models we have done so far.
> There is no agreement across all vendors on how much "power of XSD"
> is actually needed.  (That's the Requirements Phase -- the
> first 18 months of the 5 year plan.)
> 
>>>
>>> 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?
> 
> Why can't max-access be a property of the data, which is realized
> in different ways.  In XSD, it would be an <appinfo> extension.
> In SMIv2, it is MAX-ACCESS. In NCX, it is max-access.
> I think many SMI features can be defined in two parts,
> the conceptual definition, and the DML-specific definition.
> 
>>>>>
>>>>>> 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.
> 
> 
> Sigh...
> 
> People not only refuse to learn XSD,
> there is no agreement at all on what should be
> used instead.  RelaxNG with description clauses
> didn't look much better than XSD, and doesn't address
> any NETCONF-specific issues either.
> 
> You're right that I don't use XSD to write data models.
> I am trying to refine my DML to optimize tool automation.
> I think it's way easier to use than XSD, but my language
> preference is for a C-like syntax (like SMIng).  Other people
> like XML, others SMIv2, and so on.
> 
> Can agreement on a new DML really be reached in the IETF?
> A giant, complicated, "let's do everybody's idea" approach (ala DIFFSERV)
> is not going to work.  I am skeptical the WG result will be
> better and simpler than XSD.
> 
> I completely agree that XSD is not the long term solution.
> I am quite frustrated with the progress that we have had using XSD.
> At a previous WG meeting, Simon asked people who did not understand XSD
> to abstain from a straw poll.  The count was 3 for, 3 against, 40+ abstain.
> 
> On the other hand, I really don't want to wait 5+ years
> for a new DML.  New work like the partial locking and ACM
> are using XSD, and so will all other new DM work.
> I don't see how one can avoid learning XSD, even if a new DML
> is on the horizon.  And what about the free tools for the DML?
> How long will those take to get established?  Will there be any?
> 
> 
>>> 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.
>>>
>>
>>
> 
> 
> Andy
> 
> 
> 
> _______________________________________________
> NGO mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ngo
> .
> 


-- 
Tomoyuki Iijima
Hitachi, Ltd. Central Research Laboratory
TEL:[phone] ext.3579
FAX:[phone]
E-mail:[e-mail]



_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo