Subject: Re: [netmod] 6020bis more than one revision of a module

From: Randy Presuhn <[email-masked]>
Date: Tue, 13 Oct 2015 13:22:28 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Oct 13, 2015 1:06 PM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] 6020bis more than one revision of a module
>
>On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote:
>> Hi -
>> 
>> >From: David Reid <[email-masked]>
>> >Sent: Oct 9, 2015 2:03 PM
>> >To: [email-masked]
>> >Subject: [netmod] 6020bis more than one revision of a module
>> >
>> >I'm reviewing 6020bis since it is in working group last call. 
>> >I see a new requirement that a server MUST NOT implement
>> >more than one revision of a module. I understand that supporting
>> >more than one revision can cause problems, but I expect that
>> >it will happen in practice. I know it happens sometimes with
>> >MIBs in SNMP. I think MUST NOT is too strong.
>> 
>> I've encountered the same phenomenon in the SNMP universe,
>> so if I expected Netconf to used as a replacement for SNMP
>> I'd have the same concern.
>>
>
>Perhaps you can detail what it means to support multiple revisions of
>a module at the same time. Are you saying YANG needs a way to slice
>modules such that for example interface ethernet0 can support revision
>X of an Ethernet data model while interface ethernet1 supports
>revision Y of an Ethernet data model?

This is a fairly typical situation.

>If so, support for per resource
>data model revision is not really part of YANG nor is it really part
>of NETCONF I think.

Yes.  I continue to consider this a fundamental deficiency, but
recognize that there seems to be little interest in the WG in
doing anything about it.

>(Note that YANG does support mechanisms such as
>features that allow to design data models in a way that they can be
>backwards compatible.)

That's adequate for device management, particularly for
single-vendor closed boxes, but not for configuration management,
and especially not for configuration management of open systems.
Again, I recognize that I hold a minority viewpoint, and the WG
has chosen a different path.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Oct 2015 15:07:40 -0700

On Tue, Oct 13, 2015 at 1:22 PM, Randy Presuhn <[email-masked]
> wrote:

> has chosen a different path.
This is a common situation, but not really a feature.
The foo-knob range is increased from 1 - 10 to 1 - 20.
Some new cards support 1 - 20 and some other cards only support 1 - 10.

There seems to be 3 solutions, none of which are very good:

1) document everything: return lots of
instance-level conformance information and expect the client
to sort it out

2) Advertise the newer version and let the client figure out
that some instances only allow 1 - 10

3) Advertise the older version and let the client figure out
that some instances allow 1 - 20.

YANG says to do (3).
This seems most correct to me.

> Randy

Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: David Reid <[email-masked]>
Date: Wed, 14 Oct 2015 11:24:18 -0400

> that some instances allow 1 - 20.

Where does YANG tell which version the server should advertise?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2015 08:33:41 -0700

> Where does YANG tell which version the server should advertise?

Not sure but advertising range 1 - 10 is safe since all instances support
that.

Presumably, the reason we advertise capabilities is so the client will
only try operations that it thinks the server supports.  The downside
for inaccuracy is either (2) false advertising or (3) under-advertising

-David Reid
Andy