Randy Presuhn <[email protected]> writes: > 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
Actually, we are not doing only configuration management: for state data the rules of sec. 10 are arguably useless. > 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. > 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. > ... >>> 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. 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. > >>> 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. 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 > > Randy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
