Re: IETF Last Call for two IPR WG Dcouments

Olaf Kolkman <olaf@NLnetLabs.nl> Thu, 27 March 2008 09:36 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC35E3A6B05; Thu, 27 Mar 2008 02:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.644
X-Spam-Level:
X-Spam-Status: No, score=-100.644 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5fT9Wx97rJ4; Thu, 27 Mar 2008 02:36:07 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18423A6A0D; Thu, 27 Mar 2008 02:36:06 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02823A6AA0 for <ietf@core3.amsl.com>; Thu, 27 Mar 2008 02:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjF1EFR+EWYa for <ietf@core3.amsl.com>; Thu, 27 Mar 2008 02:35:58 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 7719228C230 for <ietf@ietf.org>; Thu, 27 Mar 2008 02:35:58 -0700 (PDT)
Received: from Miffy.lan (a82-95-132-144.adsl.xs4all.nl [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2R9XYeU045925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2008 10:33:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl)
Message-Id: <59EDC2DC-7692-4716-8753-50A1826198A3@NLnetLabs.nl>
From: Olaf Kolkman <olaf@NLnetLabs.nl>
To: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20080324200545.D6E6328C3AE@core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: IETF Last Call for two IPR WG Dcouments
Date: Thu, 27 Mar 2008 10:33:24 +0100
References: <20080324200545.D6E6328C3AE@core3.amsl.com>
X-Pgp-Agent: GPGMail d52 (v52, Leopard)
X-Mailer: Apple Mail (2.919.2)
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 27 Mar 2008 10:33:35 +0100 (CET)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1313435231=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


While reviewing the documents I tried to determine how the 4 streams  
currently defined in RFC4844 fit into the framework.

Although the stream is not specifically mentioned it is clear that the  
incoming rights document applies to the IETF Stream.

To me it is clear that a contribution to the IAB is explicitly bound  
by the rules (including the No Duty to Publish rule, that allows for  
confidential information to be supplied to the IAB), so are  
contributions from the IAB, i.e. IAB stream document. I conclude this  
from the fact that "IAB" is part of the IETF under the definition in  
1.e. However, I may be over-interpreting, and the status of the  
incoming rights for the IAB stream is also not captured.

The independent stream document are clearly excluded by section 4 of  
the document.

It is not quite clear where the IRTF stream document live. This could  
be fixed in a document which defines the IRTF stream.

I would think that the document would gain in clarity if it explicitly  
ties the incoming rights to the streams as defined in RFC4844 and also  
explicitly calls out that if new streams would be defined those should  
specifically define if and how rights are transfered to the IETF Trust.



--Olaf (no hats)

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf