You could call me a blue-eyed optimist, but I have brown eyes ...
What other motivation could there be to publishing documents earlier
than vendors implementing and shipping it earlier? And if they do
that, there is hardly any room for any substantial or backwards-
incompatible changes. And the size of the installed base created
by the early adopters significantly limits usefulness of any features
or backwards-compatible changes that are incorporated into later
revisions of the document.
I think you're conflating two steps here:
- implement and test, including interop testing
- shipping in a product
There is a reason to implement and test, including Interop testing. Robert
Sparks can speak (orders of magnitude :-) more authoritatively than I can,
but my impression from looking at SIPit reports, is that people in the RAI
community really do have implentations, including implementations used for
interop testing, that are NOT present in their products, and they do expect
to feed back based on interop testing and see changes to the protocol that
might require implementation changes.
But beyond this ... you can implement any draft - you just have to think
that's a good idea, and right now, people are making the decision to
implement any particular draft with no guidance.
In a previous life, I worked for a company making network monitor equipment.
We hade requests from large carriers to support monitoring one of the
SIGTRAN specs - I'm thinking it was
https://datatracker.ietf.org/doc/draft-ietf-sigtran-sua/ - in about six
different flavors of the draft (out of the 16 versions published as working
group documents).
- All had been implemented.
- All had been deployed.
- No two were 100-percent compatible.
- None carried an identifier that said "this is -09" or whatever, so we used
heuristics to guess which version of the protocol we were looking at.
- Some carriers had more than one version of the protocol running in the
networks (-07 between these two boxes, -09 between these other two boxes).
And none of these large carriers had waited for a proposed standard (it
still hadn't been approved for publication when they were asking us to
support six flavors of the draft).
If having a working group say "we think this version of the draft is stable
enough to code to" is going to make things worse, I wouldn't mind
understanding why that's true.
I will agree that I hear people say "we can't change the spec from v03 of
this because people have implemented it", but looking back, they were
pointing to TINY communities, compared to real deployments that happened
later. In the case I was talking about with Eric Berger yesterday, the
"can't change the spec from -03 because people have implemented it" draft
was finally published at -08. -03 DID change, several times.
If someone manages to make a convincing argument to protect an early
deployment to a tiny user community, that prevents us from solving problems
with a protocol that would allow wider deployment, that's our fault.
Spencer
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf