Subject: RE: Doubletree RST 'BOF' meeting note

From: Bernie Volz <[email-masked]>
Date: Thu, 3 Aug 2000 10:45:40 -0400

It depends how one defines transient.

A RST in response to a SYN could well be considered transient because either
there is no listener on the destination port or perhaps there is but the
backlog is full (some stacks drop the SYN in this case rather than sending
an RST, others send (or did send) an RST). That listener may appear at any
time in the future.

I'm also not sure what permanent means in this context either. A RST is
always "permanent" for that connection. And, predicting whether the same
condition will occur in the future is rather difficult.

-----Original Message-----
From: Craig Partridge [mailto:[email-masked]]
Sent: Thursday, August 03, 2000 10:32 AM
To: Ian Heavens
Cc: Craig Partridge; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Doubletree RST 'BOF' meeting note

In message <[email-masked]>, Ian Heavens writes:

>Sounds a good approach...the only thing is I'm not sure how many
>severity levels one could define for a RST....  

Well the existing scheme envisions two types: transient and permanent
errors and then a bunch of subcodes.

Now I'm not sure there's any transient condition that provokes an RST,
but perhaps...

Craig

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 03 Aug 2000 10:33:24 -0700

It might be better to break it into network-vs-application errors, where 
"Network" is the transport layer and below, while "Application" is the
application layer and higher.

For example, network class errors would be "out-of-sequence SYN" or "no
listener" or "timeout" or whatever. Conversely, application class errors
could be "disk space unavailable" or "unauthorized host" or the like.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/