Hi Acee,
Thanks for working on this, and the communications with the WG.
So far I haven't seen any objections. I'll request YANG doctor and RTG
directorate reviews.
Thanks,
Yingzhen
On Sat, Mar 8, 2025 at 8:16 PM Rahman <reshad=40yahoo....@dmarc.ietf.org>
wrote:
> Something similar was done with BFD YANG: similar problem and also lack of
> implementations.
>
> Sent from my iPhone
>
> > On Mar 8, 2025, at 11:28 PM, Acee Lindem <acee.i...@gmail.com> wrote:
> >
> > Thanks Rob!!!
> >
> > Yingzhen, Rob, Can we get early YANG doctor and RTG Directorate reviews?
> >
> > Thanks,
> > Acee
> >
> >> On Mar 7, 2025, at 4:00 AM, Rob Wilton (rwilton) <rwil...@cisco.com>
> wrote:
> >>
> >> Personally, I think that this is fine and pragmatic approach.
> >> If the VRRP YANG RFC was 5 years old or it was known that there were
> implementations then I would suggest we take a more cautious approach, but
> at this stage, just fixing it makes sense to me.
> >>
> >> Kind regards,
> >> Rob
> >> From: Acee Lindem <acee.i...@gmail.com>
> >> Date: Thursday, 6 March 2025 at 22:39
> >> To: YANG Doctors <yang-doct...@ietf.org>
> >> Cc: rtgwg@ietf.org <rtgwg@ietf.org>, net...@ietf.org <net...@ietf.org>,
> Rob Wilton (rwilton) <rwil...@cisco.com>
> >> Subject: Re: [rtgwg] IETF VRRP YANG Model with Inclusive Language -
> Proposal to Fix in Single Revision
> >> 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
> >
> >
> > _______________________________________________
> > netmod mailing list -- net...@ietf.org
> > To unsubscribe send an email to netmod-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
