Subject: Re: [netmod] module update rules

From: Randy Presuhn <[email-masked]>
Date: Sat, 19 Dec 2015 11:06:19 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Dec 19, 2015 12:07 AM
>To: Andy Bierman <[email-masked]>
>Cc: NETMOD WG <[email-masked]>
>Subject: Re: [netmod] module update rules
...
>IMO, 6020(bis) is not a good place for such rules because
> their applicability depends on the context. Backward
> compatibility is a matter of policies and, above all,
> sound judgement of module authors/publishers/vendors.

C'mon.  Can't we at least *pretend* to be doing configuration
management?  Being able to decide whether two things (schemata
or actual instances of configuration) are in some sense
the same, "compatible", or different is much too fundamental
to the problem space to be left to whim.

...
>> Vendors implement work-in-progress at their own risk.
>
>Yes, and that's why no vendor is very eager to do that.
> I actually think we should try harder to reduce the module
> churn already in the I-D phase, if possible.

SNMP dealt with this by not issuing the authoritative identifier
(the OID) until RFC publication, so anyone implementing the
work-in-progress did so in their own OID space.  Perhaps it
would be worthwhile to initiate a similar practice here.

>> IMO we should do a better job publishing RFCs on time,
>> and implement RFCs.
>
>But doing that means there is no way back - because of
> the update rules. We have to accept that even modules
>published in RFCs may need to be changed in ways that
> aren't permitted by sec. 10, based on feedback from
> implementations.

Why is that a problem?  If it turns out that the published
model is substantially flawed, then it seems that treating
the fixed module as a distinct entity is the right thing to
do.  Keeping the same name might help someone save face, but
it would in no way aid interoperability.  The basic idea is
that if one changes something too much, it becomes something
else.  This holds so often true in life that I'm surprised
that anyone would be surprised by this.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Dec 2015 12:11:54 -0800

> to the problem space to be left to whim.
Although I agree, we do try to set the bar high enough to
support deployments of mixed vendor and mixed revisions.
We try not to alter published APIs in a way that would break
an existing client implementation.  If one does not agree the bar
should be this high, then these rules get in the way.

...
> would be worthwhile to initiate a similar practice here.

That did not entirely help.
We would hack them in anyway.  RMON people broke OIDs
more than once (as you know ;-)

