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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 5 Nov 2021 12:55:26 +0000

YANG Doctors,

We unfortunately have a bug in the BFD YANG Model that has just been published in RFC 9127.  Because this RFC has only just been published the expectation is that are no implementations of it yet.

The local-multiplier and interval-config-type configuration shown in the tree diagram below should be under an if-feature (explanation in the email below).  Adding an if-feature is classified as a change that is not allowed under RFC 7950 section 11.  The proposal is to quickly bis RFC 9127 and modify the BFD YANG Model to add in the two missing if-feature statements.  Although this violates the MUST statement in RFC 7950, I believe that this is pragmatically the right thing to do currently and is in line with the current direction of the versioning work in Netmod (if that work achieves consensus).

Note, we considered an alternative approach of deprecate these nodes and put those leaves under a new if-feature predicated container but doing this to a newly published module seems excessive.

Hence, are any of the YANG doctors opposed to the proposed approach of making the non-backwards-compatible change and just fixing the BFD YANG module?

We would like to please conclude on this quickly since the 3 protocol YANG modules (PIM, OSPF, ISIS) are all in Auth48 and we do not want to unduly delay publishing them.  Hence, if you have objections then please can you send them by Friday 12th November.  Emails supporting this approach would also be welcome.

Thank for your input.

Regards,
Rob

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: 04 November 2021 20:32
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>; Reshad Rahman <[email-masked]>; Mahesh Jethanandani <[email-masked]>
Subject: Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

[Many of you have gotten this in different contexts.  This email is at the ADs' request to make sure we're all on the same page.]

Background:
BFD is an IETF "plumbing protocol".  Much like other bits of YANG plumbing such as the routing-config model and the policy model, there's an incentive to consistently implement configuration state in each of the consumers of the feature.  Since the YANG set of modules from IETF is IETF's "CLI", consistency of user-experience is also helpful. 

The YANG grouping, client-cfg-parms in RFC 9127, was intended to provide this in any BFD client users. Many of those are IETF protocols that have YANG modules in progress.

Because implementors do things more than one way, there are two common models by which BFD is used:
- A "centralized" model, think "protocol bfd", where BFD sessions and their parameters are provisioned.  Client users simply say "bfd enabled" in their own configuration stanzas.  Cisco is an example of this model.
- Per-client users.  In this model, each client protocol configures BFD use AND also the session parameters such as timing.  Juniper is an example of this model.

Using the ISIS model as an example of how this grouping expands:

          +--rw bfd {bfd}?
          |  +--rw enable?                           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

In the centralized model, only the "enable" leaf is needed.  The other three leaves (max two depending on how the interval-config-type feature manifests) are only needed by the implementations supporting per-client configuration.

Problem Statement:
While resuming work on the BGP model, I noted that the above.  The concern I had was "what had we decided with regard to support each of these models?  Since it's been quite some time since this work was done in BFD, I'd forgotten the discussion and in somewhat of a panic, contacted Acee as an author of one of the impacted models to figure out what we should do.

I have a vague memory that this topic had come up in one of the last IETFs we were able to gather and my memory was that simply using per-vendor deviations on the per-client nodes was sufficient.  However, the popularity - or lack thereof - of deviations has changed over time.

Acee had proposed an update to the client use of the BFD configuration state to predicate the per-client leaves on an "if-feature".  His original proposal did this if-feature by moving the BFD base-cfg-parms grouping into a container.  

While discussing this with Rob, we realized that this was also a structural change of BFD in each of the impacted YANG models, which was problematic.  Minimally, we'd want the Working Groups to look at the changes to see if it's okay or not.  From discussions with Mahesh on BGP, another suggestion is to preserve the existing BFD structure, but add the necessary if-feature to the impacted local-multiplier leaf and the interval-config-type choice.  Acee seemed to think this might be reasonable.

The open question is how to keep the pipeline for RFCs moving quickly.  We have two options that have gotten discussion:

