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").
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.
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.
The question of how snotty we should be about naming vendor X is left as an
exercise for the reader, of course.
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf