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

[Greg Mirsky <[e-mail]>]

Hi Jeff,
I haven't heard that IETF encourages the discussion of the relevance of the
IPR Disclosure to the draft it referred to, less the validity of IPR. I
always was told to stay away from these topics.

As for your question of what is the change proposed in the draft I'll point
to section 6.6 RFC 5880 that describes the Demand mode. It states that the
periodic transmission of control messages MUST be stopped. The draft
defines, and that is what I consider the update to section 6.6, the
procedure by which the system in Demand mode initiates the Poll sequence to
inform the remote BFD system of RDI.

And coming back to WGAP, I don't recall any concerns or questions being
brought up on the WG list. The volume of responses was not enthusiastic, I
agree, but all were in favor of adopting the draft.

Regards,
Greg


On Mon, Feb 18, 2019 at 8:24 AM Jeffrey Haas <[e-mail]> wrote:

> On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > could you please clarify which of your roles, BFD WG chair or individual
> > contributor, you are in this discussion.
>
> In this case I am speaking as a chair.
>
> For the Working Group to adopt a draft, it needs to solve a problem.  In
> this case, changes to the protocol.  We are asking you what changes there
> are to the protocol.  Please answer that question.
>
> In the prior adoption call, IPR declaration concerns were one of the
> considerations for some respondents as to whether we should adopt this or
> not.  You answered those, and the licensing in the current IPR declaration
> is the in the form that is the most agreeable from a licensing perspective,
> especially for open source implementors.
>
> Again, the only motivation to inquire about the IPR at this point is that
> there appears to be no protocol changes in your draft.  If you are
> asserting
> IPR, it implies that there is something new.  If there's something new, it
> should be reflected as protocol changes in your draft.  Even if you're not
> to the point where you or the IPR holder can disclose, the draft itself
> must
> be clear.
>
> If you have any further concerns beyond the above with specific regard to
> my
> stance as chair on the IPR considerations, I strongly suggest you request
> Martin to ask the IESG to have the IETF legal group intervene.  This would
> be preferable to further aspersions to implicit bias.  Please note that
> IETF
> legal will be asking similar questions to the above.
>
> -- Jeff
>
>
>
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas <[e-mail]> wrote:
> >
> > > Greg,
> > >
> > > Answering this message with the reply partially reorganized.
> > >
> > >
> > > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> > > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas <[e-mail]>
> wrote:
> > > > > > 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.
> > >
> > > Even thought the RFC says demand mode is out of scope, 5880 is clear
> about
> > > how demand mode works.  I'm not seeing anything in your draft that
> alters
> > > that procedure.
> > >
> > > Basically, no draft is needed for a one-liner: you can use demand mode.
> > >
> > > > 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?
> > >
> > > The sole reason for mentioning this is demand mode is clear.  BFD over
> mpls
> > > is clear.  You're asserting some sort of IPR on things that are already
> > > clear.  So, either your draft itself is unclear on some new thing
> you're
> > > asserting IPR on, or you're not actually covering something new.
> That's
> > > it.
> > >
> > > -- Jeff
> > >
>