1. Update RFC 9127 with a quick -bis.  
Pros: Ship the existing Cluster 236 drafts with the work simply implementing "use client-cfg-parms", so no changes there.  Fix once in BFD, everyone benefits.
Cons: Rob and Alvaro raise an issue that the necessary change in the BFD model may violate YANG module maintenance rules.  Given how recent this RFC has shipped, this might be an exceptional case.  Also, there's apparently work in netmod about relaxing some of the restrictions we've created for ourselves.  This email is partially to seed some of that conversation.  

2. Take the expanded groupings and paste them with the necessary fix into each of the impacted models and -bis RFC 9127 at a less frantic pace.
Pros: Frees cluster 236 documents from further entanglement from a MISREF.  Doesn't depend on the IESG agreeing that adding a if-feature in 9127-bis is a no-no or not.
Cons: Copy and paste makes its own headaches.  If we do need to revise BFD, it might be a goal that we have positive impact on all impacted IETF BFD clients.

Observation: As long as we stay structurally the same in both options, a consistent user experience is maintained.  I'm personally okay with that aside from the maintenance issue.

My preference is option 1.  Get the -bis published and through our processes ASAP.

As noted in the attached diff to 9127, the core potion of a -bis document is trivial.  We'd just need some additional text to explain why we did the -bis.

-- Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Nov 2021 14:25:39 +0100

Hi Rob,

so is the plan to publish a new RFC that would obsolete 9127? I'd 
support it.

Lada

On 05. 11. 21 13:55, Rob Wilton (rwilton) wrote:
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 5 Nov 2021 13:31:59 +0000

Hi Lada,

Thanks for the quick response.

Yes, I think the plan would be to obsolete 9127.

Regards,
Rob

-----Original Message-----
From: Ladislav Lhotka <[email-masked]> 
Sent: 05 November 2021 13:26
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Cc: [email-masked]; Reshad Rahman <[email-masked]>; Jeffrey Haas <[email-masked]>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Hi Rob,

Lada

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Nov 2021 09:34:00 -0400

If we can proceed with the ideal plan, we'd just take the recently approved RFC, make the minimal changes for the issue, and hand it right back to them after trying to expedite usual IETF review process.

The review is mostly at the yang-doctor level, I believe.  A bit of informative text about what we've changed in an appendix entry is needed.

-- Jeff

> On Nov 5, 2021, at 9:25 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi Rob,
> 
> so is the plan to publish a new RFC that would obsolete 9127? I'd support it.
> 
> Lada
>

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 5 Nov 2021 19:26:18 +0000 (UTC)

Hi all,
I also support publishing a new RFC which would obsolete 9127.
Instead of adding if-feature and/or moving parms into a container, could we add a new grouping e.g. client-cfg-no-parms or client-cfg-enabled, for the centralized model? That grouping would only have the "enabled" leaf. AFAIK this would not violate YANG maintenance rules.
Jeff, we discussed the client BFD config when we gathered at IETF99 with the people involved in the various routing YANG models. My, also vague, recollection is that we had discussed deviations for this case.
Regards,Reshad.
    On Friday, November 5, 2021, 09:34:12 AM EDT, Jeffrey Haas <[email-masked]> wrote:  

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Nov 2021 15:30:12 -0400

Reshad,

Thanks for remembering what IETF that happened at.  It's been a while, and my memory isn't greatest at the best of times.

There's a good chance I'm misunderstanding your proposal, but if I do, it's not going to help the general case: We need to let clients have the option for either centralized-only (just the enabled leaf) or per-client and also have the multiplier and intervals.  "enabled" is a common feature for both centralized and per-client so I don't think a feature helps there.

If I'm misunderstanding you, please consider attaching a diff.

-- Jeff

> On Nov 5, 2021, at 3:26 PM, Reshad Rahman <[email-masked]> wrote:
> 
> Hi all,
> 
> Reshad.
> > On Nov 5, 2021, at 9:25 AM, Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Rob,
> > 
> >> From: Jeffrey Haas <[email-masked] <mailto:[email-masked]>>
> >> To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]>>
> >> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; Reshad Rahman <[email-masked] <mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 5 Nov 2021 19:42:02 +0000 (UTC)

