Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02

From: "David Harrington" <[email-masked]>
Date: Thu, 1 Apr 2010 10:18:37 -0400

Hi,
 
<ad hat off>
I work for a large corporation, and understand the importance of IPR
to large corporations.
I have worked in IETF for 18 years and understand the importance of
IPR to IETF standardization efforts.
 
<ad hat on>
 
I believe this is the correct forum to discuss specific IPR claims and
specific licensing that might impact the usefulness of standards
produced by this forum, within the guidelines provided by RFC3669
"Guidelines for Working Groups on Intellectual Property Issues". 
 
It is not the correct forum to judge whether the IPR is valid. That is
up to the appropriate courts to decide.
 
I believe that it is appropriate for the WG to attempt to get
clarification on both IPR claims and licensing terms, to consider
whether alternate designs might better serve the Internet community,
to consider whether having no standard might better serve the Internet
community, and to decide whether the licensing terms mitigate the
impact of the known IPR. 
 
Recognize that IPR claims might appear at any time during the life of
a standard, so trying to pick a design that has **no** IPR
encumbrances might not be successful. Deciding whether the licensing
terms mitigate the impact of the declared IPR might be a better use of
the WG's time. But that is a WG's decision, as reflected in RFC3669.
 
All participants should be very careful to respect each other's
viewpoints in the discussions. 
 
dbh
David Harrington
[email-masked]
[email-masked]
[email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luby, Michael
Sent: Thursday, March 25, 2010 9:20 PM
To: Vincent Roca; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM
Incorporated's Statement about IPR related to
draft-roca-fecframe-rs-02

All,
I agree with and respect Stephan's remarks, this is not the forum to
discuss specific IPR.
Mike  

On 3/25/10 1:18 PM, "Vincent Roca" <[email-masked]> wrote:

Mike,

I discover that QC just updated its previous IPR disclosure
against our I-D in:    https://datatracker.ietf.org/ipr/1288/

This disclosure refers to draft-roca-fecframe-rs-02, i.e. the
latest version where we tried to solve the potential IPR issue
as I explained to you in my previous emails (sent before the
IPR disclosure update):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html

So I take it as QC's official answer: the issue is not solved in
-02 version according to QC!

Since it seems I have no choice, let's put everything on the
table:

** Concerning US Patent 7,660,245:
This patent has three independent claims: 1, 16 and 18.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols.
Unless we forgot something, we removed from our I-D all
references to this technique, which is sufficient to conclude that
version -02 cannot infringe US Patent 7,660,245.

** Concerning Patent 20100050057:
This patent has four independent claims: 1, 10, 16 and 24.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols, so
my answer is exactly the same.

I'd like to understand. *I am doing significant efforts but
I now have the feeling this is not reciprocal.* What's wrong?
I need an answer.

Regards,

  Vincent

On 25/03/10 18:08, IETF Secretariat wrote:
> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche,
Amine Bouabdallah:
>
> An IPR disclosure that pertains to your Internet-Draft entitled
"Reed-Solomon
> Forward Error Correction (FEC) Schemes for FECFRAME"
(draft-roca-fecframe-rs)
> was submitted to the IETF Secretariat on 2010-03-18 and has been
posted on the
> "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR
disclosure is
> "QUALCOMM Incorporated's Statement about IPR related to
> draft-roca-fecframe-rs-02."
>
> The IETF Secretariat
>

---

From: Vincent Roca <[email-masked]>
Date: Thu, 01 Apr 2010 17:18:14 +0200

Mike,

My intent has never been to convince QC of the negative
impacts of patents ;-), therefore I'll just focus on the main
topic.

I see good points in your answer, In particular when you
say:

 > *** You got an answer, which I'll repeat here: the one issue
 > that we discussed previously was addressed, but there are other
 > issues which we have identified that still need to be
 > considered and addressed.

This is exactly my goal: *consider and address the other
issues*. I want to understand the situation. According to
what I can read, version 02 of our I-D cannot infringe any
claim of the two patents since the 7 independent claims
all require that "the first number of source symbols is
different from the second number of source symbols".
This is no longer the case in -02. If I'm wrong, where's
my mistake? Which claim(s) do you think version 02
infringes? I want to understand your point of view.

Concerning our discussion in RMT last Autumn, I cant'
follow you when you say:

 > *** Nothing was achieved in RMT in my opinion.  That was
 > a huge waste of time and energy in my opinion to try and
 > resolve the situation, and didn't achieve anything, as still
 > it is the case that QC has declared IPR on some of your drafts
 > and you have declared loudly and publicly in many forums that
 > this is not the case.  How is that a good resolution?

The one and only reason that led QC to add 10 patents
to its IPR disclosure against RFC 5170 is now known.
Since the technique that infringes these patents (i.e.
"having several symbols per packet") is not mandatory
to use, a user can decide whether it's worth using it or
not. If it is a waste of time from your point of view,
I don't think you'll find many potential users who agree.

Here also we see how "unpublished pending patents"
can badly interfere with IETF activities. If Digital
Fountain had clarified the issue since the beginning
(i.e. in December 2007, after IPR Disclosure #908)
and pointed out to us where the problem was, the
offending technique would have been removed before the
RFC is published (as I said this technique is not
essential and we can, by increasing the matrix density,
achieve good erasure recovery performances even for
small blocks).

This is precisely why I want to clarify the situation
today W.R.T. our FECFRAME I-D.

Another point which is, for the moment, of secondary
importance IMHO, even if you mentioned it:

 > *** The main change to the new IPR disclosures (and we
 > updated them all in RMT and FECFRAME, not just this one)
 > compared to previous is the licensing terms, that
 > rationally should put the whole issue to rest.  Clearly,
 > this didn't mollify you, as it seems that any IPR, even
 > if the licensing terms are quite quite favorable, is
 > unacceptable in your opinion.

At this step of the discussion, we must focus on the
main questions: does this I-D infringe any claim?
Why? Are there alternatives? Is there any penalty in
considering these alternatives, if any?

You are trying to reverse the reasoning. This is a
mistake IMHO. Licensing conditions are one of the
elements to consider once we all perfectly understand
the situation, not before.

Anyway licensing conditions are never definitive and
can be changed at any time (and it already happened 3
times with RFC 5170!).

Be assured I want to constructively discuss with you.
Best regards,

    Vincent

On 29/03/2010 18:54, Luby, Michael wrote:
> Some remarks below. (***)
> ________________________________________
> From: Vincent Roca [[email-masked]]
> Sent: Monday, March 29, 2010 6:32 AM
> To: Luby, Michael
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02
>
> Hello Stephan and Mike,
>
>
> I think your emails deserve an answer.
> Generals considerations first, and then I'll focus on
> the specific point under discussion.
>
> --
>
> I'm also fed up with all these IPR issues that oblige me to
> leave my primary activities all too often. I'm researcher,
> not an IPR lawyer and I have no natural inclination for
> these legal aspects.
>
> That being said, I also want my work to be useful to the
> whole community (within or outside of the IETF, Nokia and
> QC included). From this point of view, if there's an IPR
> disclosure and if I have the feeling an alternative
> solution exists, I'll examine it instead of "passively
> accepting" the situation. In any case be assured my
> behavior is only governed by the desire to be useful to
> the community.
>
> *** There is IPR disclosures on many specifications within the IETF, and the standards in which they exist are useful to the whole community.  Your premise is flawed, and thus much of the reasoning below.
>
> One big difference between you and me is the fact I don't
> have any legal department in charge of examining IPR
> aspects. If my documents are subject of a disclosure, I
> can either ignore it (as many colleagues do) or tackle
> its analysis. If I want to achieve my above goal of being
> useful to the community, this second option is the only
> possible.
>
> Yes, I'd like we could all work just like 30-40 years ago,
> when smart people were eager to design the best possible
> Internet, using the best possible techniques, just because
> it was the right answer to the situation. It's  worth
> remembering this heritage. It's perhaps an utopia
> today, however I'm doing my best to stick with this
> philosophy since I currently have the freedom to do
> that.
>
> *** Much of the best technology used on the Internet has/had IPR, including Reed-Solomon codes, all video codecs, etc.
>
> Finally, you can find many examples of WGs going into this
> kind of discussion, e.g. in the informational RFC 3669
> (https://datatracker.ietf.org/doc/rfc3669/).
> A few excerpts of the lessons learned:
>
>     o  IPR claims should never be disregarded without good cause.  Due
>        diligence should be done to understand the consequences of each
>        claim.
> [...]
>     o  It's sometimes beneficial to push IPR claimants to find out what
>        they think their claims cover and what their licensing terms are.
>
>     o  Possibilities of prior art should be considered.
>
>     o  It's all right, and sometimes beneficial, to discuss IPR claims
>        and gather information about possible prior art on the group list.
>        The results of such discussion can be considered when deciding
>        whether to develop a technology (but remember that neither the
>        IETF nor any working group takes a stand on such claims as a body,
>        and the group is not the best place to get legal advice).
>
> The above sentences are not definite rules, of course, and
> each situation is specific and needs to be handled
> appropriately. However saying that "[the FECFRAME mailing
> list] is not the forum to discuss specific IPR" is a
> personal interpretation that is in-line with the IETF
> practices.
>
>
> --
>
> Now, concerning the topic that triggered this discussion:
>
> - I've updated the I-D and in theory it's sufficient for
>    QC to be aware of our attempts to solve the problem;
> - However I explicitly told Mike what we've done and
>    asked him to clarify QC's position. No answer;
> - I met Mike just before the fecframe meeting and asked
>    again the same question. Unless I misunderstood what he
>    said, I didn't get any answer;
>
> *** You got an answer, which I'll repeat here: the one issue that we discussed previously was addressed, but there are other issues which we have identified that still need to be considered and addressed.
>
> - the situation was once again explained in my slides.
>
>   I was not there unfortunately, but I didn't see
>    anything in the Minutes;
> - And then came this new IPR disclosure that completely
>    ignores any effort I've made to try understand the
>    situation and to solve it.
>
> *** The main change to the new IPR disclosures (and we updated them all in RMT and FECFRAME, not just this one) compared to previous is the licensing terms, that rationally should put the whole issue to rest.  Clearly, this didn't mollify you, as it seems that any IPR, even if the licensing terms are quite quite favorable, is unacceptable in your opinion.  However, during the course of the IPR update process, we did reexamine the spec and understood that there were still some technical issues with the current draft that probably would have to be changed to be clear of the particular IPR that is declared on the current draft.  If I remember correctly, you also mentioned that you would be adding some new elements to the next version of the draft, and be aware and forewarned that these will also have to be carefully scrutinized, as part of our obligations, to see if there is any necessity to declare additional IPR.
>
> At this point, I'm now wondering if QC's strategy is not
> to leave this point open until everybody forget? Anyway,
> if QC does not want to answer, I want it to be clearly
> stated and justified. How long it will take me to have
> this clarification is not under my control.
>
> *** This is not nor ever has been QC strategy.
>
> I'm not responsible of the whole story. Especially as
> last year I even made sure that there was no IPR issue
> in FECFRAME. Now DF/QC chose the submarine patent
> approach ("undisclosed pending patent") and to keep it
> secret till it's granted, last month.  It's their right but me
> and my co-authors are the victims in this story.
>
> *** It was not a submarine patent, and it is dangerous to allege this.
>
>
> Last but not least...
> In all my emails exchanges, I pay attention not to offend
> anybody. I don't have the feeling that any email I sent
> (including this one) was offending, but if somebody has a
> different feeling, then I apologize since this was not my
> goal.
>
> Sorry for this very long email. I hope that you now better
> understand my attitude. Stephan, if you are not interested
> by my  IPR-related emails, which I can understand, then
> please  ignore them.
>
> And long life to the IETF that already enabled me to solve
> similar issues, without having to waste time, energy and
> money in a court, whereas a consensus was easily achievable
> as long as both parties are working toward this goal. Last
> Autumn discussion with Mike on the RMT mailing list proved
> it's possible. Thanks!
>
> *** Nothing was achieved in RMT in my opinion.  That was a huge waste of time and energy in my opinion to try and resolve the situation, and didn't achieve anything, as still it is the case that QC has declared IPR on some of your drafts and you have declared loudly and publicly in many forums that this is not the case.  How is that a good resolution?
>
> Best regards,
>
>
>      Vincent
>
>
>
> On 26/03/2010 02:19, Luby, Michael wrote:
> All,
> I agree with and respect Stephan’s remarks, this is not the forum to discuss specific IPR.
> Mike
>
>
> On 3/25/10 1:18 PM, "Vincent Roca"<[email-masked]>  wrote:
>
> Mike,
>
>> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah:
>>
>> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon
>> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs)
>> was submitted to the IETF Secretariat on 2010-03-18 and has been posted on the
>> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 7 Apr 2010 17:39:29 -0700

