Hi, Jeff et al., upon more consideration of this draft, the write-up, and the related to the draft BBF liaison <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/>, I would propose to include the reference to the liaison in the write-up. Perhaps the following update is acceptable: OLD TEXT: 5. In discussion over the document's intended status, Greg has expressed an opinion that the document should be Experimental rather than Proposed Standard. As noted in the IETF webpage, "Choosing between Informational and Experimental Status", it is the Shepherd's opinion that Experimental is inappropriate. "The "Experimental" designation typically denotes a specification that is part of some research or development effort". In this case, implementations are commercially available utilizing mechanisms largely similar to those being codified in this Internet-Draft. NEW TEXT: 5. In the discussion over the document's intended status, Greg has noted that the Broadband Forum, in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo ( https://datatracker.ietf.org/liaison/1775/) informed the IETF and BFD WG that "In our [Broadband Forum's] opinion, no future standardization is required to support TR-146." Greg also expressed an opinion that the document should be Experimental rather than Proposed Standard. As noted in the IETF webpage, "Choosing between Informational and Experimental Status", it is Shepherd's opinion is that Experimental is inappropriate. "The "Experimental" designation typically denotes a specification that is part of some research or development effort". In this case, implementations are commercially available utilizing mechanisms largely similar to those being codified in this Internet-Draft.
Regards, Greg On Mon, Jan 15, 2024 at 3:18 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Jeff, > thank you for your quick response to my comments. I appreciate the update > you added to the Write-up. > > Regards, > Greg > > On Mon, Jan 15, 2024 at 2:47 PM Jeffrey Haas <jh...@pfrc.org> wrote: > >> Greg, >> >> >> On Jan 15, 2024, at 5:15 PM, Greg Mirsky <gregimir...@gmail.com> wrote: >> >> - For several years I've actively participated in the work at BBF, >> including the Working Area that published TR-146. I cannot recall that any >> member company reported TR-146 implementation. Were there any on the BFD >> mailing list that led to the following summary in the write-up: >> >> There are multiple implementations that claim some deployment of BBF >> TR-146 implementation behavior. >> >> >> If you're reading this as "claiming conformance to tr-146", that's not >> what is written here. Mostly because tr-146 was missing enough detail to >> make it difficult for a BFD implementation to claim actual conformance. >> That's to a great extent what the authors are attempting to rectify. >> >> In terms of the "BFD talking to itself over Echo", which is the >> implementation behavior in question, we can publicly say that the Broadcom >> implementation is certainly in the same family. Juniper's BFD-Lite feature >> is also in the same family. >> >> Having not asked for a conformance report vs. this document, I'm not >> pointing out other vendors who have similar behaviors. Certainly I'd >> encourage others with information on their implementations to respond to >> this thread. >> >> >> - In the course of discussing this draft, I commented many times that >> the proposed mechanism doesn't require any action from a BFD system >> outside >> of a node that transmits and processes a probe. I suggested that, if >> there's interest in publishing this draft, it be published as Experimental >> or Informational, but not a Standard track document. I don't find that >> point of the discussion reflected in the Shepherd write-up, or >> affecting the intended status. >> >> >> I've added the following point to the shepherds report. Hopefully this >> addresses your concern: >> >> 5. In discussion over the document's intended status, Greg has expressed an >> opinion >> that the document should be Experimental rather than Proposed Standard. As >> noted >> in the IETF webpage, "Choosing between Informational and Experimental >> Status", it is >> the Shepherd's opinion that Experimental is inappropriate. "The >> "Experimental" >> designation typically denotes a specification that is part of some research >> or >> development effort". In this case, implementations are commercially >> available >> utilizing mechanisms largely similar to those being codified in this >> Internet-Draft. >> >> While the procedures in this draft are purely local (the implementation >> "talks to itself"), >> the behavior requires a violation of RFC 5880 >> <https://datatracker.ietf.org/doc/rfc5880/> with regard to Echo procedures >> only >> being available after the Up state has been achieved in Asynchronous mode. >> It is thus the Chairs' opinion that the text permitting the relaxation of >> that >> requirement is appropriate to standardize for this document, and thus an >> appropriate >> change of status requiring an update to RFC 5880 >> <https://datatracker.ietf.org/doc/rfc5880/>. >> >> >> -- Jeff >> >>