Hi Jeff and Reshad, thank you for your comments and questions. Please find my answers in-line and tagged GIM2>>.
Regards, Greg On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Greg, > > On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote: > > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <jh...@pfrc.org> wrote: > > > Thanks for the update on the IPR declaration. It's good to see that > the > > > terms of the licensing have shifted such that open source > implementations > > > would be able to be done. I'll note that we're still in that limbo > phase > > > wherein it's not possible for the Working Group, or holders of IPR > against > > > the impacted RFCs 5880, 5883, and 5884, know what is being asserted > that is > > > distinct vs. previously published IPR declarations. > GIM2>> Is the fact that the patent application is not yet published the sole foundation for your objection to adopting this draft as Chair of BFD WG or as an individual contributor? Is there any IETF document that requires that the patent must be published before the draft can be adopted or published as RFC? > > > > > GIM>> My understanding of the legal side of IPR Disclosures is that the > > last overwrites, including in regard to the licensing terms, previous > > disclosures. > > The IPR disclosure and the licensing terms are clear. > > The patent is still pending. The draft is against procedures largely > specified in 5880, 5883, and 5884. Presumably IPR has been filed because > you're saying that you're doing something new against these documents. > GIM2>> I don't recall that I've ever claimed that the draft updates RFC 5883 BFD for Multi-hop paths or RFC 5884 BFD for MPLS LSPs. The draft describes how the BFD Demand mode may be used over MPLS LSP. I consider it to be complementary to RFC 5884, which only describes the use of BFD in Asynchronous mode and leaves the Demand mode out of its scope. > > > GIM>> The behavior of the system in Demand mode is introduced as > optional. > > And that is precisely the update to RFC 5880. > > I don't understand. > > Basically, 5880, 5884 leave demand as an option. It's built into the > specs. > It's unclear what you're suggesting being changed. > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does not discuss how the Demand mode may be used in BFD over MPLS LSPs. > > -- Jeff >