Hi Jeff,
You didn't misunderstand. I incorrectly thought that we just wanted different clients (e.g. ISIS vs BGP) to choose centralized v/s per-client, but on re-reading we seem to need client implementations to choose (e.g ISIS vendor A v/s ISIS vendor B).
Regards,Reshad.
    On Friday, November 5, 2021, 03:30:17 PM EDT, Jeffrey Haas <[email-masked]> wrote:  
 
 Reshad,

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Nov 2021 19:44:28 +0000

Hi Reshad,

From: yang-doctors <[email-masked]> on behalf of Reshad Rahman <reshad=[email-masked]>
Reply-To: Reshad Rahman <[email-masked]>
Date: Friday, November 5, 2021 at 3:42 PM
To: Jeff Haas <[email-masked]>
Cc: Routing ADs <[email-masked]>, YANG Doctors <[email-masked]>, "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Hi Jeff,

Correct – and we certainly don’t want to the require deviations for the predominant implementations.

Thanks,
Acee

Regards,
Reshad.

Reshad,

-- Jeff

On Nov 5, 2021, at 3:26 PM, Reshad Rahman <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Regards,
Reshad.

On Friday, November 5, 2021, 09:34:12 AM EDT, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

> On Nov 5, 2021, at 9:25 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Rob,
>
>> From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
>> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Reshad Rahman <[email-masked]<mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 6 Nov 2021 00:06:04 -0400

Hi Reshad,

Mahesh Jethanandani
[email-masked]

> On Nov 5, 2021, at 3:26 PM, Reshad Rahman <reshad=[email-masked]> wrote:
> 
> 
> Hi all,
> 

The enabled flag does not exist in the base-cfg-params  grouping, and is needed for both the config options. With your logic, the non-centralized model/implementation will need to include both groupings and declare two features. 

Thanks

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 6 Nov 2021 19:39:11 +0000

Hi Mahesh,

From: yang-doctors <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Saturday, November 6, 2021 at 12:06 AM
To: Reshad Rahman <[email-masked]>
Cc: Jeff Haas <[email-masked]>, Routing ADs <[email-masked]>, "Rob Wilton (rwilton)" <rwilton=[email-masked]>, YANG Doctors <[email-masked]>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Hi Reshad,
Mahesh Jethanandani
[email-masked]

With Jeff’s diff, you’d still need two features. The base BFD feature which is in the protocol model and the bfd:client-cfg-parameters in the diff.

Thanks,
Acee

Thanks

Regards,
Reshad.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 7 Nov 2021 12:27:27 -0500

Hi Acee,

> On Nov 6, 2021, at 3:39 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Mahesh, 
>  
> From: yang-doctors <[email-masked] <mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> To: Reshad Rahman <[email-masked] <mailto:[email-masked]>>
> Cc: Jeff Haas <[email-masked] <mailto:[email-masked]>>, Routing ADs <[email-masked] <mailto:[email-masked]>>, "Rob Wilton (rwilton)" <rwilton=[email-masked] <mailto:rwilton=[email-masked]>>, YANG Doctors <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> 
> 
>> On Nov 5, 2021, at 3:26 PM, Reshad Rahman <reshad=[email-masked] <mailto:reshad=[email-masked]>> wrote:
>> 
>> Hi all,
>>  

[mj] Acee, I was merely trying to point out to Reshad that we may not need a separate grouping with just the ‘enabled’ flag called ‘client-cfg-no-parms” or ‘client-cfg-enabled’ as the ‘enabled’ flag is needed by both modes of operation. I am fine with Jeff’s diffs.

But since you bring it up, how about moving the base BFD feature definition from the protocol drafts into the BFD types definition file, so there is one single way to enable the feature, rather than each protocol defining their own feature definition?

Thanks.

>> On Friday, November 5, 2021, 09:34:12 AM EDT, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>  
Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 7 Nov 2021 18:56:20 +0000

Hi Mehesh,

