Re: [IAOC] Sunday IAOC Overview Session

John C Klensin <john-ietf@jck.com> Wed, 20 February 2013 14:09 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43D521F880B; Wed, 20 Feb 2013 06:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.652
X-Spam-Level:
X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqkVFr+X5It9; Wed, 20 Feb 2013 06:09:34 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1EC21F8809; Wed, 20 Feb 2013 06:09:34 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1U8AMQ-000FJ8-Jg; Wed, 20 Feb 2013 09:09:26 -0500
Date: Wed, 20 Feb 2013 09:09:21 -0500
From: John C Klensin <john-ietf@jck.com>
To: Ray Pelletier <rpelletier@isoc.org>
Subject: Re: [IAOC] Sunday IAOC Overview Session
Message-ID: <399FCDD9714E1F6A26A8B460@JcK-HP8200.jck.com>
In-Reply-To: <F6CA3CD9-25D9-4D49-90D3-AC550C38DBB0@isoc.org>
References: <20130211225402.13757.92479.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130211222756.0b8a9540@resistor.net> <F73FF937-0D4C-4B47-B2E4-D11C24830256@isoc.org> <6.2.5.6.2.20130219223927.0a44f008@resistor.net> <F6CA3CD9-25D9-4D49-90D3-AC550C38DBB0@isoc.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: SM <sm@resistor.net>, ietf@ietf.org, iaoc@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
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>
X-List-Received-Date: Wed, 20 Feb 2013 14:09:35 -0000

--On Wednesday, February 20, 2013 07:44 -0500 Ray Pelletier
<rpelletier@isoc.org> wrote:

>> The last RFC Editor contracts are from 2008.  The last
>> Secretariat contract is from 2006.  All contracts except for
>> the ones with ICANN are never published even though that one
>> of the agreements mention that the contract will be published.
> 
> We will attend to all of these after Orlando to get the
> contracts published.  Each contract will need to be reviewed
> for business confidential material before posting, typically
> material that may be business proprietary so as to not reveal
> matters that may assist competitors.  It's a necessary
> courtesy.

Ray,

This doesn't help with the past, but I would have assumed (based
on experience in other organizations) that, if the rules require
posting contracts with confidential material elided, then the
issue of what is or is not treated as confidential would be part
of the contract negotiation process.  That would leave a version
with the appropriate material elided approved by both parties
along with the full contract and ready to publish as soon is the
contract is signed.  

It would have the small additional advantage of eliminating any
risk of a contractor claiming that everything they touch,
including broad SOW material, is confidential material that must
be protected from their competitors.  If a contractor were to
make such a claim during contract negotiation, you would
presumably just say "no, not acceptable in the IETF Community"
and move on.  If the claim were asserted only after the contract
was signed and work started, you could presumably be in for a
rather painful process.

Is there any reason why that approach cannot be taken in the
future?

regards,
   john