On 4/22/2010 3:35 AM, Spencer Dawkins wrote:
For what it's worth, there was (Once Upon A Time) a working group called
TCPIMPL ("TCP Implementation"), that published an "don't do it like
this" RFC (http://www.ietf.org/rfc/rfc2525.txt), that didn't call out
vendor X, but DID provide traces from implementations that violated the
spec, and explained what was wrong, what RFC(s) said it was wrong, what
a trace that demonstrated the correct behavior looked like, and why
leaving it wrong was a problem ("can you spell congestive collapse? I
knew you could").
Information (positive - i.e. true or negative i.e. disinformational)
postings are already accepted. So the TCP implementation RFC should be
informational and part of the TCP design document track.
RFC's are request for comments - meaning they are solicitations for
feedback and in that context the use of an informational RFC is totally
cool.
On whether this should be an RFC itself, or linked off the RFC(s) that
defined the correct behavior - you might think that telling everybody
that a specific behavior would be sufficient, but I am aware of people
doing new (and clueless) TCP implementations several years after this
RFC came out, with behaviors that appeared in this RFC, so there may be
a timelessness about implementation errors that is worthy of an RFC,
rather than an ephemeral web page, that captures known errors.
There should be an ongoing RFC for each protocol stating the errors in
reference ports? - I think those are specific to the ports themselves
and not the protocol specification.
If those bugs show up in the reference port that was used to qualify the
Protocol for Standards Status then you need a way of revoking an IETF
Standard Status which with the current licensing isnt possible from my
vantage point.
But I think that identifying broken implementation behavior, and
establishing consensus that it's broken, would be awesome, no matter how
that consensus is recorded.
But again - if its a broken design that is specific to the quality of
work the IETF produces and how well vetted the protocol was. Bugs in
reference ports are a totally different animal and pertain to how well
that code was tested and under what test conditions.
The question of how snotty we should be about naming vendor X is left as
an exercise for the reader, of course.
You dont have to be snotty at all - you just have to come up with a
posting model for notifying the IETF of formal deficiencies in a
protocol based on x,y, and z (whatever x,y, and z are - just realize
that posters will be liable for bad information there.
This by the way is identical to an IPR warning conceptually because it
pertains to the IP the IETF is passing outwards, so it represents a list
of the technological landmines while the IPR represents the licensing
land mines per se.
Todd
Thanks,
Spencer
How about a Real World Deployment wiki page linked from each RFC,
where implementers can insert comments like "Don't do like vendor xxx
- don't always set the nonce to zero".
Hopefully vendor xxx fixes it in the next release, and changes the
page to read "Don't do like vendor xxx did prior to version 6.14 -
don't always set the nonce to zero."
Sadly, as soon as the marketing and legal departments get wind of
this, they will edit this to say "Don't always set the nonce to zero",
but that should be good enough.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
tglassey.vcf
Description: Vcard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf