Jakob Heitz <[email protected]> wrote: > On Friday, January 04, 2013 4:35 PM, John Leslie <mailto:[email protected]> wrote: > >> Replay of an errant update can't help, and would likely crash its >> receiver. Don't do that! > > Sorry, that's not what I meant. > I meant a future operational message that says > "this update message caused me a problem and here is > the update message for your reference". It is a copy of > the message, not actually a replay.
Danger, Will Robinson! Actually, we could invent a message type which reflects the content of a "bad" update, but it would only be useful for logging at the sending peer for human perusal; and, to be useful to that human it would need to classify the problem and indicate what part(s) of the update have been acted upon. Under no circumstances should we do this without making its length abundantly clear -- both the length we assumed when reading it and the length of what we are returning (which need not be the same: humans get the best value out of the first few hundred bytes in most cases). In particular, if we detect 16-bytes of marker within it, we MUST NOT return that marker un-escaped. This would probably be the most helpful when we _don't_ expect to be able to continue without a NOTIFY. We would need to send this only to a peer that advertised the capability to log it; and that might include the ability to recognize it _after_ the NOTIFY if we decide that sending it before the NOTIFY is too risky... -- John Leslie <[email protected]> _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
