Subject: [rsvp-dir] Fwd: AD followup: draft-ietf-tsvwg-rsvp-security-groupkeying - IPR discussion

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 22 Jul 2011 09:09:50 +0100

RSVP directorate,

We can't find any discussion of this in TSVWG, so we'll be looking for 
comments on how this IPR should be considered for an INFO doc from the WG.

Best wishes,

Gorry

-------- Original Message --------
Subject: AD followup: draft-ietf-tsvwg-rsvp-security-groupkeying
Date: Mon, 18 Jul 2011 02:40:48 -0400
From: David Harrington <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>

Hi,

Has the WG explicitly discussed acceptability of the IPR terms related
to this document? The RAND terms apply for compliance to the standard,
but this is not being submitted as a standards-track document. The terms 
in the IPR declaration do not seem to provide non-assert status for 
implementing an Informational document.

Has the WG discussed this?

If so, can you provide a link to the relevant thread?

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 22 Jul 2011 14:02:28 +0100

Gorry,

I agree IPR on this was never discussed in tsvwg to my knowledge. The 
IPR declaration doesn't point to the specific IPR (which it doesn't 
have to), so we can only guess which of the approach(es) in the doc 
are encumbered.

I reviewed this one a couple of times. As you say it's informational; 
it is primarily a comparative guide. Given this implies there are no 
specific issues about normative statements, the only IPR issue would 
be if the guidance is *unjustifiably* tilted towards a particular 
approach (assuming that might be the patented approached).

When I reviewed it, I wasn't aware there was IPR on this one, so my 
"unjustified bias" detector wasn't turned up to max sensitivity. But 
in retrospect I'm very happy that all the guidance is technically 
sound. So I can't see there's any danger here.

Bob

At 09:09 22/07/2011, Gorry Fairhurst wrote:

>RSVP directorate,
>
>We can't find any discussion of this in TSVWG, so we'll be looking 
>for comments on how this IPR should be considered for an INFO doc from the WG.
>
>Best wishes,
>
>Gorry
>
>but this is not being submitted as a standards-track document. The 
>terms in the IPR declaration do not seem to provide non-assert 
>status for implementing an Informational document.
>
>_______________________________________________
>rsvp-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rsvp-dir

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bruce Davie <[email-masked]>
Date: Fri, 22 Jul 2011 09:18:48 -0400

Bob,
 Thanks for the thoughtful analysis. Since the IPR owner in this case is also my employer, I think I have to recuse myself from the discussion.

Bruce

On Jul 22, 2011, at 9:02 AM, Bob Briscoe wrote:

> Gorry,
> 
> I agree IPR on this was never discussed in tsvwg to my knowledge. The IPR declaration doesn't point to the specific IPR (which it doesn't have to), so we can only guess which of the approach(es) in the doc are encumbered.
> 
> I reviewed this one a couple of times. As you say it's informational; it is primarily a comparative guide. Given this implies there are no specific issues about normative statements, the only IPR issue would be if the guidance is *unjustifiably* tilted towards a particular approach (assuming that might be the patented approached).
> 
> When I reviewed it, I wasn't aware there was IPR on this one, so my "unjustified bias" detector wasn't turned up to max sensitivity. But in retrospect I'm very happy that all the guidance is technically sound. So I can't see there's any danger here.
> 
> 
> Bob
> 
>> We can't find any discussion of this in TSVWG, so we'll be looking for comments on how this IPR should be considered for an INFO doc from the WG.
>> 
>> Best wishes,
>> 
>> Gorry
>> 
>> but this is not being submitted as a standards-track document. The terms in the IPR declaration do not seem to provide non-assert status for implementing an Informational document.
>>