Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)

SM <sm@resistor.net> Sat, 21 December 2013 00:18 UTC

Return-Path: <sm@resistor.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6B1AD6C1 for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 16:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFp8iOtkfv5u for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 16:18:04 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D141ACCDC for <rtcweb@ietf.org>; Fri, 20 Dec 2013 16:18:03 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rBL0Hm26012662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Dec 2013 16:17:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1387585074; bh=zzwm9CJY0RJ7plmxQIElzNUMMiMq4NquS6kHKm0K0Sw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=D8frW+Rm8ip83x9Xhp8/kfbIvEKN4TkdUhhTDCqzSENEtr4fl/HcIcYaMoBWvjoSK CzSJe8wnsBaf/cIxcjhCJMQ2l+L7b2IeOfz/zc4cFf3fMXA4Ju+RuYua2ZZaw36k7R orFKkw0cnScz6d6L0AHjtFV3Jo5GB7Oi9L1IV51A=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1387585074; i=@resistor.net; bh=zzwm9CJY0RJ7plmxQIElzNUMMiMq4NquS6kHKm0K0Sw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oGsAWfgKaM26f5644088thDpI52T0EIYJbjBcCfozjUzlPs1jQ1dsO33apee04eFZ 39v40JaZqm6CgKkU/0psUKqlF7RWX+8PKssUg0NV3cx1RG4myeyRjAN9KxV1VWkDkj Su7PowHDGmqsGVoG6gD90uXv4CuzS4E+KXan8eyw=
Message-Id: <6.2.5.6.2.20131220150925.0d3e1130@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 20 Dec 2013 16:17:03 -0800
To: Ron <ron@debian.org>
From: SM <sm@resistor.net>
In-Reply-To: <20131220213922.GP3245@audi.shelbyville.oz>
References: <CA+E6M0n9frSRbbrXh=jczQETX13HX6LDGUCq2P4=6voXx93ZVA@mail.gmail.com> <CAHp8n2m5XNC8UfDswGfD=0qCPaddcsrg08FJKXnDsz-A+tWqzQ@mail.gmail.com> <CA+E6M0mwWVEAv6zeET1fwdL6oDB-Cxag64XNV1EJhk-oP3241g@mail.gmail.com> <52B38E3E.1040801@bbs.darktech.org> <52B40035.2010308@alvestrand.no> <0D649E40-454C-4945-B148-FD8AC6D49349@apple.com> <20131220185659.GN3245@audi.shelbyville.oz> <76E03D61-C9A5-4A93-BC0D-6773D603CD3B@apple.com> <20131220201906.GO3245@audi.shelbyville.oz> <CABcZeBPWGucyUYE8z6iQ3w5X64rCVPf23moWrcbWQiWzw95cxw@mail.gmail.com> <20131220213922.GP3245@audi.shelbyville.oz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Dec 2013 00:18:06 -0000

Hi Ron,
At 13:39 20-12-2013, Ron wrote:
>We don't appear to have that option in the case of H.264 though, in the
>light of declarations and statements that insist there would never be a
>licence granted for an alternative but similar technology, by at least
>one major IPR holder.
>
>I know we're edging out of the scope of things that this group is chartered
>to decide on, but I don't see any document that explicitly gives us the
>option to ignore these requirements either, and it does seem relevant to
>the decision that we need to make.
>
>Even after we decide on something (assuming that we do), it's still going
>to need to run the gauntlet of the broader IETF, and we seem to be somewhat
>perilously close to a loophole whereby I could reference something which
>I hold IPR on, that was published in the newsletter of my mother's knitting
>group, and then assert with a Straight Face, that I have no obligation to
>disclose, since it was Published Elsewhere.  And point to the discussion
>here as precedent for that.

I doubt that a mother would fall for that trick.  Here's some humor 
from the East:

   "This afternoon when I went to the kindergarten to pick my son up after
    school, he kept mumbling to me about how tired he was.  I said: What did
    you do today?  That little brat said something that made me almost spit
    blood, "After I finished arguing with the teacher, I had to then argue with
    the children, so how could I not be tired!"

    Should I give him a beating or should I give him a beating?"

Please note that there are two alternatives in the above. :-)

At 12:19 20-12-2013, Ron wrote:
>Do you have a reference to another technology that the IETF has *mandated*
>as essential to implement (effectively making it an IETF standard), without:
>
>  a) The IETF having change control over that technology (even if just by
>     reprinting a reference from some other source and making it an RFC).
>
>  b) Following all of the other relevant IETF process requirements, such as
>     timely IPR disclosure.
>
>As noted previously, there's a very big difference between something like
>an optional RTP profile and a mandatory appendage to some other standard.
>
>It seems out of scope for this working group to unilaterally break new
>ground in violation of the above requirements, and I'm not aware of any
>precedent that we'd be following in the footsteps of.  Is there one?

I'll step back a little.  VP8 is not a standards-track 
specification.  H.264 is not a standards-track specification.  There 
isn't any similar specification which has been published in the IETF 
or which is currently listed as part of IETF work.  In essence, the 
IETF does not have change control over such technology.

The quoted text does not provide much information to form an opinion 
about whether there are any process requirements which have been 
violated.  I suggest an informational reading of RFC 6701 and RFC 6702.

Regards,
-sm