Subject: [YANG] Re: Why NETCONF needs a data modeling language

From: Balazs Lengyel <[email-masked]>
Date: Sun, 02 Dec 2007 10:20:07 -0800

Hello,
 >>    Q1) Why does NETCONF need a DML at all?

If we have an IETF standard DML for NETCONF, device vendors (like my company) will be much 
more comfortable, much more willing to adapt NETCONF itself. With a standard DML we would 
see a better chance at having available 3rd party or even freeware toolkits for NETCONF.

The above would be important even for a company which would not care about interoperability.

Balazs

David Harrington wrote:
>  
>> Hi,
>>
>> There are a few questions that the IESG and others have asked,
>> which I will try to address:
>>
>>    Q1) Why does NETCONF need a DML at all?
>>    Q2) Why is NETCONF special?
>>    Q3) Why won't lots of other WGs want to define their own
>>        protocol-specific DMLs?
>>    Q4) Why isn't XSD or RelaxNG good enough?
> 
> I'll take a whack at answering the same questions.
> 
> A1) Why does NETCONF need a DML at all?
> 
> to promote vendor-neutral interoperable management. 
> 
> It is much easier to develop standards when everybody uses the same
> basic language to communicate; this "common language for shared
> communication" is also reflected in the IETF decision to use English
> text and ASCII documents.
> 
> This is not just about being able to standardize **device
> management**; it is a basic step to permit the standardization of
> **network management** and possibly **services management". The DML is
> a basic building block.
> 
> A2) Why is NETCONF special?
> 
> It is and it isn't. Netconf is only one protocol used for network
> management. 
> 
> It has some unique requirements, such as using a document-based
> approach and differentiating the data for config versus state and for
> dealing with different time-defined contexts such as running and
> startup configs. This differs from other network management protocols,
> such as SNMP and syslog and ipfix, which use their own data formats,
> and usually deal only with the currently-running config. Netconf is a
> tool designed to meet the special requirements of configuration, and
> the DML needs to support special features not found in other NM-DMLs. 
> 
> Netconf is not special, in that any language used for network
> management is likely to have certain common requirements. NM data
> models are commonly used directly by humans, in their raw form, such
> as when they troubleshoot problems using network sniffers. NM data
> models are also commonly used by NMS applications that can handle the
> translations into a more human-readable format. Designers of NM tools
> (e.g., protocols and data models) thus need to pay close attention to
> who will use the information, and to assume that the data will be used
> both directly by humans and by applications. Operators have complained
> strongly that OIDs are very hard to work with in raw form, yet
> operators frequently need to deal with the raw form of the data. 
> 
> A3) Why won't lots of other WGs want to define their own
>         protocol-specific DMLs?
> 
> To paraphrase a wise man from the SNMP community, when you fill a room
> with protocol designers and ask for a solution to a problem, is it a
> surprise when they recommend designing a new protocol?
> 
> The decision about whether to use an existing protocol/DML or develop
> a new protocol/DML should be made after a careful analysis of the
> requirements of the solution. SNMP was designed when CMIP was found to
> not quite address the needs. The SMI was designed when ASN.1 was found
> to not quite address the needs. XML was designed when other DMLs were
> found to not quite address the needs.
> 
> The decision to explore an XML-based DML and to explore a C-like DML
> follows years and years and years of debate over the requiremnts of
> network management, and configuration in particular. 
> 
> If every WG spends as much time analyzing the requirements that the
> OPS area has spent considering this decision, it might be good for
> ensuring no new protoocls are designed that are not really needed, but
> the IETF would also grind to a halt, much as the OPS community has
> done over our many years of debate. And the delay caused by our
> debates has made IETF network management largely irrelevant to the
> operator community (our customers).
> 
> As always, we need to be vigilant and determine whether enough thought
> has been given to reuse of existing protocols. We also need to
> consider the tradeoffs between new protocols and reusing existing
> protocols in ways they were not designed to be used.
> 
> A4) Why isn't XSD or RelaxNG good enough?
> 
> As mentioned in A2, NM data models need to be both machine- and
> human-readable. XSD is machine-readable, but it is a tough language
> for humans. RelaxNG seems better. 
> 
> As discussed further in a different email, Netconf will almost
> certainly need a DML suited to its requirements, and if RelaxNG is
> found to be human-friendly-enough, we would almost certainly still
> need to select a subset and adapt it to meet configuration
> requirements. So the benefit of using RelaxNG over a domain-specific
> DML may be lost by using an adapted-subset of RelaxNG.
> 
> Most operators already understand languages like Perl and C and
> Javascript, because they already need to write lots of scripts to
> manage their networks. Most implementers of NM support in
> internetworking devices work in C or a variant of C. It makes a lot of
> sense to use a language with a C-like syntax for these people, rather
> than forcing them to learn yet another language that was designed for
> some other purpose.
> 
> [soap]
> somebody commented that the designers of XSD and RelaxNG really
> understand how to design DMLs, implying that the OPS community does
> not. Many of the people involved in the ongoing DML discussions over
> the years, and now, are MIB Doctors and operators and protocol
> designers, and have had years of experience designing and working with
> SMI and network management. They understand the requirements of a DML
> for NM far more than the designers of XSD or RelaxNG, who were not
> designing their DMLs for NM purposes.
> [end soap]
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 
> 
> 
> 
> 

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Jon Saperia <[email-masked]>
Date: Sun, 2 Dec 2007 14:00:43 -0500

