On 2/5/2016 2:02 AM, John Gilmore wrote:
design a solution, 3) deploy the solution. The IETF is (only) step #2.
Yeah, let's not have the designers talking with the deployers. That can
lead to interoperability and harmony, which IETF is dead set against.
It important that the IETF not be the only place such folk can interact.
Successful protocols have active involvement of developers and
deployers from before the standards process, and long after.
There needs to be an /independent/ community establishing the needs and
exploiting the new capabilities. Again: the IETF is a way-station in
the life-cycle. It supplies some resources and process for a step along
the way, but it is not the anchor holding the community together.
Keeping the IETF mailing list active is often helpful, but that's
different from maintain a working group. For that independent
community, outside of the IETF it is common to have multiple, related
mailing lists, such as foo-interest, for general discussion, and
foo-dev, for discussion of the technical details and possible revisions,
and foo-ops, for deployment discussion.
As for the concern expressed in the thread for garnering feedback about
a new specification and then incorporating changes, that forms input to
a fresh effort to form a new working group, to do the next version of
the specification.
In fact there often is a a counter-productive effect of keeping a
working group actively seeking input to revisions: It communicates to
the industry that the specification remains unstable. Operators do not
like deploying unstable specifications; so they defer adoption.
d/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
