On Sat, Dec 19, 2015 at 11:06 AM, Randy Presuhn < [email protected]> wrote:
> Hi - > > >From: Ladislav Lhotka <[email protected]> > >Sent: Dec 19, 2015 12:07 AM > >To: Andy Bierman <[email protected]> > >Cc: NETMOD WG <[email protected]> > >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. > > 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. ... > >> 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. > > 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) > >> 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. > 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 protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
