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

Whow ... extremely well said !

The idea for phone number beats me ... who uses voice phones these days ???

Cheers,
R.

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
>