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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
begin:vcard
fn:Todd Glassey
n:Glassey;Todd
email;internet:TGlassey@xxxxxxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf