Subject: [Netconf] A data modeling question

From: Jernej Tuljak <[email-masked]>
Date: Thu, 25 Oct 2012 13:02:26 +0200

Hi,

I have a question about the future of NETCONF in terms of servers 
exposing their data model to clients. I know RFC6241 states the data 
model is out of it's scope but will this always be the case?

I've been following the discussions on both Netmod and Netconf 
mailing-lists for some time now and got the feeling that YANG and 
NETCONF are going to get coupled more closely together in the future. 
This makes sense since YANG represents the only standard way of exposing 
a server's data model (the only way I know of, except for base protocol 
capability URIs). Without it, NETCONF probably loses most of it's value. 
You could avoid YANG and resort to an XSD, RNG schema or something 
similar, since YANG is just a specialized XML schema anyways. But doing 
that automatically means you are doing things in a non-standard way. 
There's nothing written anywhere about how a server using XSD instead of 
YANG is supposed to announce it's capabilities, so implementers are 
bound to come up with different ways of handling this. Even in case of 
YANG, not everything about announcing conformance is clear, as some 
discussions have proven. And then there's also the differentiation 
between state and config data (and quite possibly other types soon). 
There's lots of ways you could achieve that with a general XML schema.

The reason I'm writing this is that we recently had a feature request 
for our client to support XML schema along with YANG. Since our client 
is striving to be a generic one (bottom up approach according to 
RFC6244) and there's no standard way or even guidelines to handle such 
data models, it feels like implementing this would be a step in the 
wrong direction. It might even send a wrong signal to other users which 
could then easily assume that YANG is just another thing they don't need 
to bother with. But is this really the case? In the coming interop tests 
there is currently a small number of servers listed to join in and most 
of them are YANG-based or at least use YANG modules in their hello 
message (avoiding actual numbers here because I don't know if they can 
be discussed). What does that mean?

I'm not trying to propose anything here. I'd just like to know what 
others think about the loose way of how NETCONF currently treats data 
models and how this might end up in the future.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Oct 2012 13:45:14 +0200

Hi Jernej,

did you check RFC 6022?

Lada

On Oct 25, 2012, at 1:02 PM, Jernej Tuljak <[email-masked]> wrote:

> Hi,
> I have a question about the future of NETCONF in terms of servers exposing their data model to clients. I know RFC6241 states the data model is out of it's scope but will this always be the case?
> I've been following the discussions on both Netmod and Netconf mailing-lists for some time now and got the feeling that YANG and NETCONF are going to get coupled more closely together in the future. This makes sense since YANG represents the only standard way of exposing a server's data model (the only way I know of, except for base protocol capability URIs). Without it, NETCONF probably loses most of it's value. You could avoid YANG and resort to an XSD, RNG schema or something similar, since YANG is just a specialized XML schema anyways. But       doing that automatically means you are doing things in a non-standard way. There's nothing written anywhere about how a server using XSD instead of YANG is supposed to announce it's capabilities, so implementers are bound to come up with different ways of handling this. Even in case of YANG, not everything about announcing conformance is clear, as some discussions have proven. And then there's also the differentiation between state and config data (and quite possibly other types soon). There's lots of ways you could achieve that with a general XML schema.
> The reason I'm writing this is that we recently had a feature request for our client to support XML schema along with YANG. Since our client is striving to be a generic one (bottom up approach according to RFC6244) and       there's no standard way or even guidelines to handle such data models, it feels like implementing this would be a step in the wrong direction. It might even send a wrong signal to other users which could then easily assume that YANG is just another thing they don't need to bother with. But is this really the case? In the coming interop tests there is currently a small number of servers listed to join in and most of them are YANG-based or at least use YANG modules in their hello message (avoiding actual numbers here because I don't know if they can be discussed). What does that mean?
> I'm not trying to propose anything here. I'd just like to know what others think about the loose way of how NETCONF currently treats data models and how this might end up in the future.
> Jernej
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 25 Oct 2012 14:22:47 +0200

> did you check RFC 6022?

Sure I did. So a standard way to expose an XSD/RNG based server data 
model would be to implement ietf-netconf-monitoring?

Jernej

>
> Lada
>
> On Oct 25, 2012, at 1:02 PM, Jernej Tuljak<[email-masked]>  wrote:
>
>> Hi,

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Oct 2012 14:26:53 +0200

On Oct 25, 2012, at 2:22 PM, Jernej Tuljak <[email-masked]> wrote:

> Sure I did. So a standard way to expose an XSD/RNG based server data model would be to implement ietf-netconf-monitoring?