FECFRAME working group,
Vincent has made some points below to which I have responded below (ML).  On some of these points I think it would be useful to have other inputs from other members of the FECFRAME working group, or those interested in IPR issues in general, rather than have this be just a dialog between two people.
Thanks, Mike

On 4/1/10 8:18 AM, "Vincent Roca" <[email-masked]> wrote:

Mike,

(ML) As a general policy (at both DF and QC), we declare IPR on an IETF draft/RFC if there is some inventive element described in the draft/RFC that was previously described in the specification of an active patent, where we feel that the element could be the basis of a claim.  Otherwise, if we waited till we actually had filed an additional patent with the particular claim based on the original patent specification and then after that declared IPR on an IETF draft/RFC, it might be perceived as a submarine declaration.

(ML) Given this, there are other elements, for example in U.S. Patent 7660245, that are also included in draft-roca-fecframe-rs-02.  As an example of such an element, placing the SBL in the repair packet FEC Payload ID but not in the source packet FEC Payload ID is described in some detail in U.S. Patent 7660245, and the advantages of doing this are well-described in U.S. Patent 7660245, but this particular element is not necessarily the basis of a claim in U.S. Patent 7660245.  However, this element is included in draft-roca-fecframe-rs-02.  There are potentially other elements that are similar, that I would be willing to work with you offline to identify and remove from the newer versions of draft-roca-fecframe-rs-02, if this is the path that you and the FECFRAME working group decide to take.