From: Mahesh Jethanandani <[email-masked]>
Date: Sunday, November 7, 2021 at 12:27 PM
To: Acee Lindem <[email-masked]>
Cc: Reshad Rehman <[email-masked]>, Jeff Haas <[email-masked]>, Routing ADs <[email-masked]>, "Rob Wilton (rwilton)" <rwilton=[email-masked]>, YANG Doctors <[email-masked]>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Hi Acee,

On Nov 6, 2021, at 3:39 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mahesh,

From: yang-doctors <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 6, 2021 at 12:06 AM
To: Reshad Rahman <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>, Routing ADs <[email-masked]<mailto:[email-masked]>>, "Rob Wilton (rwilton)" <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Hi Reshad,
Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

On Nov 5, 2021, at 3:26 PM, Reshad Rahman <reshad=[email-masked]<mailto:reshad=[email-masked]>> wrote:
Hi all,

Sure.

Thanks,
Acee

Thanks.

Thanks,
Acee

Thanks

Regards,
Reshad.

-- Jeff

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Nov 2021 13:19:15 -0500

> On Nov 7, 2021, at 1:56 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> From: Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> 

The original diff I had sent out vs. the RFC was lost when the yang doctors were added.

Here's the diff again.  I think aside from adding appendix test and a little bit of word smithing, it's about all we need:

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 8 Nov 2021 10:49:26 -0800

Hi Jeff,

> On Nov 8, 2021, at 10:19 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> 
> 
>> On Nov 7, 2021, at 1:56 PM, Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> <rfc9127-bis-from-.diff.html>

All three protocol drafts (BGP, ISIS and OSPF, I did not check PIM) define their own feature statements for the base and for the client-cfg-parms in their own models. All I am suggesting is those feature definitions be moved into ietf-bfd-types YANG module as part of this update. But if the desire is to keep the change to the min, I am ok with it too.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Nov 2021 14:12:33 -0500

Mahesh,

> On Nov 8, 2021, at 1:49 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi Jeff,
> 
>> On Nov 8, 2021, at 10:19 AM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

My diff had it in that module.

Here's the full .xml for you to peruse.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 8 Nov 2021 12:01:13 -0800

Hi Jeff,

And here is the full set of diffs that I had in mind.

> On Nov 8, 2021, at 11:12 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 
>> On Nov 8, 2021, at 1:49 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Jeff,
>> 
> <rfc9127.xml>

Mahesh Jethanandani
[email-masked]

---

From: Rahman <[email-masked]>
Date: Mon, 8 Nov 2021 17:36:56 -0400

So that means that an implementation must choose 1 ‘mode’ for all its protocols which use BFD? I’m good with that.

Regards,
Reshad.

Sent from my iPhone

> On Nov 8, 2021, at 3:12 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Nov 2021 16:41:03 -0500

Ah, now I understand.  

I think that means the leaves that use client-cfg-parms would need to be if-feature bfd and if-feature client-cfg-parms.

The references would have to be RFC XXXX.

And perhaps if the namespacing isn't clear, perhaps the feature shoudl be bfd-client-cfg-parms.

Add the Appendix of "changes since RFC 9127" and I think we have a document. :-)

-- Jeff

> On Nov 8, 2021, at 3:01 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi Jeff,
> 
> <rfc9127-bis-diff.html>
>> On Nov 8, 2021, at 11:12 AM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Mahesh,
>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 8 Nov 2021 13:52:49 -0800

> On Nov 8, 2021, at 1:41 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Ah, now I understand.  
> 

That is correct.

> The references would have to be RFC XXXX.

Yes. I should have changed it to RFC XXXX instead of RFC 9127, as the latter does not have these feature definitions.

Sure.

>> On Nov 8, 2021, at 3:01 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Jeff,
>> 

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Nov 2021 15:36:58 -0500

Rob,

Did you want more than Lada to respond on this issue?  Or are you counting on him being the active voice and assuming some silent "I agree"?

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Wed, 10 Nov 2021 09:18:14 +0100 (CET)

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?

or,

B. Is it ok to do modifications to the AUTH48-docs, as long as they
don't have to wait for a 9127-bis?

