Subject: Re: [netmod] how to know which module revision an RPC is for?

From: Kent Watsen <[email-masked]>
Date: Mon, 3 Jan 2011 11:43:10 -0800

> It depends on what "break in compatibility" means. 

I think we all know it means that some aspect of an existing client integration stops working.

> Which text in section 10 of RFC 6020 makes you believe that removing
> "mandatory" is allowed?

Section 10 says: a "mandatory" statement may be removed or changed from "true" to "false".  Please see my 12/30@2:06 email for how this makes sense for inputs but not outputs...

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Jan 2011 14:29:31 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> Hi Andy,
> 
> 
> > You can add a leaf to the input for the client to request
> > a specific version.
> 
> I don't understand, can you provide an example?   Oh, wait, do you
> mean that the payload of the RPC itself would have a <revision>
> element?

I think often you can add a more explicit parameter to the input,
e.g. if the new revision added a field <status> to the output, you can
add an input field <send-status/> to let the client indicate that it
supports the new version.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Jan 2011 14:36:57 +0100 (CET)

Hi,

> Other concerns not yet addressed:
> 
> 1. unclear how "obsolete" status can ever be used (as to do so would break
>    backwards compatibility)

I agree with Juergen and Andy.  A robust client that sees a new
revision it does not understand will have to be prepared that some
nodes are obsolete and thus not implemented on the server.

This is of course something that has to be taken into account when
obsoleting an object.

> 2. missing clarification that removing a "mandatory" statement is only allow
>    for inputs (RPCs and config)

I think you are right that this is a bug in the spec.

> 3. missing clarifying statement that clients must skip over unrecognized
>    elements in a response

I don't think we can mandate that a client MUST skip over unrecognized
elements.  Maybe SHOULD.  But this would be a clarification; it more
or less follows from the text that a client should do this.  Being
explicit is of course good.

> 4. no expiration policy (or are implementations to be forever backwards
>    compatible?)

If your product implements an RFC with an obsolete object, you are
"allowed" to removed the object from your implemenation.  Your
customers may not like it though, but then it's a business decision if
you remove the object anyway :)

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Jan 2011 15:13:00 -0800

> This is of course something that has to be taken into account when

We have to treat inputs and outputs separately.

For outputs, like RPC-Reply or Notifications, I agree that a client needs to be prepared that a 'non-mandatory' node may be obsoleted.  On the other hand, 'mandatory' output nodes can never be obsoleted (at least not without a deprecation policy), as doing so may break interoperability with existing clients.

For inputs, like RPC and Configuration, though I agree that mandatory nodes can be deprecated, I don't believe that deprecated nodes can ever be obsoleted (at least not without an expiration policy), as doing so may break interoperability with existing clients.

> I think you are right that this is a bug in the spec.

Great! - so do we start 6070bis?

> explicit is of course good.

Yes, an explicit statement would be a very good as YANG's versioning strategy depends on it...

> you remove the object anyway :)

OK, there may be scenarios where it comes to that, but I'm talking about the much more benign cases:

  1. obsoleting inputs long since deprecated.  This would allow the server to remove
     the legacy code needed to support the deprecated node

  2. obsoleting a 'mandatory' output.  This would allow the server to remove some
     special code it may have implemented just to generate a required value

In both these cases, clients can be gracefully migrated off time presumably supported input or output via a temporal policy (i.e. a 1-year grace period).  Case in point, given the choice between breaking clients and having to bend over backwards for a finite amount of time, Juniper will likely bend over every time.  We simply cannot afford to break interoperability with clients, and yet we don't want to have cruft in our code forever either.  An "expiration strategy" for deprecated inputs and an "deprecation strategy" for mandatory outputs would be very welcomed enhancement to YANG's versioning strategy.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Jan 2011 16:45:10 -0800

Hi,

I have a problem with changing 6020 to say a client MUST do X Y Z with the reply.
There are no requirements at all on data 'exiting the protocol'.
Since the client does not have to use the reply to do more NETCONF protocol
interactions, there is nothing for the standard to say about what
the client does with an <rpc-reply>.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, January 12, 2011 3:13 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?)

Thanks,
Kent

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Jan 2011 16:55:47 -0800

Is this response to #3 or #4?   If #3, it's OK if it's a SHOULD, as Martin suggested.  If #4 then it looks like 6020 has painted itself into a corner...

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, January 12, 2011 7:45 PM
To: Kent Watsen; Martin Bjorklund
Cc: [email-masked]
Subject: RE: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?)

Hi,

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, January 12, 2011 3:13 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?)

> I think you are right that this is a bug in the spec.

Great! - so do we start 6020bis?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Jan 2011 17:13:13 -0800

Hi,

It is for #3.

Per #4:  One might ask if we have any obsolete SNMP objects
(standard or proprietary) and if so, how did it work out?

I see ipForwardTable in RFC 4292 is obsolete.

It seems reasonable to me to have IETF guidelines that an object
must be at status 'deprecated' for a year or 2 before it can move to 'obsolete'.

I don't think different policies for different types of objects
is needed.  If you don't have the current schema, there might be
nodes of any type changed to obsolete since the version you know about.
This is OK.  You cannot apply your contract for last year's model
to this year's model.  You need to read the new contract.

Andy

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, January 12, 2011 7:45 PM
To: Kent Watsen; Martin Bjorklund
Cc: [email-masked]
Subject: RE: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?)

Hi,

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, January 12, 2011 3:13 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?)

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jan 2011 09:07:35 +0100

> must be at status 'deprecated' for a year or 2 before it can move to

Most RFCs spin very slowly and I would first of all trust the WGs
responsible for them that they know best when it is appropriate to
obsolete a definition. I think we should only add more rules if we
have evidence that there is a problem to be fixed.

/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: Kent Watsen <[email-masked]>
Date: Thu, 13 Jan 2011 06:29:08 -0800

> have evidence that there is a problem to be fixed.

This isn't just about IETF-defined modules; YANG is used to define 3rd-parties data-models as well

If we don't want to provide an ability to deprecate a 'mandatory' output element, then perhaps we should disallow any output value from being marked 'mandatory' in the first place - at least then servers can deprecate them with impunity.

BTW, my other point, that deprecated input values can never being obsoleted, equally applies to IETF-defined modules.  But let's be clear, this isn't about being able to deprecate input elements, this is about vendors not being able to safely remove the support for deprecated input elements - see the distinction?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jan 2011 16:00:20 +0100

> This isn't just about IETF-defined modules; YANG is used to define 3rd-parties data-models as well

I do not think the IETF can effectively define rules how other
organizations deprecate or obsolete definitions.

[...]

> BTW, my other point, that deprecated input values can never being
> obsoleted, equally applies to IETF-defined modules.  But let's be
> clear, this isn't about being able to deprecate input elements, this
> is about vendors not being able to safely remove the support for
> deprecated input elements - see the distinction?

I believe there are big differences in deployment scenarios. In some
environments, software gets regularly updated, in other environments
this happens much less frequently or in some only when boxes are
replaced. Is it realistic to find concensus on a universal time span
that works well for all YANG modules in all possible deployments?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Jan 2011 12:40:25 -0800

> On Thu, Jan 13, 2011 at 06:29:08AM -0800, Kent Watsen wrote:

Juergen is right.

IMO, the WG has already addressed this problem with <get-schema>
(implemented in yuma, BTW).

The old contract does not apply to servers which do not
claim to support that version of the contract. Period.
Get the new contract and check if the old features you need
are still in it.

IETF objects will follow strict rules.
It may be easy to obsolete something if there are few implementations.
It will have to be on a case-by-case basis, like MIB objects.

Andy