Adding YANG doctors...
Summary: I'm attempting to improve the pathetic IETF YANG model velocity by
fixing non-inclusive the ietf-vrrp.yang model in one RFC (remove) rather than
three (deprecate->obsolete->remove).
While some of the removals don't make the restrictive RFC 7950 backward
compatibility rules, there are no "config true" nodes removed and there are no
known implementations (although there is one open source implementation anxious
to develop the new version of the model).
Thanks,
Acee
> On Mar 4, 2025, at 1:33 PM, Acee Lindem <acee.lin...@gmail.com> wrote:
>
> After some conversations with Mahesh, I've reverted the draft to use the
> original YANG model name, vrrp.yang. Mahesh didn't feel using a different
> name to avoid backward compatibility concerns was a good approach.
>
> Consequently, I have republished the draft. Since the changes are to avoid
> the usage of non-inclusive language, I still feel this should be done in a
> single shot rather than the onerous deprecated->obsoleted->remove cycle
> requiring 3 RFCs rather than one. One could consider the use of non-inclusive
> language to be a "bug" that should just be fixed in a single revision.
>
> Note that none of the types, identifiers, or the notifications are "config
> true" so there really shouldn't be any problems. I've include the nodes have
> change below to illustrate this. Also, I don't know of any ietf-vrrp.yang
> implementations and this draft has existed in the RTGWG for more than a year.
>
> I'd like to more forward with this now rather than have a people who have
> never written a YANG model have come out to champion the very restrictive
> YANG backward compatibility rules very late in the publication cycle.
>
> Thanks,
> Acee
> 125a126,151
>> typedef new-master-reason-type {
>> status deprecated;
>> type enumeration {
>> enum not-master {
>> description
>> "The virtual router has never transitioned to master
>> state.";
>> }
>> enum priority {
>> description
>> "Priority was higher.";
>> }
>> enum preempted {
>> description
>> "The master was preempted.";
>> }
>> enum no-response {
>> description
>> "Previous master did not respond.";
>> }
>> }
>> description
>> "Indicates why the virtual router has transitioned to
>> master state.";
>> } // new-master-reason-type
>>
> 160a187,194
>> identity vrrp-event-master-timeout {
>> status deprecated;
>> base vrrp-event-type;
>> description
>> "Indicates that the current master has not sent an
>> advertisement within the limit of master-down-interval.";
>> }
>>
> 222a257,263
>> identity vrrp-event-lower-priority-master {
>> status deprecated;
>> base vrrp-event-type;
>> description
>> "Indicates that there is a lower-priority VRRP master.";
>> }
>>
> 327c368,377
> < /* vrrp-version identity and its derivatives. */
> ---
>> identity master {
>> status deprecated;
>> base vrrp-state-type;
>> description
>> "Indicates that the virtual router is forwarding
>> packets for IP addresses that are associated with
>> this virtual router.";
>> }
>>
>> /* vrrp-version identity and its derivatives. */
> 727a778,786
>> }
>> leaf master-down-interval {
>> status deprecated;
>> type uint32;
>> units centiseconds;
>> config false;
>> description
>> "Time interval for the backup virtual router to declare
>> 'master down'.";
> 751a811,818
>> leaf new-master-reason {
>> status deprecated;
>> type new-master-reason-type;
>> config false;
>> description
>> "Indicates why the virtual router has transitioned to
>> master state.";
>> }
> 771a839,845
>> leaf master-transitions {
>> status deprecated;
>> type yang:counter32;
>> description
>> "The total number of times that this virtual router's
>> state has transitioned to 'master'.";
>> }
> 965a1040,1052
>> }
>> }
>>
>> notification vrrp-new-master-event {
>> status deprecated;
>> description
>> "Notification event for the election of a new VRRP master.";
>> leaf master-ip-address {
>> status deprecated;
>> type inet:ip-address;
>> mandatory true;
>> description
>> "IPv4 or IPv6 address of the new master.";
> 966a1054,1061
>> leaf new-master-reason {
>> status deprecated;
>> type new-master-reason-type;
>> mandatory true;
>> description
>> "Indicates why the virtual router has transitioned to
>> master state.";
>> }
>
>
>> On Mar 2, 2025, at 8:57 PM, internet-dra...@ietf.org wrote:
>>
>> Internet-Draft draft-ietf-rtgwg-vrrp-rfc8347bis-01.txt is now available. It
>> is
>> a work item of the Routing Area Working Group (RTGWG) WG of the IETF.
>>
>> Title: A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
>> Authors: Acee Lindem
>> Xufeng Liu
>> Athanasios Kyparlis
>> Ravi Parikh
>> Mingui Zhang
>> Name: draft-ietf-rtgwg-vrrp-rfc8347bis-01.txt
>> Pages: 43
>> Dates: 2025-03-02
>>
>> Abstract:
>>
>> This document describes a YANG data model for the Virtual Router
>> Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are
>> covered.
>>
>> The VRRP terminology has been updated conform to inclusive language
>> guidelines for IETF technologies.
>>
>> This document obsoletes RFC 8347.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc8347bis/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-rtgwg-vrrp-rfc8347bis-01.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-rtgwg-vrrp-rfc8347bis-01
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> rtgwg mailing list -- rtgwg@ietf.org
>> To unsubscribe send an email to rtgwg-le...@ietf.org
>
> _______________________________________________
> rtgwg mailing list -- rtgwg@ietf.org
> To unsubscribe send an email to rtgwg-le...@ietf.org
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