If B is ok, you could modify the docs like this, without touching
RFC 9127:

       container bfd {
         if-feature bfd;
         description "BFD Client Configuration.";
         uses bfd-types:client-cfg-parms {
           refine local-multiplier {
             if-feature client-cfg-parameters;
           }
           refine interval-config-type {
             if-feature client-cfg-parameters;
           }
         }           
         reference
           "RFC YYYY - YANG Data Model for Bidirectional
                       Forwarding Detection (BFD).";
       }

This means that each of these documents would have to define its own
feature "client-cfg-parameters" though.  But this is similar to how
they currently define their own "bfd" feature.  (Unclear to me if this
is a bug or a feature.)

Some other observations:

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).

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?

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Nov 2021 06:18:25 -0500

Martin,

> to touch the three (?) documents that are in AUTH48?

That my proposal.

> 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.

> 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.

> case, you could as well wait with all docs?

The intent is to fast track the -bis.  The diff is trivial.

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Wed, 10 Nov 2021 13:16:25 +0100 (CET)

Hi,

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Nov 2021 09:09:36 -0500

Martin,

> AUTH48-docs out before the bis?

Our available actions are constrained by the impression that the -bis
violates the IETF YANG module revision rules.  My impression from this email
is you're okay with this violation.

If you similarly agree that simply shipping the -bis in short order with the
changes is the Right Thing, that helps.  The ADs can determine if we have
consensus to proceed with that as the action and we can move forward.

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Wed, 10 Nov 2021 15:24:19 +0100 (CET)

> is you're okay with this violation.

I'm not ok with this violation in general, but I am ok with it in this
particular case.  Hence my questions.  If it turns out that in the end
you modify the AUTH48-docs and wait for the bis anyway, then I don't
think this is the right way to go.

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Nov 2021 09:31:48 -0500

On Wed, Nov 10, 2021 at 03:24:19PM +0100, Martin Björklund wrote:
> particular case.  Hence my questions.

Understood.

> If it turns out that in the end

So, your preference is "ship AUTH48 docs unchanged, even though it'd have a
potentially redundant 'feature bfd'"?

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Wed, 10 Nov 2021 16:26:00 +0100 (CET)

> potentially redundant 'feature bfd'"?

Of course my preference is to not violate the upgrade rules, if
possible.

1.  publish the auth48-docs now with redundant "bfd" feature
2.  publish the auth48-docs now and remove the redundant "bfd" feature
3.  remove the redundant "bfd" feature and wait for -bis

I am not sure I understand what the proposal is at this point (as I
understood it, your original proposal was (1), but also w/o "bfd" in
-bis).

With (2), the published docs won't be very useful until the -bis is
published, right?

In the case of (3), I think it is better to make a proper fix to -bis.

And in the case of (1), you could as well introduce redundant
"client-cfg-param" features (as I suggested earlier), and avoid the
proposed -bis YANG upgrade rule violation.

Anyway, if you still decide to go with (1) or (2), I am ok with the
proposed -bis.  (I prefer (2) over (1)).

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Nov 2021 11:18:44 -0500

Martin,

> On Nov 10, 2021, at 10:26 AM, Martin Björklund <[email-masked]> wrote:
> 

Correct.  The critical detail the yang doctors was solicited for was if we can proceed with a quick 9127-bis to deal with the missing if-feature.  Adding that if-feature in the -bis avoids having to maintain the contents of a grouping in multiple documents that were otherwise inheriting it.

> With (2), the published docs won't be very useful until the -bis is

It creates a new dependency, yes.

> proposed -bis.  (I prefer (2) over (1)).

Thanks for your opinion.  We'll hopefully close this with Rob and the routing-ADs shortly.

-- Jeff

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:27:50 +0000

Hi,

Thanks for the input so far.

Having chatted with Alvaro and John, I believe that we are looking for a solution such that (1) we know what is being done in RFC 9127bis, and (2) allows the Auth48 of the protocol drafts to complete so that they can be published.  I.e., it is okay to delay Auth48 by a couple of weeks so that we know exactly what changes need to be made to the modules in Auth48, but not to delay publishing of the protocol drafts until RFC 9217bis has gone through the process.

