An informational document that also has a management/YANG part included would IMHO be the right outcome.
Regards, Jeff > On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) <rrah...@cisco.com> wrote: > > > Hi Jeff and Les, > > In general I prefer to have the 2 together (here’s the protocol details and > here’s how it’s managed), IMHO there’s benefit in having the 2 together since > the YANG discussions are happening while we’re in the thick of the protocol > discussions. I am actually not keen to end up with 2 docs, RFC XXX and RFC > YYYY: YANG for XXXX with 2 different lifecycles, by the time the YANG is done > people aren’t interested anymore because the protocol spec is done. I > brought this up some time ago with RTG AD and OPS AD, but I don’t think there > was any conclusion.. > > In this specific case, I agree that there’s no protocol changes. So with 2 > documents, are you proposing that the BFD spec should be informational and > the YANG standards track? Or both informational? If it’s the latter, I’d > rather they be in the same doc. > > Regards, > Reshad ( no hat). > From: Jeff Tantsura <jefftant.i...@gmail.com> > Date: Tuesday, August 18, 2020 at 9:01 PM > To: Robert Raszuk <rob...@raszuk.net>, "Les Ginsberg (ginsberg)" > <ginsb...@cisco.com>, "Reshad Rahman (rrahman)" <rrah...@cisco.com>, Martin > Vigoureux <martin.vigour...@nokia.com> > Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending > 16 August, 2020) > > IMHO - It isn’t right that presence of YANG defines document’ designation > track. The common practice is that if the draft in question doesn’t require > any protocol changes it should aim for Informational track (or BCP). > https://ietf.org/standards/process/informational-vs-experimental/ > > I’d rather have 2 separate documents. In general, given that YANG documents > life cycle is quite different from that of protocol ones, it is perhaps a > good practice to keep them separate. > I have included Martin (Routing AD for BFD) > > Cheers, > Jeff > On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) > <rrahman=40cisco.....@dmarc.ietf.org>, wrote: > > Indeed, draft-chen-bfd-unsolicited was informational and with the addition of > the YANG module draft-ietf-bfd-unsolicted was changed to standards track.. > > Regards, > Reshad (no hat). > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of Robert Raszuk > <rob...@raszuk.net> > Date: Tuesday, August 18, 2020 at 5:44 AM > To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> > Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending > 16 August, 2020) > > Hi Les, > > While shifting to Informational would be perhaps ok protocol wise - isn't it > common practice in IETF that any draft (or at least most of them) which > define a YANG model is a Standards Track document ? > > I hope you are not suggesting to split this one into two :). > > Thx, > R. > > On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > Sorry to be tardy in responding... > > As I stated almost 2 years ago when this draft was introduced: > > a)The problem the draft is addressing is real and the solution useful > > b)There are implementations which have already addressed this problem with no > interoperability issues > > c)I do not see that any changes have been made to the BFD protocol (e.g.. RFC > 5881) > > Therefore, I think this should go forward - but as Informational. > > Les > > > > -----Original Message----- > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org> On Behalf Of Jeffrey Haas > > Sent: Monday, August 17, 2020 1:45 PM > > To: rtg-...@ietf..org > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending > > 16 > > August, 2020) > > > > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote: > > > Working Group, > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ > > > > > > With apologies to the authors of BFD unsolicited, this document is past > > > due > > > for Working Group Last Call. The primary holdup on the document had > > been > > > last minute interaction with the RFC Editor with regard to its impact on > > > the > > > BFD Yang model. That work had completed some time ago.. (The Yang > > model, > > > however, is still lingering in MISREF state.) > > > > > > This begins a last call period ending on 16 August. > > > > The last call period has ended with a few comments from Greg and Raj that > > should be addressed before we continue. > > > > It'd also be helpful to hear from additional reviewers before we advance > > this document. > > > > -- Jeff
