Greg, You may find the official liaison response here in the archives: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/>
The contents of that response are: From: Dave Sinicrope <[email protected]> <mailto:<[email protected]>> To: Jeffrey Haas <[email protected]>,Reshad <mailto:<[email protected]>,Reshad> Rahman <[email protected]> <mailto:<[email protected]>> Cc: Alvaro Retana <[email protected]>,John <mailto:<[email protected]>,John> Scudder <[email protected]>,Martin <mailto:<[email protected]>,Martin> Vigoureux <[email protected]>,Dave <mailto:<[email protected]>,Dave> Sinicrope <[email protected]>,Jeffrey <mailto:<[email protected]>,Jeffrey> Haas <[email protected]>,Reshad <mailto:<[email protected]>,Reshad> Rahman <[email protected]>,Bidirectional <mailto:<[email protected]>,Bidirectional> Forwarding Detection Discussion List <[email protected]> <mailto:<[email protected]>> Response Contacts: Technical Contacts: Purpose: For information Body: The BBF thanks the IETF BFD WG for informing us of important work on the BFD Echo. We wanted to clarify the "overlapping use case with TR-146". TR-146 leverages BFD Echo as a connectivity check mechanism. It does so in a manner where the peer does not need a full BFD implementation to echo the packet received. In our opinion, no future standardization is required to support TR-146. There is no current interest in revising TR-146 to leverage the enhancement of the BFD protocol. We noted in the BBF community that those interested in participating should do so in the IETF BFD WG. Sincerely, Lincoln Lavoie, Broadband Forum Technical Committee Chair > On Apr 5, 2023, at 7:36 PM, Greg Mirsky <[email protected]> wrote: > > Hi, Dave, Jeff, et al., > I was looking for the BFD WG liaison to BBF and its response. I appreciate it > if you help me to find out what was the BBF response, as the > draft-ietf-bfd-unaffiliated-echo is in the WG LC. > > Thank you in advance. > > Regards, > Greg > > On Thu, Nov 18, 2021 at 10:05 AM David Sinicrope <[email protected] > <mailto:[email protected]>> wrote: > Hi Jeff, (Sorry for bouncing around email addresses on you… IT challenges > this week) > > Thanks for clarifying the assertion concerning BBF interest. Still, given > the statement in the adoption call and the clear references to TR-146 in the > draft, it would be a good idea to liaise to BBF, even if brief, and let them > know of the draft and its relation to TR-146. It certainly couldn’t hurt to > have open communication with them on the subject. > > Regarding your check with the IESG on the liaison - please proceed as you > deem appropriate. I will say, (and apologies if I’m stating well known > details) that typically liaisons don’t need IESG approval. They are normally > crafted/drafted by the WG Chairs, and have some level of review and approval > by the WG(s) in question or impacted. > > I hope this helps find the most expeditious and effective way to proceed. > Thanks, > Dave > > On Thu, Nov 18, 2021 at 12:38 Jeffrey Haas <[email protected] > <mailto:[email protected]>> wrote: > David, > > On Thu, Nov 18, 2021 at 05:18:38PM +0000, David Sinicrope wrote: > > Sorry, I don't recall our discussion, but then it would have been as long > > ago as Singapore in Nov 2019 or before. > > (Is it possible you spoke with Dave Allan?) > > That's possible! As I noted in the thread, my notes from that lunch are > missing. (I have strong words for Microsoft about their support for Mac > mail, but that's a different story.) Whomever I had a conversation with it > was in a subterranean warren of lunch venues. Perhaps that will jar > someone's memory of the venue. > > If you have contact info for Dave Allen I can certainly followup with him. > > > I can say as the BBF Liaison Manager there have been many past claims of > > BBF interest in IETF work without substantiation. As a result, it has > > been key to ensure that any statement of BBF interest in IETF work, > > especially if made to encourage action in the IETF, be formally supported > > via a liaison. Searching the Liaison Statements in > > Datatracker<https://datatracker.ietf.org/liaison/ > > <https://datatracker.ietf.org/liaison/>>, I don't see a liaison > > from either the BBF or IETF related to this work. > > Please note that I don't believe we're asserting that BBF is interested in > IETF in doing this work for BBF. And perhaps the easiest answer we'll > converge to is "remove all mention of BBF". > > That said, throughout the discussion that lead to this draft, it was pointed > out to the original authors that they were largely covering the TR-146 use > case. Minimally, making sure we have a BBF statement regarding the IETF > work may make sense. > > > Also, to the best of my knowledge, the issues that this draft addresses > > have not been raised in BBF. E.g., a proposal for revision to TR-146 or > > related documents. > > I am not a participant in BBF and have no knowledge of any such > communications one way or the other. Informally, the discussions I have > been involved in both with the BFD draft in question and in prior contexts > at my employer have mostly been that the BBF procedures are somewhat > inspecific and cleaner documented procedures for the use case are desired. > > > Given the stated overlap and application of the draft to TR-146 (in the > > adoption call), > [...] > > I would suggest that a liaison be crafted and sent to the BBF formally > > notifying them of this work and inquiring as to the interest in the > > content of the draft. Fortunately, the next BBF meeting where such a > > liaison would be addressed and responded to is 29 Nov - 3 Dec 2021. The > > sooner the liaison is sent, the more likely a timely response coming out > > of this upcoming meeting. > > I think we could make such a deadline. I'll start discussion with our AD to > see what the IESG will want for the liaison statement. > > Meanwhile, I'll see if I can contact Dave Allen to try to get clarification > of what we discussed over lunch - if it was him. > > -- Jeff > -- > David Sinicrope > [email protected] <mailto:[email protected]>
