> On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman <[email protected]> wrote:
>
>
>
> On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <[email protected]
>> <mailto:[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.
>> 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.
>>
>> I will try to make this procedure more clear in the YANG guidelines draft.
>
> The question is one of “published”. So at the IETF that means an RFC
> today, but Lada makes a good point in that in our new rapid development
> environment we may never get to RFCs for most of the models being worked
> on today - or not for some time. If we want those I-Ds to be used in
> production, it might make sense to define an I-D as “published”.
>
> As I pointed out earlier, for other organizations, they have different
> definitions of “published”, so we should consider a more flexible definition
> of
> “published” to encompass those. Its probably not a big deal to just say
> something like, “other organizations that define models will define their
> own definition of stable/published, and in those cases, that will
> suffice as the threshold for a version and following the updating
> rules described herein."
>
>
> I think we should just try to focus on our own standards development process.
> Other organizations can adopt or reject IETF practices if they want.
> We are using the same definition of published for about 25 years.
> It means RFC in our process. In a vendor environment, it means modules
> released to customers.
>
> We don't have a rapid development environment in the IETF.
> If people want to implement half-baked YANG modules, that is their business.
> They should be commended if they actually provide implementation feedback
> into the RFC, but a work-in-progress is not a published module.
That isn’t the point; the rest of the Yang universe looks to the IETF
to standardize and manage the Yang lanague and also looks here
for rules or best practices on building modules.
—Tom
>
>
>
> —Tom
>
>
> Andy
>
>
>
>>
>>
>>
>> Lada
>>
>>
>> Andy
>>
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://www.ietf.org/mailman/listinfo/netmod>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://www.ietf.org/mailman/listinfo/netmod>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
