On Jan 3, 2013, at 2:15 PM, Jeff Wheeler <j...@inconcepts.biz> wrote:
>>> However bad or difficult to clean up, what if that's not as bad as the >>> alternative ? >> >> Clearly, the treat-as-withdraw alternative is better. You're not leaving >> bogus state in the rest of the network. > > Does this mean you support treat-as-withdraw, even though you dislike > its high complexity? My read of your postings today is that you > dislike the whole error-handling idea. Jeff, I support the general concept of improved error handling and softer failures when possible. As I've said before, errors can be reasonably classified into two groups: syntactic and semantic. A syntactic error would be any inconsistency of length fields, incompatibility between a type and a length, or any other error that would introduce any doubt about the parsing of the message. Once this type of error has occurred, then the remainder of the data stream is wholly in doubt. A session reset seems like the only (conservative) way of handling this, as it's unclear that further data would be accurate. I'm very open to a discussion of alternatives to session flap for these cases. Should we require manual intervention before session restart? This would seem reasonable. Semantic errors would be consistency violations within the contents of the message. In these cases, treat-as-withdraw seems reasonable. Tony _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
