Re: is there a specific proposal for living ops docs?

Jared Mauch <jared@puck.nether.net> Sat, 20 July 2019 18:57 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9087212006E for <ietf@ietfa.amsl.com>; Sat, 20 Jul 2019 11:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSWb35hl7tdL for <ietf@ietfa.amsl.com>; Sat, 20 Jul 2019 11:57:05 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB05412001B for <ietf@ietf.org>; Sat, 20 Jul 2019 11:57:05 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:c8dd:839:b5a0:d98b] (unknown [IPv6:2603:3015:3606:cbe1:c8dd:839:b5a0:d98b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id D67B65401BD; Sat, 20 Jul 2019 14:57:02 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: is there a specific proposal for living ops docs?
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <m2imrwv9cn.wl-randy@psg.com>
Date: Sat, 20 Jul 2019 14:57:02 -0400
Cc: Job Snijders <job@instituut.net>, IETF Rinse Repeat <ietf@ietf.org>, Keith Moore <moore@network-heretics.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D587A2CB-144A-46BC-8A0A-C5BC7DF66C98@puck.nether.net>
References: <F2D5DCCF-4051-444B-9522-9E11F9F93005@fugue.com> <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com> <144ff436-a7a2-22f7-7b06-4d0b3bcfefac@joelhalpern.com> <20190719041456.GL33367@vurt.meerval.net> <254fc5f6-3576-a62f-b84f-a7c5d29b0055@joelhalpern.com> <a1561aa7-5f41-0e2a-1892-cfb587196ac0@gmail.com> <C3D53639-C2C0-42CE-9708-99294091E012@puck.nether.net> <a17a8648-14c8-1889-4ee3-86996ff6281e@gmail.com> <3B0C189A-D56B-430F-82FF-19DE0DC788DE@puck.nether.net> <BA80E73F53C26B9191294131@JcK-HP5.jck.com> <20190719190534.GG38674@shrubbery.net> <4f43fac6-ed7f-08ca-d5da-1e84b0a7b12b@network-heretics.com> <3a678b4a-1c9e-8a2a-ea02-ac32a07f3711@gmail.com> <CACWOCC8g_YXT9OU6NxuhFGkxuejxux_ykoKfA7i8cmZ73nWjeg@mail.gmail.com> <m2muh8valj.wl-randy@psg.com> <0FE0532C-28AF-47F6-8BED-D5C3E05216D1@puck.nether.net> <m2imrwv9cn.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/x5eFABjAWOjOibaN44nAjt3ykG0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2019 18:57:08 -0000


> On Jul 20, 2019, at 2:39 PM, Randy Bush <randy@psg.com> wrote:
> 
>>>>> That's exactly why I asked about RIPE's solution. Before proposing
>>>>> a solution, don't we want to study one that apparently works?
>>>> Works by what metric?
>>> worked for us in publishing an op doc which was eventually followed by
>>> an rfc
>> I think an example of a RFC of this sort is 2182/BCP-16.
> 
> uh, non sequitur.  the subject was ripe docs working.  2182 was never a
> ripe doc, and the ietf pub cycle was just fine for it.

I don’t think as much as you do here.  That document has aged well and is good ops advice (for DNS operators).

> but maybe folk could get the point here if (the metaphorical) you could
> point to an example op doc which is needed asap, is in good shape, and
> ietf rfc processing would cause ops issues.  a real example, might help.

As I said previously, the tools at the IETF are decent, and I can publish something before the day is out if I really think it’s necessary.  Maybe given recent events I should write up things like AS_PATH filtering plus prefix list filtering is a good thing so my ops alerting system will stop telling me of weird routing issues.  It fires all the time and periodically with something big going on (eg: recent 701 event).

- Jared