(ML) There is still an IPR declaration against RFC 5170 that was not resolved and I imagine will not be resolved, since for whatever reason you have decided that it is ok not to try and remove that IPR from the RFC 5170.  So, in my mind, resolving one portion of an IPR declaration but still having other IPR declared that is not resolved doesn't really help, since the basic situation is the same: there is still IPR declared on RFC 5170.

(ML) Here is an extract from the email that David Harrington recently sent out: "Recognize that IPR claims might appear at any time during the life of a standard, so trying to pick a design that has **no** IPR encumbrances might not be successful. Deciding whether the licensing terms mitigate the impact of the declared IPR might be a better use of the WG's time. But that is a WG's decision, as reflected in RFC3669."  That was my point.

(ML) True about the changes in licensing conditions/terms, and this has been true for all relevant drafts/RFCs in both RMT and FECFRAME with respect to DF/QC IPR declarations, but each time they have changed they have become more favorable, to the point that the licensing terms have become very favorable at this point.  Thus, a general question for FECFRAME:  Is it better to have drafts/RFCs with no currently known IPR declarations at the expense of possibly not as good drafts/RFCs in terms of the technology capabilities and efficiencies, or is it better to have drafts/RFCs with IPR declarations with favorable licensing terms with the advantage of having better drafts/RFCs in terms of the technology capabilities and efficiencies?  This is not an abstract question: this is a question specifically in the context of this and other drafts within FECFRAME  and with respect to the particular IPR declarations with associated licensing terms that have been made in FECFRAME.  I know how some other IETF working groups have dealt with this, and it seems to have come out both ways depending on the group and the licensing terms, but I'm not sure that FECFRAME has had this discussion at the working group level to decide the path forward.

    Vincent

On 29/03/2010 18:54, Luby, Michael wrote:
> I agree with and respect Stephan's remarks, this is not the forum to discuss specific IPR.
> Mike
>
>

