--On Friday, March 25, 2016 12:28 -0400 Russ Housley
<housley@xxxxxxxxxxxx> wrote:
> I really have a problem with the use of "IETF-sanctioned" in
> this bullet. RFC 2418 talks about design teams. It says:
>
> 6.5. Design teams
>
> It is often useful, and perhaps inevitable, for a sub-group
> of a working group to develop a proposal to solve a
> particular problem. Such a sub-group is called a design
> team. In order for a design team to remain small and
> agile, it is acceptable to have closed membership and
> private meetings. Design teams may range from an informal chat
> between people in a hallway to a formal set of expert
> volunteers that the WG chair or AD appoints to attack a
> controversial problem. The output of a design team is
> always subject to approval, rejection or modification by
> the WG as a whole.
>
> It seems to me that the design team, whether established by
> the leadership or self organized, intends to influence the
> IETF document. For this reason, I think that any design team
> participation must be considered a contribution.
Russ,
I agree with your logic, but think there is a practical problem
with the application. Part of my problem is believing that
2418, certainly with the best of intentions and probably
accidentally, overreached. I see two difficulties:
(1) If one considers only design teams and discussions formed as
offshoots of WGs (and I think that was what was on the radar of
the process that produced 2418), the above sort of works then,
modulo the second difficulty, treating design team discussions
and input as Contributions is reasonable. However, we also have
a lot of other things that can be considered design teams that
exist prior to WG creation (or even BOF or preliminary WG
formation requests). We've seen a lot of good work come out of
such discussions, work that might have been impeded by people
having to invest too much effort in trying to figure out what
they can discuss while swilling coffee or other stimulants or
intoxicants.
It is not hard to imagine a discussion in which someone says
"well, my organization has some experience in this area and I
can tell you about it informally in case you find that useful
but, if the discussion turns formal and/or starts developing
specific proposals, I'll have to step back because my company
wants nothing to do with IETF involvement on that topic". I
daresay that several of us have been in exactly that type of
situation. Once a WG gets started, we lose that type of (often
very valuable and operational input) because the person involved
has to stand well back. But, if we can avoid losing it
entirely, especially in the earliest stages of thinking about
design, it seems to me that is in the best interests of the
Internet.
Equally or more important, the more requirements we put on those
sorts of early discussions, the more we create incentives for
creation of specifications or proto-standards in real or
imaginary organizations outside the IETF and hence not subject
to its rules. Whatever the Foundation for Operational
Optimization of Long-haul Services might be, it isn't an IETF WG
or Design Team. When it brings a nearly-complete spec (they
say) to the IETF and says "standardize this" and "already
deployed", we don't have much leverage (probably none) on IETF
disclosures from the folks and companies that did the design:
other than listed document authors, they can hide completely
from Contribution-based requirements. In pragmatic terms, I
would much rather allow informal and unconstrained discussions
under the IETF umbrella and then have open and transparent
discussions that conform to our IPR rules (and that allow the
IETF consensus process early change control) than be pushed to
adopt 3/4-baked proposals/specifications of sometime-dubious
origins.
(2) We seem to be going down a path in which it is necessary to
create documentation in situations where Contributions might
occur, if only to avoid "she said X and therefore made
Contributions and Participated"... "nope, never said that and
wasn't paying attention if it was said" conversations in which
discovering the reality is, at best, hard. That is easy with
mailing lists and almost as easy with WGs that record their
sessions and/or product minutes or logs that identify individual
comments. It is hard or impossible to do with an informal
gathering and discussion. I don't think it is in our interest
to discourage those discussions.
While I'm dissatisfied with the terminology, I assume those
sorts of distinctions are what "IETF-sanctioned" was trying to
get at.
Recommendation, with the disclaimer that I have looked at the
relevant section but haven't studied the entire I-D...
Insert an additional subsection, perhaps as part of 5.1, that
talks about voluntary (non-required) disclosures. Point to our
rationale for wanting (needing?) disclosures to improve the
quality of standards and preserve the integrity of the IETT
(there is material in Sections 2, 3.1, and the introduction to
Section 5 but it may not be good enough and/or sufficient).
>From that required point of view, the current text focuses too
much on obligations and requirements and avoids talking about
doing things just because they are The Right Thing to Do. In
that section, encourage (but do not require) disclosures if
there are any interactions, whether possibly interpreted as
Contributions or not, that might shape or influence IETF
documents or ideas that could end up in IETF documents. I'd
like to make that broad enough to suggest that any relevant
FOOLS participants have a moral obligation to disclose both
their conversations and any associated IPR.
Then go ahead and narrow things a bit, although I still hope we
can do better that "IETF-sanctioned". Remember that the _real_
risk here is that someone influences a WG or Last Call
discussion in some significant way without the community having
a chance to evaluate that influence attempt in the light of
outside motives or agendas (of which, of course, hidden IPR is a
tiny fraction of the bad possibilities).
It may occasionally be worth remembering that part of the reason
for the IETF and the switch from a development and discussion
point for technical specifications to an SDO was that the
community believed that SDOs with lots of procedures,
hair-splitting rules, and an abundance of lawyers, were not a
good way to develop standards for the Internet or any other set
of high-quality technical specifications. We shouldn't
accidentally re-invent ourselves into the model we were trying
to avoid.
john