Subject: another document categorization suggestion

From: james woodyatt <[email-masked]>
Date: Wed, 21 Apr 2010 17:55:39 -0700

everyone--

After just now finding the root cause of yet another stupid interoperability problem to be an interaction between a client not choosing a sufficiently unique host/session identifier and a server being overly clever about using said identifiers for purposes other than intended in the protocol specification...

WHEREAS the IETF has no document category for dealing with material that is unfit for Standards Track, that does not in any way describe Best Current Practice, provides Information of questionable utility, which is neither yet limited to Historical interest nor of merely Experimental nature...

BE IT HEREBY RESOLVED that IETF should create a new document category for Disinformation, and that RFC 2516 should immediately and with extreme prejudice be reclassified as such without further discussion.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 21 Apr 2010 19:13:00 -0700

On 04/21/2010 05:55 PM, james woodyatt wrote:
> everyone--
> 
> After just now finding the root cause of yet another stupid
> interoperability problem to be an interaction between a client not
> choosing a sufficiently unique host/session identifier and a server
> being overly clever about using said identifiers for purposes other
> than intended in the protocol specification...
> 
> WHEREAS the IETF has no document category for dealing with material
> that is unfit for Standards Track, that does not in any way describe
> Best Current Practice, provides Information of questionable utility,
> which is neither yet limited to Historical interest nor of merely
> Experimental nature...
> 
> BE IT HEREBY RESOLVED that IETF should create a new document category
> for Disinformation, and that RFC 2516 should immediately and with
> extreme prejudice be reclassified as such without further
> discussion.

I believe that we already have (dis)informational

> 
> -- james woodyatt <[email-masked]> member of technical staff,
> communications engineering
> 
> 
> _______________________________________________ Ietf mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 22 Apr 2010 06:39:15 +0100

> BE IT HEREBY RESOLVED that IETF should create a new document category for Disinformation, and that RFC 2516 should immediately and with extreme prejudice be reclassified as such without further dis…

I think what we're really looking for in cases like this is a document subset called RWD, or Real World Deployment.  This subset comprises of notes stating the necessary information that couldn't possible be included in specifications for any number of good reasons, but which assist those implementing those specifications to avoid the next incoming arrow of misfortune that results from trying to interoperate with the incredible array of brain-dead implementations using the dubious interpretations that exist, perhaps just to the benefit of the IETF, for whom these concerns are perhaps greater than those of the vendor.

As a concession to avoiding further bureaucracy, because we get enough of that as it is, and as an aid to IETF sponsorship, special offers should be made concerning vendor recognition in such documents.  The hopeful consequence of this is that the subset should be modest in size, if not purpose, and will remain so for the foreseeable future.

Cheers,
Sabahattin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Apr 2010 08:50:30 +0300

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sabahattin Gucukoglu
Sent: Thursday, April 22, 2010 8:39 AM
To: [email-masked]
Subject: Re: another document categorization suggestion

Cheers,
Sabahattin

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Apr 2010 05:35:25 -0500

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.

---

From: todd glassey <[email-masked]>
Date: Thu, 22 Apr 2010 05:45:26 -0700

On 4/22/2010 3:35 AM, Spencer Dawkins wrote:
> 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.

> 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.

> 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. 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>