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