Re: another document categorization suggestion

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf