It's a wonderfully useless solution when it could be a wonderfully useful solution - it's just more operational noise that we already have and we will start filtering like everything else.
Neil. > On 19 Nov 2016, at 16:58, Marco Marzetti <[email protected]> wrote: > > 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
