Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 May 2011 15:06:59 -0400

(As individual)

I started to reply to this some time ago, and never got around to 
sending it. Comments inline.

	Thanks,
	Paul

On 4/22/2011 1:41 PM, Stephan Wenger wrote:
> Hi Paul, group,
> Some of the issues you raised are based on my input, so I think it's only
> fair if I answer them.
> Please see inline.
> Stephan
>
>
> On 4.22.2011 06:37 , "Paul Kyzivat"<[email-masked]>  wrote:
>
>> [...]
>>
>> Why is REQMT-4 SHOULD while REQMT-5 is MUST?
>> It seems that REQMT-7/REQMT-8 is a similar pairing, but in that case
>> both are MUST strength.
>
> It's an IPR concern that led to the SHOULD.  I prefer the WG has the
> freedom to leave out specification text addressing this requirement if IPR
> surfaces, which (in this case) seems likely to me.  Sorry for not being
> more specific on this public mailing list.

If there are IPR issues I would prefer to lay them on the table rather 
than have them be an unspoken subtext driving such decisions.

If you have IPR concerns, is it about IPR that has been disclosed, or 
about stuff you know of that hasn't been disclosed, or about stuff you 
don't know about but suspect might exist?

> As a general comment, IIRC the previous revision of the draft contained
> only MUST requirements.  I personally prefer "soft" requirement language,
> so to be able to address concerns of whatever nature (including, but by no
> means limited to IPR) without having to abandon one of our own
> requirements.

I find the use of SHOULD be generally cause confusion.
Its especially a problem in protocol specs, because many implementers 
treat it as "not required".

Its slightly different in requirements, since at the end of the day we 
still get to judge if we like the resulting mechanism.

But the distinction then becomes one of "must-have" vs. "nice-to-have". 
And deciding which is among what we need to be deciding now. It really 
leaps out at you when you have some MUSTs and some SHOULDs - it begs for 
an explanation of how the choice was made.

>>     REQMT-6:   The solution MUST include a mechanism to support a means
>>                of describing dynamic changes in the streams offered by
>>                the sender; and dynamic changes in the streams requested
>>                by the receiver.
>>
>> IMO "a mechanism to support a means" is excessive. How about
>>
>>     REQMT-6:   The solution MUST include a mechanism to support
>>                describing dynamic changes in the streams offered by
>>                the sender; and dynamic changes in the streams requested
>>                by the receiver.
>
> Sounds OK to me.

> Allyn and I had a discussion about this requirement.  I was worried that
> it would not be within the charter.  Allyn proved me wrong.  However, it
> is my understanding that implementing this "solution" requires technology
> that goes beyond the exchange of properties and capabilities during
> session setup.  We are not talking about a bunch of SDP codepoints here.
> This is real-time conference control for media.  Is this really what we
> want to do in this WG?  It's conceptually a different problem than just
> announcing "this session comes from the right camera".  Do we have an idea
> what we want to use here?  Mediactl?
>
>>
>> I don't understand exactly what point REQMT-10 is trying to make that is
>> different from REQMT-9. I think maybe REQMT-10 needs a few more words.
>
> Agreed.  10 seems to be a generalization of 9.
>
>>
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>
>
>

---

From: "Roni Even" <[email-masked]>
Date: Thu, 5 May 2011 10:32:18 +0300

Stephan,

I agree with Peter, this is about a mechanism and not about the data itself.
So I am not sure about the concern for IPR on being able to describe sender
capabilities.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Musgrave
Sent: Saturday, April 23, 2011 8:52 PM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] FW: New Version Notification for
draft-romanow-clue-telepresence-requirements-02

Hi Stephan

On 2011-04-22, at 1:41 PM, Stephan Wenger wrote:

 

REQMT-4:   The solution SHOULD support a mechanism by which a sending
              endpoint or MCU can describe aspects of its
              characteristics and attributes.