I guess so.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Thu, 25 Oct 2012 09:03:45 -0400

Jernej Tuljak writes:
>for our client to support XML schema along with YANG.

Can you share something about your customer's motivations?  Are
they uncomfortable with YANG and more comfortable with XSD?  Are
they already modeling in XSD?  Are they using tools that require
(or already generate) XSD?  Can you make XSD->YIN scripts suitable
for translating their model from XSD into YANG?

My overall suggestion would be to find a way to announce your XSD
capabilities in such a way that it would be compatible with a near
future when the customer's ever-growing love of YANG pushes them
to start modeling in YANG and celebrate their freedom from XSD.

Sure, it's an optimistic picture, but optimism is a mandatory
requirement for life in the IETF.  ;^)

Thanks,
 Phil

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 25 Oct 2012 15:40:26 +0200

Dne 25.10.2012 14:26, piše Ladislav Lhotka:
> On Oct 25, 2012, at 2:22 PM, Jernej Tuljak<[email-masked]>  wrote:
>

That then solves the data model exposure problem. But there's still no 
way for a generic client to interpret schema discovered this way. They 
may describe NETCONF content but there's no standard way to determine 
what kind. Data? RPC operation? Notification body?

I don't see a good way of implementing support for this in a netconf 
client. Hard-coding is of course not an option.

Jernej

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 25 Oct 2012 16:25:56 +0200

> requirement for life in the IETF.  ;^)

These specific customers are probably developing a NETCONF server and 
want to avoid using YANG to model their content. I think they started 
off with XSD and want to keep it that way.

We could probably manually create YANG based on their XSD, but that 
would not solve the problem in general. As far as I know XSD->YANG 
conversion is not trivial to implement so it can't cover every case. It 
would probably require heavy user interaction or some sort of 
annotations in the XSD itself. Such a tool would be quite useful though.

I've actually seen people ditching NETCONF entirely, simply because they 
thought YANG was "unnecessary overhead". I personally don't agree with 
them and just wish everyone would go yang. That's also why I have doubts 
about supporting XSD.

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Oct 2012 08:05:57 -0700

Your customer has engineers that prefer to author
data models in XSD?  Have they actually done this
or it's all future work?

The NETCONF WG failed miserably trying to get anybody
to use XSD for NETCONF.  That's why YANG got started
in the first place.  XSD cannot even distinguish which nodes
are writable vs read-only, except with proprietary annotations.

I don't see any evidence that YANG is a mistake and we should
have stuck with XSD.  Quite the opposite.  IMO YANG will
probably be around a lot longer than NETCONF.

Andy

On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak <[email-masked]>wrote:

> These specific customers are probably developing a NETCONF server and want
> to avoid using YANG to model their content. I think they started off with
> XSD and want to keep it that way.
>
> We could probably manually create YANG based on their XSD, but that would
> not solve the problem in general. As far as I know XSD->YANG conversion is
> not trivial to implement so it can't cover every case. It would probably
> require heavy user interaction or some sort of annotations in the XSD
> itself. Such a tool would be quite useful though.
>
> thought YANG was "unnecessary overhead". I personally don't agree with them
> and just wish everyone would go yang. That's also why I have doubts about
> supporting XSD.
>
> Jernej
>
>
>> Thanks,
>>   Phil
>>
>
> ______________________________**_________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Oct 2012 17:19:28 +0200

> are writable vs read-only, except with proprietary annotations.

I think it's mainly (stupid) company rules - "We use industry standards". In management circles, XSD has somehow been able to live long past its clinical death.

> probably be around a lot longer than NETCONF.

+1.

Lada

> 
> 
> Andy
> 
> 
> 
> On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak <[email-masked]> wrote:
> These specific customers are probably developing a NETCONF server and want to avoid using YANG to model their content. I think they started off with XSD and want to keep it that way.
> 
> We could probably manually create YANG based on their XSD, but that would not solve the problem in general. As far as I know XSD->YANG conversion is not trivial to implement so it can't cover every case. It would probably require heavy user interaction or some sort of annotations in the XSD itself. Such a tool would be quite useful though.
> 
> I've actually seen people ditching NETCONF entirely, simply because they thought YANG was "unnecessary overhead". I personally don't agree with them and just wish everyone would go yang. That's also why I have doubts about supporting XSD.
> 
> Jernej
> 
> 
> Thanks,
>   Phil
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Oct 2012 08:27:46 -0700

On Thu, Oct 25, 2012 at 8:19 AM, Ladislav Lhotka <[email-masked]> wrote:

