Subject: Re: [netmod] enumeration type

From: Randy Presuhn <[email-masked]>
Date: Sat, 25 Jan 2014 10:38:19 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Jan 24, 2014 11:53 PM
>To: B Lukovic <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] enumeration type
...
>In Berlin (IETF 87), I proposed to start work on a new YANG
>spec that would, among other things, remove such NETCONF dependences.

How quickly we forget lessons learned in the 1980's.

There's a seductive appeal to the idea of making the
data modeling language protocol independent, but the
reality is that both protocols and data modeling languages,
at least as a matter of usability, generally end up embodying
assumptions about metamodel.  If you're careful and lucky,
you *might* get a spec appropriate for use with a set of
Netconf-ish protocols, and perhaps a set of specs for how
this new Yang maps to the service definitions of each of
those protocols.  Doing this "right" requires thinking
about both what the metamodel really is, and what the core
supporting protocol services need to be.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jan 2014 11:02:57 -0800

> supporting protocol services need to be.
Good point -- not just because I do not want to work a new
YANG version :-) -- the only reason RESTCONF works with YANG
is because it borrows the NETCONF context roots (datastore,
rpc input/output, notification), so all the validation rules are the same.

> Randy

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Jan 2014 20:04:22 +0100

> supporting protocol services need to be.

Well, the fact of the matter is that YANG is already being used for non-NETCONF protocols (and a non-XML encoding). Those who do so have to pretend they know what each constraint means, and this is of course a slippery slope.

I do believe the potential of YANG goes beyond NETCONF. IMO, a meta-model should no be too difficult to derive: one or more hierarchical data trees, R/O and R/W data, RPCs and notifications.

Lada 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Jan 2014 20:09:32 +0100

On 25 Jan 2014, at 20:02, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn <[email-masked]> wrote:
> Hi -
> 

This is not true:

   o  If the constraint is defined on state data, it MUST be true in a
      reply to a <get> operation without a filter.

Where in RESTCONF can I find a reply to a <get> operation without a filter?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jan 2014 11:15:09 -0800

> Where in RESTCONF can I find a reply to a <get> operation without a filter?
You are being kind of literal.
A developer might guess GET.
As for "using an encoding other than XML", we are using the
YANG to JSON mapping you wrote.

How can we make sure that the NETMOD charter is updated
(if RESTCONF is approved for NETCONF) so that the YANG to JSON
mapping RFC must also be chartered? RESTCONF has a normative
reference to this draft.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Jan 2014 20:39:43 +0100

> A developer might guess GET.

Yes, and I2RS folks might guess something else. Validity has to do with certain data trees rather than particular methods for retrieving the data. We should be able to define it in a generic way, I don’t think there is any rocket science involved.

> YANG to JSON mapping you wrote.

Right, but it is not very straightforward and easy to grasp for newcomers. I think the JSON encoding should eventually be integrated into the YANG spec as an alternative to XML.

> mapping RFC must also be chartered? RESTCONF has a normative

I hope it will be chartered.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 25 Jan 2014 22:57:57 +0100 (CET)

Randy Presuhn <[email-masked]> wrote:
> assumptions about metamodel.

I fully agree.

But the idea is not to try to make YANG a protocol-independent
modelling languge.  The idea is "just" to separate the
protocol-specific parts from the language.

The idea with RESTCONF (separate thread...) is to do this - design a
new protocol that is compatible with the (implict) meta-model of
NETCONF and YANG.

But I also agree that it is not obvious that it can be done, and still
be useful.

> If you're careful and lucky,

Again I fully agree.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jan 2014 14:00:22 -0800

...
> Yes, and I2RS folks might guess something else. Validity has to do with
> certain data trees rather than particular methods for retrieving the data.
> We should be able to define it in a generic way, I don’t think there is any
> rocket science involved.
>
>
The term <get> could easily be replaced by "retrieval".
I think I2RS can figure that out, but we can worry
about that if the issue ever comes up for real.

> Right, but it is not very straightforward and easy to grasp for newcomers.
> I think the JSON encoding should eventually be integrated into the YANG
> spec as an alternative to XML.
>
>
Republishing RFCs just to move stuff around is expensive and the
IETF can't really afford the resources to do that.  A newcomer
reading RESTCONF will see where to find the JSON encoding rules.

Andy

---

From: B Lukovic <[email-masked]>
Date: Sat, 25 Jan 2014 17:13:35 -0500

This is interesting discussion but subject line is misleading.

      Borislav

On 1/25/2014 5:00 PM, Andy Bierman wrote:
>     Yes, and I2RS folks might guess something else. Validity has to do
>     with certain data trees rather than particular methods for
>     retrieving the data. We should be able to define it in a generic
>     way, I don’t think there is any rocket science involved.
>
>
>     Right, but it is not very straightforward and easy to grasp for
>     newcomers. I think the JSON encoding should eventually be
>     integrated into the YANG spec as an alternative to XML.
>
>