Subject: Re: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04

From: Curtis Villamizar <[email-masked]>
Date: Fri, 04 Oct 2013 16:46:25 -0400

In message <[email-masked]>
IETF Secretariat writes:
 
>  
> Dear Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David Ward:
>  
>  An IPR disclosure that pertains to your Internet-Draft entitled "OSPF Traffic
> Engineering (TE) Metric Extensions" (draft-ietf-ospf-te-metric-extensions) was
> submitted to the IETF Secretariat on 2013-09-17 and has been posted on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/2199/). The title of the IPR disclosure is
> "Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-
> extensions-04."");
>  
> The IETF Secretariat
>  
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

Since two of the authors are named on the patent, it is hard to
understand how they could not have known about the IPR.

Since the patent was applied for in 2004 and the first iteration of
this draft was in 2011, and at least two co-authors of the draft knew
about the patent by way of also being co-inventors of the patent, this
appears to be a blatent late disclosure of IPR.

Would the authors please explain how this was allowed to occur.

Also, the patent seems (to me) to apply only to local-repair paths and
not to primary paths.  Would the inventors please confirm (or deny).

I'm not sure how all the prior art on using multiple metrics,
including additive constraints on "paths", could be construed as not
applying to "local-repair paths".  But then again, I'm not a lawyer
and hope never to be one.  The patent system at work again.

Curtis

---

From: Acee Lindem <[email-masked]>
Date: Thu, 10 Oct 2013 21:24:10 +0000

Hi Curtis, 
The draft was first presented at IETF 80 in Prague in the Routing, ISIS, and OSPF WGs. At the time, the biggest concern was the overlap with other delay/loss encoding drafts in the CCAMP WG. I looked at the minutes of the 3 WGs and IPR was not declared or questioned. I also spoke to one of the patent authors and the timing of the IPR declaration was not intentional - both the draft/patent authors are co-authors on a fair number of Internet drafts and patents. In the future, we'll assure the IPR question is raised prior to making any draft an OSPF WG document. 
I won't comment as to whether the simple encoding and advertisement of these delay/loss metrics actually violates a patent specifying specific usage of the metrics. 
Thanks,
Acee

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 11 Oct 2013 12:09:44 -0400

Acee,

Thanks for the reply on this and providing the history from WG chair
perspective.

Thanks also for considering explicitly asking for IPR statements from
the authors when accepting a WG doc.  It would also be helpful to ask
for IPR statements before each WGLC the way the MPLS WG does.

btw- It would appear to me that advertising the parameters is not the
issue, but rather using them for delay bounded path computation for
the protection LSP is the reason the IPR would apply.  I think that
mention of use in delay bounded path computation was added late in the
game and may account for the late IPR.

Curtis

In message <[email-masked]>
Acee Lindem writes:
> 
> Hi Curtis, 
>  
> The draft was first presented at IETF 80 in Prague in the Routing,
> ISIS, and OSPF WGs. At the time, the biggest concern was the overlap
> with other delay/loss encoding drafts in the CCAMP WG. I looked at the
> minutes of the 3 WGs and IPR was not declared or questioned. I also
> spoke to one of the patent authors and the timing of the IPR
> declaration was not intentional - both the draft/patent authors are
> co-authors on a fair number of Internet drafts and patents. In the
> future, we'll assure the IPR question is raised prior to making any
> draft an OSPF WG document.
>  
> I won't comment as to whether the simple encoding and advertisement of
> these delay/loss metrics actually violates a patent specifying
> specific usage of the metrics.
>  
> Thanks,
> Acee 
>