Obsoletes is probably the best status.
(For the Working Group)
Mahesh is tracking this work in github:
https://github.com/mjethanandani/rfc9127-bis/
<https://github.com/mjethanandani/rfc9127-bis/>
I've opened an issue for this.
-- Jeff
> On Dec 7, 2021, at 9:14 AM, Reshad Rahman <res...@yahoo.com> wrote:
>
> Should RFC9127-bis obsolete RFC9127?
>
> Regards,
> Reshad.
>
> On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <jh...@pfrc.org>
> wrote:
>
>
> Working Group,
>
> While some explanation is required, the request to the Working Group is very
> simple: Please review this minor update to the recently published BFD YANG
> module and offer your comments whether we should head to rapid publication.
>
> This last call ends 20 December.
>
> ---
>
> The history:
> This module defines a YANG grouping, "client-cfg-parms". The intent of that
> grouping is to provide a common user experience in IETF YANG modules that
> want to use BFD. It provides a consistent set of leaf nodes that can be
> used by those client protocols so you don't have to remember whether
> it's "enable" or "enabled", what a multiplier is called, and where the
> timers live.
>
> This grouping is currently present in the RIP YANG model. It is also in the
> RFC Editor's queue for the PIM, OSPF, and ISIS modules. The BGP model
> intends to use this grouping.
>
> A small issue was noted shortly after publication that even though the
> grouping is correct, its structure in RFC 9127 was awkward for
> implementations that do not use per-client configuration of BFD parameters.
>
> Using the YANG tree for ietf-bfd-mpls included in the module from the -bis,
> consider the following:
> | +--rw enabled? boolean
> | +--rw local-multiplier? multiplier
> | +--rw (interval-config-type)?
> | | +--:(tx-rx-intervals)
> | | | +--rw desired-min-tx-interval? uint32
> | | | +--rw required-min-rx-interval? uint32
> | | +--:(single-interval) {single-minimum-interval}?
> | | +--rw min-interval? uint32
>
> There are two commonly deployed styles of BFD provisioning in the industry:
> - Fully centralized. In this case, BFD clients only need to indicate that
> they have "enabled" BFD to be used in that case. The sessions are
> configured at global scope. (E.g. "protocols bfd")
> - Per-client configuration. In this case, the client will also want to
> indicate that it supports local configuration of parameters such as the
> multiplier, and intervals.
>
> In the current structure of RFC 9127, an implementation that uses fully
> centralized mode will need to create a YANG deviation for each use of BFD's
> client-cfg-parms. While this was considered acceptable during the original
> drafting of the grouping in the BFD YANG module, current practices have
> evolved.
>
> The fix, and the very small change to RFC 9127 in this -bis, is to add a new
> YANG feature, "client-base-cfg-parms", and take the client configuration
> parameters and predicate it on that feature.
>
> This small change permits all of the client YANG modules listed above to
> inherit this feature behavior with no changes to those client modules.
>
> The following section from 9127-bis states the change as well:
>
> : Updates since RFC 9127
> :
> : This version of the draft updates the 'ietf-bfd-types' module to
> : define a new feature called 'client-base-cfg-parms and a 'if-feature'
> : statement that conditionally includes definition of parameters such
> : as 'multiplier' or 'desired-min-tx-interval'. The feature statement
> : allows YANG implementations of protocol such as OSPF, ISIS, PIM and
> : BGP, to support both a model where such parameters are not needed,
> : such as when multiple BFD sessions are supported over a given
> : interface, as well as when they need to be defined per session.
>
> -- Jeff
>
> ----- Forwarded message from internet-dra...@ietf.org
> <mailto:internet-dra...@ietf.org> -----
>
> Date: Tue, 07 Dec 2021 04:26:39 -0800
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> Cc: rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>
> Subject: I-D Action: draft-ietf-bfd-rfc9127-bis-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of the
> IETF.
>
> Title : YANG Data Model for Bidirectional Forwarding
> Detection (BFD)
> Authors : Reshad Rahman
> Mahesh Jethanandani
> Lianshu Zheng
> Santosh Pallagatti
> Greg Mirsky
> Filename : draft-ietf-bfd-rfc9127-bis-00.txt
> Pages : 70
> Date : 2021-12-06
>
> Abstract:
> This document defines a YANG data model that can be used to configure
> and manage Bidirectional Forwarding Detection (BFD).
>
> The YANG modules in this document conform to the Network Management
> Datastore Architecture (NMDA) (RFC 8342).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/
> <https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/>
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00>
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ----- End forwarded message -----
>
