[secdir] a different thing (was: Fwd: DISPATCH and strategies for standards maintenance)

[Stephen Farrell <[e-mail]>]

Hiya,

Way down below, Harald says:

"
What the DISPATCH process fails to achieve is what a good directorate
should have been doing: Taking a view of the whole area of the protocol
suite, and noticing things like:
"

followed by a list of what Harald figures are bad things found in
the RAI area.

We don't tend to do anything like that in secdir, and I'm not sure
how we could if we wanted to, or even if we should want to, but I
suspect you'd be the folks involved if we ever did.

So with no specific idea in mind, I wonder would (somehow) getting
that kind of review be a good thing? And if so, any idea on how we
might be able to do that? (Without us all using it to beat up on
our least fav security technology:-)

I'd be interested in what you think about that, on the list now and
maybe for chatting at the secdir lunch for those of us who'll get
to IETF95.

Cheers,
S.



-------- Forwarded Message --------
Subject: DISPATCH and strategies for standards maintenance
Date: Fri, 22 Jan 2016 08:33:01 +0100
From: Harald Alvestrand <[e-mail]>
To: [e-mail]

Recently, in a response to a Last Call on
<draft-campbell-art-rfc5727-update-02>, I wrote the following on the
IETF list:

  Objection:

  I find the DISPATCH style of review to be a horribly broken idea.

  I also find the use of the term "working group", and the procedures of
  working groups, for what is effectively a permanent review panel and a
  standing BOF venue to be counterproductive and destructive of getting
  work done.

  This document proposes recommending this method as a generic tool that
  can be used in areas outside of the limited scope of SIP extensions -
  something I think is taking a bad idea and making it even more harmful.
  (RFC 5727 already said it would do that, but the RAI area has not
  followed up on this particular bad idea from RFC 5727, letting
  initiatives like WEBRTC flourish outside of the DISPATCH process, so the
  damage done by DISPATCH has been limited.)

  I therefore object to this document being published as a BCP.

These words were rather harsh, and were commented on as such. It seems
best for the community that I spend some words on describing why I came
to this conclusion.


When I came to deal with WebRTC and the assocated areas, I believed (not
having examined the area too closely) that with the SIP suite, which
uses SDP and RTP, we had achieved a reasonably functional and
architecturally competent real time communications suite.


I was wrong.


It turned out that a number of fundamental problems existed, including:


* A lack of clarity on the connection between SDP and RTP - the word
“session” was used at both layers, but represented different things.
* A lack of consensus on how one negotiated session properties that
applied in one direction only.
* An SDP architectural misfeature that led to a completely bogus
requirement that differing media types be carried on different UDP ports
* A number of issues with use of addresses in signalling - including the
formulation of rules like the “SDP patch-up offer/answer” for making one
set of addresses (in m-lines) match up with another set of addresses (in
ICE)
* A general acknowledgement that certain fairly absolute rules, like
“always use RTCP”, were widely ignored in the industry and couldn’t be
depended on
* A number of rules around SSRCs that were based on an operating
environment that doesn’t exist in practice (multicast groups) - in
particular SSRC collisions - which have made these identifiers much less
powerful than they might have been.
* A number of long-standardized extension features (CAPNEG in
particular) that are largely ignored by industry due to complexity, but
are still used to block other efforts by saying “why can’t you use X
instead”.
* A number of unfinished products (EKT in particular) that seemed to be
a good fit for some problem - but somehow never seemed to cross the
finish line.


This list is far from exhaustive. We have been chipping away at the
issues that mattered to the WebRTC effort, while attempting to make sure
the issues we were not addressing did not affect the effort (by not
using the features they referenced).


I observed the DISPATCH process for much of the time of my engagement.
The DISPATCH process is reasonably efficient …. at solving the wrong
problem.
The ideal DISPATCH task is a proposal to address a small problem (or
paper over some deficency in the protocol for a certain set of cases).
It allows the ADs to delay such a proposal for 3 months without any
controversy (“until the next IETF meeting”), and for 6 months if it
turns out to need a WG (“first DISPATCH, then you write a charter, then
you meet”). (Sometimes such delay is a good thing; some bad ideas just
need the time to die.)
Once the proposal reaches a DISPATCH meeting agenda, it gets some
review, it gets some comments, it gets some recommendation (maybe) - and
then it can move on, if the proposers still have energy for the push,
and if any of the experts in the area have bought into the idea enough
to give it the guidance it needs to achieve non-conflict with all the
other small patches people are working on.

What the DISPATCH process fails to achieve is what a good directorate
should have been doing: Taking a view of the whole area of the protocol
suite, and noticing things like:

* SIP is largely non-interoperable. It’s useful to connect islands of a
single product while claiming standards conformance, and it’s easier to
wrangle into some semblance of interoperability than proprietary
protocols - but it’s not “plug and play”.
* SDP is a world picture that is not capable of representing a
significant subset of the interesting ways in which people want to
interconnect. This means that solutions that use SDP have to work around
SDP, not with it.
* RTP is showing its age. Security is a bolt-on, and RTCP is more of an
extension platform than it is an useful set of features in the base spec.

It’s clear that the industry needs a robust, interoperable, secure
protocol suite for real time communication. It’s also clear that the
IETF is the logical venue for that to happen.


But DISPATCH isn’t the way to get there.

--
Surveillance is pervasive. Go Dark.