Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

Robert,

So you're suggesting to include recommendation for the formatting?
That could help (as long as it's not mandatory).

Regards

On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae <neil@domino.org> wrote:
> I personally think this is a really bad idea but understand why some might want this - and we've had similar drafts in the past- in my view  we shouldn't be moving more towards more human related randomness in system level messages - have a set of status numbers or something that can be predictable but randomly "we took the peer down whilst we went to McDonald's" as opposed to CEASE reason 666 - we depeered or reason 999 we have a problem call us would be a much better approach. We can't keep running networks like we did 20 years ago!
>
> Thanks
> Neil
> Sent from my iPhone
>
>> On 16 Nov 2016, at 13:47, Peter Hessler <phessler@theapt.org> wrote:
>>
>> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
>> :I hope to capture in the draft that an implementation can choose which
>> :characters of the Shutdown Communication they represent in the syslog or
>> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
>> :all newline/newpage/newfeed/newparagraph style chars and make sure that
>> :the Communication is represented on a single line. I don't have the
>> :proper words for the draft to express that (yet).
>>
>> I've been thinking about wording for protecting the receiving system
>> from possible bad input.  I'm not worried about (valid) UTF-8 display
>> chars, nor about whitespace things.  I am worried about Little Bobby
>> Tables, though.
>>
>> We also have to consider that this will be displayed possibly in a Unix
>> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
>> chars have different meanings there.
>>
>> I'm not quite happy with the wording, but I would like something along
>> these lines added.  Possibly in the Security section, or at the end of
>> Section #2.
>>
>> ====
>> Receiving systems SHOULD filter the message for the intended output
>> environment and MAY change octets or sequences of octets for their
>> local environment.
>> As the message may be displayed on a command line, stored
>> in a syslog server, in an SQL database, or even a Web Server different
>> outputs MAY happen.
>> Sending systems MUST NOT depend on changes to their
>> sequences not happening.
>> ====
>>
>> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
>> escapes, Javascript/HTML, etc)
>>
>>
>> --
>> Taxes, n.:
>>    Of life's two certainties, the only one for which you can get
>>    an extension.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

-- 
Marco