[188578] in North American Network Operators' Group
Re: Best practices for sending network maintenance notifications
daemon@ATHENA.MIT.EDU (joel jaeggli)
Wed Apr 6 16:02:50 2016
X-Original-To: nanog@nanog.org
To: "Dan Mahoney, System Admin" <danm@prime.gushi.org>, nanog@nanog.org
From: joel jaeggli <joelja@bogus.com>
Date: Wed, 6 Apr 2016 17:02:41 -0300
In-Reply-To: <alpine.BSF.2.00.1604061144160.78400@prime.gushi.org>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UjJt5dhRCu2LwDXJa5GVKnWciMex1TIlg
From: joel jaeggli <joelja@bogus.com>
To: "Dan Mahoney, System Admin" <danm@prime.gushi.org>, nanog@nanog.org
Message-ID: <a4afac03-9fc0-f4ff-0ebb-bb466bce1822@bogus.com>
Subject: Re: Best practices for sending network maintenance notifications
References: <alpine.BSF.2.00.1604061144160.78400@prime.gushi.org>
In-Reply-To: <alpine.BSF.2.00.1604061144160.78400@prime.gushi.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 4/6/16 3:56 PM, Dan Mahoney, System Admin wrote:
> All,
>=20
> We recently, at $dayjob, had one of our peers (at Symantec) send out a=
> network maint notification, putting 70 addresses in the "To:" field,
> rather than using BCC or the exchange's mailing list.
>=20
> Naturally, when you mail 30 addresses, of the forms peering@ and noc@
> various organizations, you're likely to hit at least a few
> autoresponders and ticket systems...
>=20
> And at least one or two of those autoresponders are of course brainded
> and configured to reply-all. (In this case, Verizon's ServiceNow setup=
> was such a stupid responder). And that made things fun in our own
> ticket system, as our RT setup happily created a bunch of tickets.
>=20
> My question for the group -- does anyone know if there's a "best
> practices" for sending maint notifications like this? An RFC sort of
> thing?
In general I'd push for a little automation for the sending of
notifications as reducing the likelihood of mishap.
Targeting bcc is nice, but so does simply generating a message for each
peer precludes this. we store contact information which bgp neighbor
parameters in our config generation.
> While it would define a social protocol, rather than a truly technical
> one, if there's not such a document, it seems like it could useful. An=
d
> once such a thing exists, exchanges could of course helpfully point
> their members AT it (for both their humans, and ticket systems, to foll=
ow).
>=20
> -Dan
>=20
--UjJt5dhRCu2LwDXJa5GVKnWciMex1TIlg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlcFa2IACgkQ8AA1q7Z/VrLsFwCeNLOMqIWy8fdY2RQ0Cz0F7NfC
TvIAn0eZy21T4/GE0wTLWjbYGgHkHE/N
=P+tn
-----END PGP SIGNATURE-----
--UjJt5dhRCu2LwDXJa5GVKnWciMex1TIlg--
