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

Ron <ron@debian.org> Fri, 20 December 2013 21:39 UTC

Return-Path: <ron@debian.org>
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 868C21AE19D for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 13:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ooFbV_5kumBq for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 13:39:28 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3E1AE16B for <rtcweb@ietf.org>; Fri, 20 Dec 2013 13:39:27 -0800 (PST)
Received: from ppp118-210-62-207.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.62.207]) by ipmail07.adl2.internode.on.net with ESMTP; 21 Dec 2013 08:09:25 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 9D67B4F8F3 for <rtcweb@ietf.org>; Sat, 21 Dec 2013 08:09:23 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pONDHEVzGzgU for <rtcweb@ietf.org>; Sat, 21 Dec 2013 08:09:22 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id E92704F902; Sat, 21 Dec 2013 08:09:22 +1030 (CST)
Date: Sat, 21 Dec 2013 08:09:22 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABcZeBPWGucyUYE8z6iQ3w5X64rCVPf23moWrcbWQiWzw95cxw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
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: Fri, 20 Dec 2013 21:39:30 -0000

On Fri, Dec 20, 2013 at 03:27:55PM -0500, Eric Rescorla wrote:
> On Fri, Dec 20, 2013 at 3:19 PM, Ron <ron@debian.org> wrote:
> >> If we insist on a recursive closure of all normatively referenced documents,
> >> the database would be so overloaded as to be unreadable and a mess.  As far
> >> as I know, no body has gone down that (insane, IMHO) route, expecting that
> >> people can work out for themselves that if a document is published by body A,
> >> it may well be in body A that you’ll find the declarations.
> >
> > 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).
> 
> This applies to plenty of technologies. One example would be AES. The citations
> for that are to the AES FIPS.

Ah, thanks!  Though even that one seems somewhat closer to the RTP profile
case than what we have proposed before us here - but it is a thinner slice
of the salami.

Maybe I'm still missing other cases but in RFC 5246 it's only mandatory
"In the absence of an application profile standard specifying otherwise"
which doesn't seem to be further defined in either that document, or in
RFC 6919 :)

And it would also seem to be subject to the IETF requirement that security
technologies MUST be strictly RF.  Which leaves the door open that the IETF
_could_ always assume change control of it if the need ever arose.  Which
seems reasonably pragmatic, even absent the "mandatory unless" language,
and the IETF does make sensible exceptions for strictly RF technologies.

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.


The IETF requirements as published would seem to be very clear.  Where does
our leeway come from to blur those lines here?

  Cheers,
  Ron