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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/idr >> > >> > _______________________________________________ >> > GROW mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/grow >> >> >> >> -- >> Marco >> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow > > -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