There actually is quite a lot of I-D implementation.
Those of us doing it know there will be lots of instability,
and therefore do not attempt to track every revision.
(Yes this leads to random snapshots out in the field,
and no, I don't want to replay the "WG snapshot" debate)

> that anyone would be surprised by this.

We had this same problem for MIB modules for a long time, and still
managed to updated published RFCs many times.

> Randy

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 13:17:34 +0100

> management?  Being able to decide whether two things (schemata

Actually, we are not doing only configuration management: for
state data the rules of sec. 10 are arguably useless.

> to the problem space to be left to whim.

Deciding whether a revision is compatible with a previous one is
possible – at least if compatibility means sec. 10 rules. However,
sec. 10 states that a new revision MUST NOT introduce incompatible
changes, ever. Such an absolute statement IMO doesn't make sense - we
have been violating it for most NETMOD modules, and it is probably no
different in other WGs. And if the rules are meant as a whip on rogue
vendors and their proprietary modules, then it certainly won't help
either.

> would be worthwhile to initiate a similar practice here.

It might be helpful to be able explicitly indicate the status of each
module, e.g. pre-alpha, alpha, beta, release-candidate, stable.

Some modules spend a long time in the I-D stage (ietf-routing was
started 57 months ago), so it doesn't tell much by itself.

> that anyone would be surprised by this.

Yes, if something changes too much. I don't think though that elementary
changes such as adding a single new mandatory leaf fall into this
category, yet they are not allowed per sec. 10 rules. It is not
reasonable to start a new module in such cases because the revision
history still provides valuable information, a new name and namespace
URI is needed etc. Such an abrupt change help neither old clients nor
anybody else.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Dec 2015 15:47:24 +0100

I believe the model we have agreed on in RFC 6020 is this:

- YANG modules in I-Ds are 'development' modules and not 'published'
  modules.

- It helps a lot during module development if 'development' modules
  are actually implemented. Note that implementations of 'development'
  modules are not intended to be 'deployed'.

- A 'published' module (something appearing in an RFC in the IETF)
  will be subject to YANG update rules.

- 'Published' modules are expected to be 'implemented' and 'deployed'.

- IETF WGs need to take care of the maintenance and interoperability
  of what has been 'published', hence the module update rules.

- Obviously, it is good to detect major flaws during 'development' and
  hence the importance of early 'implementation' experience.

Note that there are no formal module name or namespace assignements
until a module has been published as an RFC. A WG might put in a best
guess what the names might be but assignment and registration via IANA
happens during the publication process.

Perhaps it helps to clarify in RFC6020bis that the updates rules apply
to published modules and not to modules under development.

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 16:07:20 +0100

> On 21 Dec 2015, at 15:47, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Section 10 makes no distinction between development and published modules, except that for published modules a new "revision" statement MUST be included in front of the existing "revision" statements.

>  modules are not intended to be 'deployed'.

Absolutely, but this requires that development modules also carry revision information - otherwise clients won't be able to figure out the data model.

>  will be subject to YANG update rules.

Are you saying that other SDOs may adopt different rules, and that these rules don't apply to proprietary modules?

> to published modules and not to modules under development.

Yes, some clarification is needed in any case.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Dec 2015 07:37:22 -0800

Hi,

It seems rather fundamental that the members of a standards development
organization
understand the difference between a standard under development and a
standard
published for use.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Dec 2015 16:40:54 +0100

> Section 10 makes no distinction between development and published modules, except that for published modules a new "revision" statement MUST be included in front of the existing "revision" statemen…

And I noted in my email that we may have to make section 11 of RFC
6020bis more explicit.

> Absolutely, but this requires that development modules also carry revision information - otherwise clients won't be able to figure out the data model.

I am against regulating development or investing effort to deal with
interoperability of development modules. If someone has to distinguish
the stuff running in your labs, I am sure he/she will find a way to do
so.

> Are you saying that other SDOs may adopt different rules, and that these rules don't apply to proprietary modules?

I believe that it is generally up to the organization publishing
modules to define what is a 'published module' and what is a
'development module'. We can only reasonably define this for the
IETF.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Dec 2015 11:28:41 -0800

On Mon, Dec 21, 2015 at 7:40 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > On 21 Dec 2015, at 15:47, Juergen Schoenwaelder <
> > Section 10 makes no distinction between development and published
> modules, except that for published modules a new "revision" statement MUST
> be included in front of the existing "revision" statements.
> >
>
> > Absolutely, but this requires that development modules also carry
> revision information - otherwise clients won't be able to figure out the
> data model.
> >
>

I agree with you.
However, we do seem to aggressively extract YANG modules from documents and
then ignore the source document completely.
There is absolutely no way for a YANG compiler to tell the difference
between a module extracted from an Internet Draft from a module
extracted from an RFC.

There is no "module-status" statement in YANG.

   module-status draft;
   module-status published;

Perhaps this is overkill, but whining about module update rules
constantly is getting old.

Andy

> > Are you saying that other SDOs may adopt different rules, and that these
> rules don't apply to proprietary modules?
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Dec 2015 11:01:01 +0100

> between a module extracted from an Internet Draft from a module

This is a tool problem that is easy to solve (e.g., by storing
published modules separately from other modules).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 11:35:39 +0100

> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> That's why the definition what 'published' means in the IETF is in the
>>> guidelines document. On the other hand, since this is an IETF
>>> document, I also do not find it problematic to define IETF rules
>>> here. Others should be able to skip over this. There are really more
>>> important problems to solve.
>> 
>> It is not clear at all from sec. 10 that data modellers outside IETF may skip over this. I am not even sure that everybody in this WG agrees with your interpretation.
>> 
> 
> You are wrong.
> 
> - Section 10 in RFC 6020 applies to all published modules.

The bullets specifying the rules are introduced with this sentence:

'A definition may be revised in any of the following ways:'

so IMO it is intended to apply to *all* modules. Are you saying that it actually means

'A definition in a module published by IETF may be revised in any of the following ways:'?

> 
> - The definition of what turns a module into a published module is
> specific to the different organizations publishing modules.

So it means that such an organization may also decide to ignore the rules entirely or replace them with its own rules.

If the WG can agree on this and make the corresponding changes in sec. 11 of 6020bis, then I have no more objections.  

Lada

> 
> - For the IETF, the definition is publication as an RFC. I do not care
> whether this definition is in RFC 6020bis or RFC 6087bis.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Dec 2015 16:06:56 +0100

> 'A definition in a module published by IETF may be revised in any of the following ways:'?

A definition in a published module may be revised [...]

> So it means that such an organization may also decide to ignore the rules entirely or replace them with its own rules.

No.

> If the WG can agree on this and make the corresponding changes in sec. 11 of 6020bis, then I have no more objections.

The rules are there to ensure interoperability. Interoperability is an
issue for published modules (but not for modules under development).
The IETF certainly has a history to care about interoperability. I
expect that other organizations care about interoperability as well.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 16:23:44 +0100

> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <[email-masked]> wrote:
> 

This doesn't make much sense unless you give an objective definition of "published". For example, are proprietary modules (developed by vendors) ever published?

> expect that other organizations care about interoperability as well.

That's their business.

Lada

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 22 Dec 2015 10:24:41 -0500

> On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
> 

	And that is the point I made the other day. Simply saying that definition is The IETF’s
definition forms a rather circular argument.

	—Tom

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Dec 2015 07:51:56 -0800

On Tue, Dec 22, 2015 at 7:24 AM, Nadeau Thomas <[email-masked]>
wrote:

> >> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <
> >>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <
> >>>>> It is not clear at all from sec. 10 that data modellers outside IETF
> may skip over this. I am not even sure that everybody in this WG agrees
> with your interpretation.
> >>>>>
> >>>>
> >>>> You are wrong.
> >>>>
> >>> So it means that such an organization may also decide to ignore the
> rules entirely or replace them with its own rules.
> >>>
> >>
> >> No.
> >>
> >>> If the WG can agree on this and make the corresponding changes in sec.
> 11 of 6020bis, then I have no more objections.
> >>
> > This doesn't make much sense unless you give an objective definition of
> "published". For example, are proprietary modules (developed by vendors)
> ever published?
>

Each SDO may have its own definition of work-in-progress vs
published-for-use.
It doesn't seem that hard to figure out without help from the IETF.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Dec 2015 16:53:56 +0100

> This doesn't make much sense unless you give an objective definition of "published". For example, are proprietary modules (developed by vendors) ever published?

This has to be late binding - an organization publishing modules will
have to define what 'publishing' means for them and they will have to
decide whether they publish anything at all.

/js

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 22 Dec 2015 11:35:22 -0500

> On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	So that is exactly what I was suggesting the document’s text
be changed to.  At the present time it refers to the IETF’s process
only.

	—Tom

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Dec 2015 08:55:02 -0800

On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas <[email-masked]>
wrote:

>
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <
> >>>>>> It is not clear at all from sec. 10 that data modellers outside
> IETF may skip over this. I am not even sure that everybody in this WG
> agrees with your interpretation.
> >>>>>>
> >>>>>
> >>>>> You are wrong.
> >>>>>
> >>>> If the WG can agree on this and make the corresponding changes in
> sec. 11 of 6020bis, then I have no more objections.
> >>>

I know -- I added issue #25 4 days ago:
https://github.com/netmod-wg/rfc6087bis/issues/25

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 22 Dec 2015 13:52:13 -0500

thx!

> On Dec 22, 2015:11:55 AM, at 11:55 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>>
> https://github.com/netmod-wg/rfc6087bis/issues/25 <https://github.com/netmod-wg/rfc6087bis/issues/25>
> 
>  
> 
>         —Tom
> 
> 
> 
> 
> Andy
> 
>  
> >
> > /js
> >
> > --
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 22:57:35 +0100

> On 22 Dec 2015, at 16:53, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Right. Should there ever be any malcontents who are not happy with those rules, here is a recipe: they can provide the modules to their customers instead of publishing them. And W3C could just recommend their modules.

Lada