Robert, This is a wonderful easy to use solution to send informational messages to your neighbor for a very specific case (sesssion shutdown) It is so easy that i wonder why we're discussing for so lo long.
Changing operational patterns or having well-formatted messages is out of the scope and don't relate to the draft. What i mean is you can't say the proposal is not good just because stupid people do stupid things in other circumstances (like sending maintenance alerts) Regards On Sat, Nov 19, 2016 at 4:10 PM, Robert Raszuk <[email protected]> wrote: > > Leave alone that this all makes sense to be sent well before the planned > admin shutdown so the other side is first aware of it and can manually or > automatically take users off that peering. > > But looks like we are light years away from such basic thing here .... > > On Sat, Nov 19, 2016 at 3:59 PM, Neil J. McRae <[email protected]> wrote: >> >> We shouldn't be encouraging folks to build networks that for routine >> events we then require more manual intervention when it's unwarranted. >> >> Why does it need to be free format? >> >> How many reasons or signals does one need to send in a message like this? >> Just thinking whilst I wait for the till to be rebooted in WHSmiths - I can >> think of 3 different cease reasons (and 1 of them is a form of the other). >> De-peer; maintenance; problem call/contact us - what else ? Enough to >> trigger info is in the existing config to trigger you to the right >> information on peeringdb or other local database. >> >> Cheers, >> Neil >> >> Sent from my iPhone >> >> > On 19 Nov 2016, at 14:48, Nick Hilliard <[email protected]> wrote: >> > >> > Robert Raszuk wrote: >> >> 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). >> > >> > the field should either be fully structured or free-form, and the >> > explicit intent of this draft is free form, utf8. Having a half-way >> > house is in nobody's interest because the discussion will then rat-hole >> > on defining a new ad-hoc quasi-language, and the draft - if it ever gets >> > turned into running code - will end up being a protocol soup which >> > no-one will find satisying. >> > >> > If you feel it should be fully structured, then please feel free to >> > submit an alternative draft to that effect. >> > >> > Nick > > -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
