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

[Robert Raszuk <[e-mail]>]

Marco,

Just to be clear: I am also OK with free form text with the few well known
and easy to machine parse keywords (in it). Of course provided that we
either forget about new length field in subcode 2 which would update 4271
or we do it in new subcode all together.

Thx,
R.

On Sat, Nov 19, 2016 at 3:27 PM, Marco Marzetti <[e-mail]> wrote:

> Robert,
>
> Just to be clear: i am supporting free text as i don't think that we
> should enforce any kind of formatting for any reason.
>
> Regards
>
> On Sat, Nov 19, 2016 at 3:07 PM, Robert Raszuk <[e-mail]> wrote:
> > Marco,
> >
> > Yes indeed. As said it would be completely optional.
> >
> > Job,
> >
> > Free form is so old fashioned that it really does not even sound
> reasonable.
> > Why do you want everything to be "figured out" outside of IDR ? Why for
> > everything we recently propose there must be 5 documents to read all in
> > different forums/groups to use it ? Do you prefer to hard encode TLVs to
> > make the proposal parsable ?
> >
> > Please remember you are extending BGP as the protocol used by many who do
> > not even know what IDR or GROW is. Not everyone who uses BGP has time for
> > IETF or NANOG or RIPE.
> >
> > Cheers,
> > R.
> >
> >
> >
> > On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti <[e-mail]>
> wrote:
> >>
> >> 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 <[e-mail]> 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 <[e-mail]> 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
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/idr
> >> >
> >> > _______________________________________________
> >> > GROW mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> >> --
> >> Marco
> >>
> >> _______________________________________________
> >> GROW mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> >
>
>
>
> --
> Marco
>