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

[Marco Marzetti <[e-mail]>]

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