---

From: Vincent Roca <[email-masked]>
Date: Tue, 13 Apr 2010 14:25:28 +0200

Mike, all,

>     (ML) As a general policy (at both DF and QC), we declare IPR

> on an IETF draft/RFC if there is some inventive element described

> in the draft/RFC that was previously described in the

> specification of an active patent, where we feel that the element

> could be the basis of a claim.  Otherwise, if we waited till we

> actually had filed an additional patent with the particular claim

> based on the original patent specification and then after that

> declared IPR on an IETF draft/RFC, it might be perceived as a

> submarine declaration.

Okay, I agree with this position in general.

I also understand you're acknowledging the fact version -02 has

definitively solved any issue W.R.T. the *claims* of the two

patents mentions in the IPR disclosure. Good.

Two additional comments:

- Your position makes sense iff you let the authors know the exact

situation, i.e. the fact their document may infringe a *future*

patent, continuation of the one being listed in the IPR disclosure,

without necessarily infringing any existing claim.

In our case, it was not clear until recently and from this point

of view, our discussion was more than required.

- without any further information from your side, the situation is

rather unhealthy, since we, the authors, have no objective way

to determine:

(1) what are the "inventive elements" of the patent description

that will be the basis of futures claims in future patent

application(s), and

(2) the context under which you these claims will apply, which

is equally important.

>     (ML) Given this, there are other elements, for example in U.S.

> Patent 7660245, that are also included in
draft-roca-fecframe-rs-02.

> As an example of such an element, placing the SBL in the repair

> packet FEC Payload ID but not in the source packet FEC Payload ID

> is described in some detail in U.S. Patent 7660245, and the

> advantages of doing this are well-described in U.S. Patent 7660245,

> but this particular element is not necessarily the basis of a claim

> in U.S. Patent 7660245.  However, this element is included in

> draft-roca-fecframe-rs-02.  There are potentially other elements

> that are similar, that I would be willing to work with you offline

> to identify and remove from the newer versions of

> draft-roca-fecframe-rs-02, if this is the path that you and the

> FECFRAME working group decide to take.

We are making progress... Of course I accept your proposal.

Let's discuss off-list and come back with an analysis of the

situation. And if anybody is interested, he can join the

discussion.

>     (ML) Here is an extract from the email that David Harrington

> recently sent out: “Recognize that IPR claims might appear at

> any time during the life of a standard, so trying to pick a design

> that has **no** IPR encumbrances might not be successful. Deciding

> whether the licensing terms mitigate the impact of the declared

> IPR might be a better use of the WG's time. But that is a WG's

> decision, as reflected in RFC3669.”  That was my point.

I think the authors (and the WG) do not have the needed elements

(e.g. the exhaustive list of techniques that might infringe

future QC patents). This is IMHO a prerequisite to judge whether

or not the current licensing terms mitigate or not the situation.

Besides, we are still in an early phase of the IETF work, and

changing the I-D content, even significantly, is usual, no matter

the reasons. This is my point.

And of course, as David H. reminded us, IPR disclosures from

other companies might appear in the future. But it's a different topic.

Regards,

Vincent

On 08/04/10 02:39, Luby, Michael wrote:

FECFRAME working group,

Vincent has made some points below to which I have responded below
(ML).  On some of these points I think it would be useful to have other
inputs from other members of the FECFRAME working group, or those
interested in IPR issues in general, rather than have this be just a
dialog between two people.

Thanks, Mike

On 4/1/10 8:18 AM, "Vincent Roca" <[email-masked]>
wrote:

Mike,

topic.

(ML) As a general policy (at both DF and QC), we declare IPR on an IETF
draft/RFC if there is some inventive element described in the draft/RFC
that was previously described in the specification of an active patent,
where we feel that the element could be the basis of a claim.
Otherwise, if we waited till we actually had filed an additional
patent with the particular claim based on the original patent
specification and then after that declared IPR on an IETF draft/RFC, it
might be perceived as a submarine declaration.

