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. ... >> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
