Do we need a formalized language: [Was: Re: analysis of YANG vs. RELAX NG]

[Balazs Lengyel <[e-mail]>]

Hello,
Ericsson uses it"s own formalized language (which we would like to change to a standard 
solution) to automatically
- generate code
- generate html documentation in a strict Ericsson-format
- do semantic checks
- provide standard interface description e.g. LDAP schema files, Corba IDLs

Doing all this without a precise formal language would be near impossible.

Balazs

Jon Saperia wrote:
> 
> On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder wrote:
> 
>> On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote:
>>
>>> Another question to answer, is why is having a data model (an 
>>> ontology) not 
>>> enough?  The question of needing a standard data model must be separated 
>>> from the need for a custom modeling language.  Some of the 
>>> justifications 
>>> I've seen so far for a modeling language have really been justifying 
>>> only a 
>>> standard data model.
>>
>> Different areas happen to use different terminology. What you call a
>> data model is what network management people happen to call an
>> information model, see RFC 3444. I don't care which terminology we use
>> in this discussion as long as we happen to understand the same thing
>> when we use the same words.
>>
>>> Of course using XML as the data format doesn't, by itself, give 
>>> enough of a 
>>> common data model for 3rd-party NetConf tools to understand arbitrary 
>>> data. 
>>> NetConf probably does need a common data model, perhaps defining how IDs 
>>> are expressed and what a container is, what is a netconf "object" 
>>> that can 
>>> be operated on.
>>>
>>> But a common data model does not need to depend on a modeling 
>>> language at 
>>> all.  Put it differently: a sufficiently strong common data model can 
>>> work 
>>> with multiple modeling languages without harming interoperability.  
>>> Thus, 
>>> having a standard data model that is independent of the modeling 
>>> language 
>>> can be a real win for clarity and robustness and somewhat more proof 
>>> against changing stylistic preferences.
>>
>> The network management world is used to automated processes and the
>> number of MIB modules in existences may serve as a proof that people
>> do find benefits from using machine readable definitions. OK, to be
>> fair, I must admit that SNMP is almost unusable with generic tools
>> without at least translating OIDs into something textual. But there is
>> of course much more you get out of concrete machine readable data
>> models since they can drive large (and annoying and error prone) parts
>> of implementation processes.
>>
>>> The commonest approach for IETF protocols that deal with an ontology 
>>> is to 
>>> define the data model in English, limiting the ways the data can be 
>>> expressed to something that becomes essentially self-describing (the 
>>> name 
>>> of a new thing/object, and its contents or value, can be derived from 
>>> the 
>>> document without seeing a specific schema).  LDAP is one of the clearest 
>>> examples of this.  An LDAP agent can handle custom content because it 
>>> follows the expected data model. There's no need, in LDAP, for a special 
>>> language to describe new attributes.  The iCalendar and vCard formats 
>>> are 
>>> the same.  SNMP is really different in having a special language to 
>>> learn, 
>>> and using that in specs.
>>
>> I would call the "iCalendar apprach" semi-formal and this is likely
>> true for the others you mention as well. My understanding is that
>> iCalendar does in fact use some ABNF plus several other "conventions",
>> i.e., certain naming and structuring rules, value notation rules,
>> quoting rules and so on. So there is somewhat formalized content but I
>> also agree that the overall format is not as strict as the SMIv2 or
>> YANG or RelaxNG or XSD (just to name a few ;-).
>>
>> I believe the key difference is simply the number of definitions
>> network management people happen to deal with. The complete
>> configuration of high-end routers involves significantly more than
>> just a few 10s of knobs. I am sure people from the network device
>> vendor business can provide concrete numbers concerning the size of
>> configuration options you find on today's products in case that is
>> useful. Once you reach a critical threshold, you really like to have
>> precise machine readable specifications that can drive a tool chain
>> and to some extend validate definitions, automate some of the
>> implementation work, reduce implementation bugs, drive documentation
>> tools and so on.
>>
>>> My experience with description languages or other formalizations is that 
>>> these often take the place of proper specification.  Authors think that 
>>> they are done when they've written the code that describes the format.  
>>> However, the most important aspect to a new standard schema is 
>>> usually what 
>>> it *means*.
>>
>> Sure, languages can't turn lazy people into smart people. But the IETF
>> is actually very good at handling this. You can't publish a protocol
>> by writing down just a few ABNF definitions. You can't publish a MIB
>> module by leaving description clauses empty. You can't publish a
>> protocol by just writing down message formats in ASCII art and nothing
>> else. The key to good specifications is simply good reviews.
>>
>> I do not really want to be involved in a high-level discussion whether
>> formalized notations, semi-formal notations, or plain English
>> notations are most useful and I hope we can avoid getting into such a
>> discussion to save us all time and bandwidth. I suggest that the WGs
>> and people actually involved in a given protocol take this decision.
>> Personally, I happen to believe that the scale in terms of the number
>> of definitions you have to handle determines whether machine readable
>> definitions are worth the extra formalization efforts.
>>
>> In the case of NETCONF, it is important to allow operators to quickly
>> and easily understand what configuration knobs exist on their devices,
>> what they mean and how to turn them. A common notation is needed for
>> that so that SDOs, vendors, and operators have a common language to
>> work with. In order to deal with the large number of knobs you find on
>> today's devices, I believe that a formalized notation is well worth
>> the effort.
> 
> Juergen, there is one additional point/requirement for a solution 
> related to the number of objects you suggest.  That is the rate of 
> change, not be the standards body, in this case since we are talking 
> about configuration information, but by the vendors.  With each new 
> technology, hardware platform, software revision and potentially 
> firmware revision, a vendor will need to modify the 'knobs'.  This is 
> where the formalized notation in my view has a strong payback.
>>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>>
> 
> Thanks,
> /jon
> ----
> Jon Saperia
> [e-mail] <mailto:[e-mail]>
> (mobil) 617-201-2655
> (office) 978-461-0249
> 
> 
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]