Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>