We would like to reach an agreement on what the plan/changes are no later than Nov 24th, sooner if possible.

My reading of the consensus so far so that it is acceptable to make non-backwards-compatible changes to RFC 9217bis, if necessary, but we should not make non-backwards-compatible changes without a good justification.

I think, if I understand the proposals correctly, that I'm leaning towards option (2) that Martin described below.

Regards,
Rob

-----Original Message-----
From: Martin Björklund <[email-masked]> 
Sent: 10 November 2021 15:26
To: [email-masked]
Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:42:53 +0000

[Resending with Reshad's correct address]

Hi,

Regards,
Rob

-----Original Message-----
From: Martin Björklund <[email-masked]> 
Sent: 10 November 2021 15:26
To: [email-masked]
Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Nov 2021 18:25:38 -0500

I spent some time talking to Mahesh this afternoon and think we’re in sync. 

Expect a complete diff from him soon. 

Jeff

> On Nov 10, 2021, at 4:42 PM, Rob Wilton (rwilton) <[email-masked]> wrote:
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 19 Nov 2021 09:56:23 +0000

Hi Jeff, Mahesh,

Any update on that diff?

Thanks,
Rob

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: 10 November 2021 23:26
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Björklund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Reshad Rahman <[email-masked]>
Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Nov 2021 08:02:21 -0500

We've been iterating on it in the background.  Reshad had pointed out the original diff I created was not correct for part of where the base config is inherited, offered an update and we're tweaking it based on language feature.

The version that circulated last night seems promising.  I think we're waiting on Mahesh to respond for the review.

-- Jeff

> On Nov 19, 2021, at 4:56 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Jeff, Mahesh,
> 
> Any update on that diff?
> 
> Thanks,
> Rob
> 
>

---

From: John Scudder <[email-masked]>
Date: Tue, 23 Nov 2021 16:21:18 +0000

>>> On Nov 10, 2021, at 4:42 PM, Rob Wilton (rwilton) <[email-masked]> wrote:
...
>>> We would like to reach an agreement on what the plan/changes are no later than Nov 24th, sooner if possible.

Are we there yet?

Thanks,

—John

> On Nov 19, 2021, at 8:02 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Nov 2021 11:59:29 -0500

We have a proposed set of changes slightly different than my original diff.

Mahesh is working with the yanglint tools team on the validator tooling to ensure we're doing the right thing.  

If it helps move things along, we certainly can post the current diff.

-- Jeff

> On Nov 23, 2021, at 11:21 AM, John Scudder <[email-masked]> wrote:
>

---

From: John Scudder <[email-masked]>
Date: Tue, 23 Nov 2021 21:20:47 +0000

On Nov 23, 2021, at 11:59 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

It wouldn’t hurt.

Thanks,

—John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Nov 2021 16:52:40 -0500

> On Nov 23, 2021, at 4:20 PM, John Scudder <[email-masked]> wrote:
> 
>> On Nov 23, 2021, at 11:59 AM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 

The attached is what we're working through.

The draft text is simple past that point.

-- Jeff

---

From: Reshad Rahman <[email-masked]>
Date: Tue, 23 Nov 2021 22:02:12 +0000 (UTC)

And the subsequent thing we discussed is not having the refine at all but instead:use base-cfg-parms {  if-feature "client-cfg-parameters";}
    On Tuesday, November 23, 2021, 04:52:43 PM EST, Jeffrey Haas <[email-masked]> wrote:  

On Nov 23, 2021, at 11:59 AM, Jeffrey Haas <[email-masked]> wrote:
If it helps move things along, we certainly can post the current diff.

It wouldn’t hurt.
Thanks,

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Nov 2021 17:09:09 -0500

Thanks, Reshad.  That one wasn't top of my queue for the thread.

-- Jeff

> On Nov 23, 2021, at 5:02 PM, Reshad Rahman <[email-masked]> wrote:
> 
> And the subsequent thing we discussed is not having the refine at all but instead:
> use base-cfg-parms {
>   if-feature "client-cfg-parameters";
> }
> 
>> On Nov 23, 2021, at 4:20 PM, John Scudder <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>