Do I understand this to mean that you are concerned about IPR regarding the
mechanism of describing the aspects and characteristics? 

Or do you mean that there might be IPR associated with the
characteristics/attributes themselves?

If the later, then I think a MUST would be ok, since the requirement is for
a mechanism.

I have the opposite bias - I prefer MUST for requirements - otherwise why
call them requirements?

A section which describes additional goals (as opposed to requirements)
could be a place for SHOULD clauses.

Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 May 2011 08:52:17 -0400

(as co-chair)

If people have concerns about IPR, I would like to see them aired.
And if anyone is concerned about IPR they are aware of, then they are 
*obligated* to file an IPR disclosure.

But lets not "self censor" without explaining that is what is happening.

	Thanks,
	Paul

On 5/5/2011 3:32 AM, Roni Even wrote:
> Stephan,
>
> I agree with Peter, this is about a mechanism and not about the data
> itself. So I am not sure about the concern for IPR on being able to
> describe sender capabilities.
>
> Roni Even
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Peter Musgrave
> *Sent:* Saturday, April 23, 2011 8:52 PM
> *To:* Stephan Wenger
> *Cc:* CLUE
> *Subject:* Re: [clue] FW: New Version Notification for
> Do I understand this to mean that you are concerned about IPR regarding
> the mechanism of describing the aspects and characteristics?
>
> If the later, then I think a MUST would be ok, since the requirement is
> for a mechanism.
>
> I have the opposite bias - I prefer MUST for requirements - otherwise
> why call them requirements?
>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 05 May 2011 08:29:53 -0700

Right.  I should have read this more carefully.  For this one, MUST is fine
with me.
(This was one of the requirements where Allyn and me worked on in a rather
uncoordinated fashion, late at night.)
Stephan

From:  Roni Even <[email-masked]>
Date:  Thu, 5 May 2011 10:32:18 +0300
To:  'Peter Musgrave' <[email-masked]>, Stephan Wenger
<[email-masked]>
Cc:  'CLUE' <[email-masked]>
Subject:  RE: [clue] FW: New Version Notification for
draft-romanow-clue-telepresence-requirements-02

Stephan,
 
Roni Even

Hi Stephan

 

Peter

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 05 May 2011 08:55:14 -0700

Hi Paul,

>But lets not "self censor" without explaining that is what is happening.

Sorry, but that cannot be left standing as is.

The requirement for IPR disclosure for me extends to those patent claims
that I am reasonably and personally aware of AND that are assertable by my
employer or sponsor.  Sections 6.1.1 and 6.1.2 of RFC 3979.  Rest assured
that I will disclose any of such IPR, perhaps in more detail than I'm
obliged to do so.  I have a history in doing exactly that.

However, if the (suspected) patent claim is not owned by my employer or
sponsor, I'm only "encouraged" to send mail at ipr@ietf and/or make a
third party disclosure.  Section 6.1.3 of RFC3979.  There is a reason for
this choice of (weak) language in RFC3979.  Making third party disclosures
involves certain risks in some legislations, especially for people like
myself who do patent work for a living (and standardization as a hobby :-).

Therefore, I regret to state that, except in most unusual situations, I
will not talk openly about someone else' IPR in any other but the vaguest
terms.  Specifically, I will not name patent numbers, nor owners.

That said, I do have to keep my employer's competitive position in mind.
I want to avoid stepping on someone else's patent claims because we
implement CLUE, and I want to avoid being driven out of the market because
we don't (obviously hypothetically speaking in both instances).
Therefore, I need to warn about someone else's IPR, or "kill" technologies
I don't like for this reason based on fake technical arguments.  The
latter is common in standardization, but I think the former is more honest
and less damaging and, ultimately more efficient.

I promise not to throw FUD around, but then again, the definition of FUD
is vague and context sensitive (depends on business model, own IPR
position etc. etc.).

In consequence, I expect to continue with vague warnings in the hopes that
participants do their own research.

Regards,
Stephan