> I think it's mainly (stupid) company rules - "We use industry standards".
> In management circles, XSD has somehow been able to live long past its
> clinical death.
>
>
If they already use XSD and know it, then it is not stupid.
But even XSD folks have moved on to RelaxNG so it
does seem that XSD is on its way out.

This is just the usual business decision about when
to update your technology.  (One sign is when you
can't find any vendors who want to support your
technology anymore.  ;-)

 Andy

> want to avoid using YANG to model their content. I think they started off
> with XSD and want to keep it that way.
> >
> would probably require heavy user interaction or some sort of annotations
> in the XSD itself. Such a tool would be quite useful though.
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Oct 2012 17:43:36 +0200

On Thu, Oct 25, 2012 at 04:25:56PM +0200, Jernej Tuljak wrote:
> 
> I've actually seen people ditching NETCONF entirely, simply because
> they thought YANG was "unnecessary overhead".

Any insights what people use who ditch NETCONF because they do not
like learning YANG? (I assume it is the learning curve that scares
people/organizations, I have a hard time to imagine that an engineer
who started writing YANG modules ever wants to go back to XSD - but
I am of course biased.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Oct 2012 09:06:24 -0700

> who started writing YANG modules ever wants to go back to XSD - but
Perhaps they mean that the whole data abstraction thing
is too much overhead.  There are many protocols (proprietary
and standard) which couple a data model to a protocol.

SNMP and NETCONF do not do that.  The protocol data
is defined separately in modules with a formal language.
The added value wrt/ tool automation that is gained by
using a formal language and framework may not be obvious.

/js

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 25 Oct 2012 14:24:23 -0400

>annotations in the XSD itself. Such a tool would be quite useful though.

Definitely not idea, and given the number of variation for representing
data, likely custom work.

>them and just wish everyone would go yang. That's also why I have doubts 

The key idea would be that XSD models a document, where YANG models
a hierarchical database that can be presented as a document, but can
be manipulated with NETCONF.  Any key (to me at least) is that one
can share infrastructure between the CLI and NETCONF to reduce
the cost of maintenance.

Thanks,
 Phil

---

From: David Torre <[email-masked]>
Date: Fri, 26 Oct 2012 16:58:07 +0000

For me, I suppose question is not whether YANG is "better" than XSD but when manufacturers will support it, correct? 

I read the RFCs some time ago, and it seems the YANG modules need to be "compiled" onto the device. It seems today mfgs like Cisco/Juniper only support XSDs, no?

David Torre
Owner, Atomic Fission
www.atomicfission.com

________________________________________
From: [email-masked] [[email-masked]] on behalf of Phil Shafer [[email-masked]]
Sent: Thursday, October 25, 2012 11:24 AM
To: Jernej Tuljak
Cc: Netconf
Subject: Re: [Netconf] A data modeling question

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 26 Oct 2012 13:20:11 -0400

David Torre writes:
>I read the RFCs some time ago, and it seems the YANG modules need to be "compiled" onto 
>the device. It seems today mfgs like Cisco/Juniper only support XSDs, no?

We publish XSD files in a format that pre-dates YANG (and NETCONF),
but really really need to start publishing this info in YANG.  For
us, it's a matter of development bandwidth, but we hope to get
something out next year.

Thanks,
 Phil

---

From: David Torre <[email-masked]>
Date: Fri, 26 Oct 2012 21:39:59 +0000

>but we hope to get something out next year.

Looking forward to that...

For Juniper, I wind up paring down the junos.xsd / config-XX.xsd anyway given they're so incredibly massive. It would be awesome if I could just run JAXB across those definitions and get Java POJOs in return. I instead have to pick & choose various elements to build SRX and EX-specifc data models :-( 

The goal for me is to build a network management system that doesn't need to be "trained" on every new device, but instead, (dynamically) learns from the device itself-- be that an XSD, or some sort of "YANG capabilities exchange" etc. 

Regardless, eventual Juniper support for native YANG (or YIN) would be awesome. 

David Torre
Owner, Atomic Fission
www.atomicfission.com

________________________________________
From: Phil Shafer [[email-masked]]
Sent: Friday, October 26, 2012 10:20 AM
To: David Torre
Cc: Jernej Tuljak; Netconf
Subject: Re: [Netconf] A data modeling question

We publish XSD files in a format that pre-dates YANG (and NETCONF),
but really really need to start publishing this info in YANG.  For
us, it's a matter of development bandwidth

Thanks,
 Phil