(ML) Given this, there are other elements, for example in U.S. Patent
7660245, that are also included in draft-roca-fecframe-rs-02.  As an
example of such an element, placing the SBL in the repair packet FEC
Payload ID but not in the source packet FEC Payload ID is described in
some detail in U.S. Patent 7660245, and the advantages of doing this
are well-described in U.S. Patent 7660245, but this particular element
is not necessarily the basis of a claim in U.S. Patent 7660245.
However, this element is included in draft-roca-fecframe-rs-02.  There
are potentially other elements that are similar, that I would be
willing to work with you offline to identify and remove from the newer
versions of draft-roca-fecframe-rs-02, if this is the path that you and
the FECFRAME working group decide to take.

small blocks).

(ML) There is still an IPR declaration against RFC 5170 that was not
resolved and I imagine will not be resolved, since for whatever reason
you have decided that it is ok not to try and remove that IPR from the
RFC 5170.  So, in my mind, resolving one portion of an IPR declaration
but still having other IPR declared that is not resolved doesn’t really
help, since the basic situation is the same: there is still IPR
declared on RFC 5170.

(ML) Here is an extract from the email that David Harrington recently
sent out: “Recognize that IPR claims might
appear at any time during the life of a standard, so trying to pick a
design that has **no** IPR encumbrances might not be successful.
Deciding whether the licensing terms mitigate the impact of the
declared IPR might be a better use of the WG's time. But that is a WG's
decision, as reflected in RFC3669.”
That was my point.

times with RFC 5170!).

(ML) True about the changes in licensing conditions/terms, and this has
been true for all relevant drafts/RFCs in both RMT and FECFRAME with
respect to DF/QC IPR declarations, but each time they have changed they
have become more favorable, to the point that the licensing terms have
become very favorable at this point.  Thus, a general question for
FECFRAME:  Is it better to have drafts/RFCs with no currently known IPR
declarations at the expense of possibly not as good drafts/RFCs in
terms of the technology capabilities and efficiencies, or is it better
to have drafts/RFCs with IPR declarations with favorable licensing
terms with the advantage of having better drafts/RFCs in terms of the
technology capabilities and efficiencies?  This is not an abstract
question: this is a question specifically in the context of this and
other drafts within FECFRAME  and with respect to the particular IPR
declarations with associated licensing terms that have been made in
FECFRAME.  I know how some other IETF working groups have dealt with
this, and it seems to have come out both ways depending on the group
and the licensing terms, but I’m not sure that FECFRAME has had this
discussion at the working group level to decide the path forward.

Best regards,

Vincent

> Cc: [email-masked];
[email-masked];
[email-masked]

> Subject: Re: Posting of IPR Disclosure related to QUALCOMM
Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02

> *** There is IPR disclosures on many specifications within the
IETF, and the standards in which they exist are useful to the whole
community.  Your premise is flawed, and thus much of the reasoning
below.

> *** Much of the best technology used on the Internet has/had IPR,
including Reed-Solomon codes, all video codecs, etc.

> *** You got an answer, which I'll repeat here: the one issue that
we discussed previously was addressed, but there are other issues which
we have identified that still need to be considered and addressed.

> *** The main change to the new IPR disclosures (and we updated
them all in RMT and FECFRAME, not just this one) compared to previous
is the licensing terms, that rationally should put the whole issue to
rest.  Clearly, this didn't mollify you, as it seems that any IPR, even
if the licensing terms are quite quite favorable, is unacceptable in
your opinion.  However, during the course of the IPR update process, we
did reexamine the spec and understood that there were still some
technical issues with the current draft that probably would have to be
changed to be clear of the particular IPR that is declared on the
current draft.  If I remember correctly, you also mentioned that you
would be adding some new elements to the next version of the draft, and
be aware and forewarned that these will also have to be carefully
scrutinized, as part of our obligations, to see if there is any
necessity to declare additional IPR.

> *** Nothing was achieved in RMT in my opinion.  That was a huge
waste of time and energy in my opinion to try and resolve the
situation, and didn't achieve anything, as still it is the case that QC
has declared IPR on some of your drafts and you have declared loudly
and publicly in many forums that this is not the case.  How is that a
good resolution?

(draft-roca-fecframe-rs)