Re: [oasis-charter-discuss] Thoughts on comments received on CfC for "Best Current Practices" TC [BCP]

[Jamie Clark <jamie.clark@oasis-open.org>]

Quick answer to a quick question -- a TC which explicitly limited itself, in its charter, to create only Committee Notes (that is, to not submit any Committee Specifications), would demonstrably never be able to impose a patent commitment on its participants, and thus should be viewed as "IPR-safe" in that sense.

Jamie

On Wed, Nov 13, 2019 at 12:45 PM Bret Jordan <bret.jordan@broadcom.com> wrote:

Is there another vehicle at OASIS to do this kind of work? I was under the impression there is not. Maybe Jamie has thoughts on this? Â

Bret

On Nov 13, 2019, at 12:57 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I am just going to throw out one side note here.... IBM has an internal process we have to go through to join any TC, due to the strict IPR obligations they carry. I know for a fact that many other organizations share a similar process.

Â

Due to the steps of process and what it involves, it prohibits myself or anyone else at IBM from participating in this best practice TC (if anyone wants more details on why, I perhaps could share over a beverage sometime) without me jumping through a whole bunch of hoops that I really can't justify.

Â

Simultaneously, I do not imagine that the proposers here, intend for the output of this group to be bound by any IPR obligations.

Â

As such, is a TC really the best vehicle for this, knowing that this may well limit who is able to feed into these guidelines?

Â

-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson

Â

Â

----- Original message -----
From: Jamie Clark <jamie.clark@oasis-open.org>
Sent by: <oasis-charter-discuss@lists.oasis-open.org>
To: bret.jordan@broadcom.com, Allan Thomson <athomson@lookingglasscyber.com>, Duncan Sparrell <duncan@sfractal.com>, Martin Chapman <martin.chapman@oracle.com>, jmbrule@radium.ncsc.mil
Cc: Chet Ensign <chet.ensign@oasis-open.org>, oasis-charter-discuss <oasis-charter-discuss@lists.oasis-open.org>, Gershon Janssen <gershon@qroot.com>
Subject: [EXTERNAL] [oasis-charter-discuss] Thoughts on comments received on CfC for "Best Current Practices" TC [BCP]
Date: Wed, Nov 13, 2019 2:18 PM
Â

Dear convenors and all:Â

Â

I hope to be able to join you for the BCP TC convener call later today. I read through the comments to your proposal, and in light of some raised objections, let me contribute a few questions and observations. (Two possibly-key questions for the convenors appear at the bottom of this note.) Â

Â

Disclaimer: (a) These only are non-normative opinions from one OASIS staff member, with some experience in this field, but as suggestions, not as rulings by OASIS or its TC Administrator, who this decade is Chet not me. (b) This is not a member comment that requires logging or response under our rules. It's facilitative optional staff feedback, post-deadline, after reviewing the logged comments.

1. Critiques of charters generally: We should be very hesitant to critique any OASIS TC proposals for reasons other than rule conformance. OASIS has distinguished itself for years as a forum where a sufficient number of supporters may launch a proposal, without risk of political or technical disagreements about its merit. That's a feature of OASIS, not a bug, Any objections to elements of this charter should be viewed primarily by whether they're permitted by our rules. That some proposed project may be thought redundant, or low priority, or has disputed technical or policy goals, normally never has been an actionable objection in our system.
2. TCs about TCs: OASIS has hosted multiple TCs over 20 years whose scope is to create internal guidance or suggested practices for TCs and other standards projects -- such as the Conformance TC (1999-2002) and the TAMIE TC (2009-2017). So it seems clear that development of useful methods for running a TC is not generally out of scope for an OASIS TC.Â
3. Which deliverables are really a problem? Reading this proposed charter and comments, I did not see as many collisions between OASIS official guidance, and these proposed deliverables, as some others. I'll send along a couple of examples of (in my opinion) clearly virtuous and useful proposed work products later. It looks to me like there's some good stuff in here, and I hope OASIS can find a way to support its goals.
4. Still, OASIS can act to keep its rules clear. At the same time, though, this project's plans do relate to core interests of OASIS rulemaking. As several have suggested, I think OASIS does have some legitimate interest in asking for changes to charter content if it creates serious confusion or explicit rule collisions. Let me mention two specific possible problem areas. Â
5. "Best practices". First, OASIS has almost always avoided the phrase "best practices" in its own outputs, because we didn't want either to incur the implied liability of that assertion, and (in light of the extreme breaths and diversity of OASIS dev communities) did the identification of any one method as "best" seems potentially misleading in many cases. So, to process this charter and its proposed name, OASIS may need to confirm whether the words "best practices" are in fact reserved by us, or prohibited by us, as a matter of policy. My question to you: is that name/claim a negotiable element of your proposal, or would OASIS need to place it on hold, if that determination requires formal action before approval?
6. Handling any direct contradictions. Second, there are some concerns expressed that, without clear scope boundaries, there could be direct collisions between the TC's output and OASIS rules, creating confusion for implementers and members. By collision, I mean a case where the TC's finalized spec bearing the OASIS says normatively that standards developers should do X, directly contradicting an OASIS process rule or Instruction that today says that standards developer should do Not-X; or the spec asserts a normative requirement that OASIS does not today require. It's possible that those sorts of conflict could be avoided simply by including a few scope limitations in the charter. My question to you: How do the proposers wish to address rule collisions? Here are some examples for further thought (again, just opinions here):

SAMPLE SCOPE CLAUSES

• TC work product that addresses existing OASIS process rules or guidance must be clearly labeled as either conforming to, or proposing changes to, rules currently in force.
• Any proposals to change the OASIS process rules or guidance must be presented in a manner that does not give the appearance of OASIS approval, effective rule amendments, or an existing, enforced alternative or optional rule set.
• OASIS TC Admin reserves the right to insert appropriate special captions within any TC work product, including its front matter, to make the foregoing distinctions clear.

Someone mentioned a concern with alignments with OASIS rules changing over time, as well. I can only note that all OASIS publications are timestamped. Very possibly, some of the 2001 Conformance TC publications have obsolete elements in 2019 ... but we don't require that they be updated or deleted. They're historical conclusions speaking as of the time of that publication.

Â

Hope this helps. Opinions only. Cordially Jamie

Â

James Bryce Clark, General Counsel, OASISÂ

Advancing open data, code and standards for the global information society https://www.oasis-open.org/staff

OpenMobilityFoundation.org (new), an OASIS-hosted open source program
EU 2019 Rolling Plan for ICT Standards: https://j.mp/EUstds2019

Borderless Cybersec Oct 2019:Â DC 2018, Prague 2017,ÂNYC 2017,ÂTokyo 2016,ÂBrussels 2016,ÂWorld Bank 2015

Â

Â