Re: Alternate entry document model (was: Re: IETF processes (wasRe:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]