Re: another document categorization suggestion
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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
<>___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: another document categorization suggestion
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: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Thursday, April 22, 2010 8:39 AM To: ietf@ietf.org Subject: Re: another document categorization suggestion On 22 Apr 2010, at 01:55, james woodyatt wrote: > 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 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: another document categorization suggestion
On 22 Apr 2010, at 01:55, james woodyatt wrote: > 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 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 smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: another document categorization suggestion
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 member of technical staff, > communications engineering > > > ___ Ietf mailing list > Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
another document categorization suggestion
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 member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