Thanks
/jon
----------------------
Jon Saperia
TSP NM
(mobil) 617-201-2655
(office) 978-461-0249
[email-masked]

On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote:

> If we have an IETF standard DML for NETCONF, device vendors (like  
> my company) will be much more comfortable, much more willing to  
> adapt NETCONF itself. With a standard DML we would see a better  
> chance at having available 3rd party or even freeware toolkits for  
> NETCONF.

Yes, but does that mean that we will begin to develop a standard  
configuration objects for say, BGP or DiffServ that would work from  
one vendor to the next?  It would be nice to think so, that would  
really help interoperability and should be the target of 'our'  
collective efforts.
/jon
>> to promote vendor-neutral interoperable management. It is much  
>> easier to develop standards when everybody uses the same
>> management. It has some unique requirements, such as using a  
>> document-based
>> the DML needs to support special features not found in other NM- 
>> DMLs. Netconf is not special, in that any language used for network
>> network management, and configuration in particular. If every WG  
>> spends as much time analyzing the requirements that the
>> for humans. RelaxNG seems better. As discussed further in a  
>> different email, Netconf will almost

---

From: Balazs Lengyel <[email-masked]>
Date: Sun, 02 Dec 2007 12:19:01 -0800

Hello,
Naturally our aim is to develop standard NETCONF configuration models, and the more people 
use NETCONF the easier that will be.
Balazs

Jon Saperia wrote:
> 
> Thanks
> /jon
> ----------------------
> Jon Saperia
> TSP NM
> (mobil) 617-201-2655
> (office) 978-461-0249
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> If we have an IETF standard DML for NETCONF, device vendors (like my 
>> company) will be much more comfortable, much more willing to adapt 
>> NETCONF itself. With a standard DML we would see a better chance at 
>> having available 3rd party or even freeware toolkits for NETCONF.
> 
> configuration objects for say, BGP or DiffServ that would work from one 
> vendor to the next?  It would be nice to think so, that would really 
> help interoperability and should be the target of 'our' collective efforts.
> /jon
>>
>>> to promote vendor-neutral interoperable management. It is much easier 
>>> to develop standards when everybody uses the same
>>> operators frequently need to deal with the raw form of the data. A3) 
>>> Why won't lots of other WGs want to define their own
>>>         protocol-specific DMLs?
>>> for humans. RelaxNG seems better. As discussed further in a different 
>>> email, Netconf will almost
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>
>>
>

---

From: Jon Saperia <[email-masked]>
Date: Sun, 2 Dec 2007 17:43:53 -0500

Wrong order - people will push (not just the vendors for convenience)  
when there is something that makes a real difference.
On Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote:

> Hello,
> Naturally our aim is to develop standard NETCONF configuration  
> models, and the more people use NETCONF the easier that will be.
> Balazs
>
>
> Jon Saperia wrote:
>> Thanks
>> /jon
>> ----------------------
>> Jon Saperia
>> TSP NM
>> (mobil) 617-201-2655
>> (office) 978-461-0249
>>> chance at having available 3rd party or even freeware toolkits  
>>> for NETCONF.
>> configuration objects for say, BGP or DiffServ that would work  
>> from one vendor to the next?  It would be nice to think so, that  
>> would really help interoperability and should be the target of  
>> 'our' collective efforts.
>> /jon
>>>

Thanks,
/jon
----
Jon Saperia
[email-masked]
(mobil)	617-201-2655
(office)	978-461-0249