> On 18 Dec 2015, at 18:00, Andy Bierman <[email protected]> wrote: > > > > On Fri, Dec 18, 2015 at 8:32 AM, Ladislav Lhotka <[email protected]> wrote: > > > On 18 Dec 2015, at 17:06, Andy Bierman <[email protected]> wrote: > > > > > > > > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <[email protected]> wrote: > > Hi, > > > > if we want people to take YANG modules appearing in I-Ds seriously and > > implement them, then we should apply the revisioning rules to them. That > > is, if a module changes between two I-D revisions, then its revision-date > > has to be bumped and a new entry added to the revision history. As it is > > now, the I-D-based modules are esentially revisionless. > > > > > > > > The revision rules only apply to published modules. > > Update rules of sec. 10 offer no such excuse. > > > That is a flaw in the draft
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. > > > > > In IETF-speak, that means an RFC. An Internet Draft > > is a work-in-progress. We update the revision date every time > > the module changes, but the numerous incremental changes > > for a work-in-progress should not be recorded in the module > > revision history. They should be recorded in the Change Log appendix. > > Revision numbers are critical for interoperability. If we want vendors to > implement modules such as ietf-routing now, the revisions must be solid and > reliable. > > > 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. > 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. > > > > > > > I will try to make this procedure more clear in the YANG guidelines draft. > > I think it should be the other way around: YANG spec should not contain the > update rules (because we all ignore them for I-D-based modules, right?), but > the IETF guidelines should specify the policy you describe. > > > This is a closed issue in YANG 1.1 You said there was a flaw in the draft. Lada > > > Lada > > > > Andy > > > > > > > > > > Lada > > > > > > Andy > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
