Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

[Martin Björklund <[e-mail]>]

Hi,

Jeffrey Haas <[e-mail]> wrote:
> Martin,
> 
> On Wed, Nov 10, 2021 at 09:18:14AM +0100, Martin Björklund wrote:
> > Hi,
> > 
> > First I want to make sure that I understand the proposal correctly.
> > 
> > A. Is it correct that you want to do a bis of 9127 so that you don't have
> > to touch the three (?) documents that are in AUTH48?
> 
> That my proposal.
> 
> > B. Is it ok to do modifications to the AUTH48-docs, as long as they
> > don't have to wait for a 9127-bis?
> 
> The preference is to not do this.  It'd cause an inconsistency in
> maintainance over the long term.
> 
> > With the proposal from Mahesh (define the "bfd" feature in bfd-types),
> > you either will have 4 versions of the "bfd" feature, or you would
> > have to modify the AUTH48-docs, AND have them wait for a 9127-bis (in
> > which case it would have been better to deprecate "client-cfg-parms"
> > and define a new grouping with the if-feature statements).
> 
> Understood.  It'd be ideal to not have to touch the AUTH48 documents.  That
> said, removing redundancy seems like it might be best if we must touch them
> at all.
> 
> > If you publish the AUTH48-docs and then publish a 9127-bis with a
> > modified "client-cfg-parms" as proposed, doesn't this mean that
> > implementations still have to wait for 9127-bis?  And if this is the
> > case, you could as well wait with all docs?
> 
> The intent is to fast track the -bis.  The diff is trivial.

Ok, but if you can fast-track the bis, is it still important to get the
AUTH48-docs out before the bis?


/martin