> On 18 Dec 2015, at 19:42, Martin Bjorklund <m...@tail-f.com> wrote: > > Ladislav Lhotka <lho...@nic.cz> wrote: >> >>> On 18 Dec 2015, at 17:06, Andy Bierman <a...@yumaworks.com> wrote: >>> >>> >>> >>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <lho...@nic.cz> 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. > > It says: > > For any published change, ...
Well, sec. 10 (and 11 in 6020bis) only says: "For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements." The update rules aren't conditional in any way. Lada > > > I agree w/ Andy that 6087bis could clarify what this means in terms of > IETF. > > > /martin > > >>> 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. >> >>> >>> 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. >> >> Lada >> >>> >>> >>> >>> Lada >>> >>> >>> Andy >>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
