Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08
Benjamin Kaduk <kaduk@mit.edu> Tue, 31 December 2019 02:37 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3112002E; Mon, 30 Dec 2019 18:37:14 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 GwUCuJIrzpHB; Mon, 30 Dec 2019 18:37:13 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E168312008F; Mon, 30 Dec 2019 18:37:12 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBV2b8lA025151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Dec 2019 21:37:10 -0500
Date: Mon, 30 Dec 2019 18:37:07 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Randy Bush <randy@psg.com>
Cc: last-call@ietf.org, secdir@ietf.org
Message-ID: <20191231023707.GR35479@kduck.mit.edu>
References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <CAAyEnSOx-MH0Ua6o9j-zMKwLktvYGXzBUw1ZkuO49BWD+1yxRQ@mail.gmail.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> <F73568E4-2AD0-4C9F-AD03-EBA831D569AB@nohats.ca> <CACsn0c=KkDzwXYMzWW88_OcX8GpJ92e3yrXeWR=v0SdQRYzxFQ@mail.gmail.com> <m2sgl4i92o.wl-randy@psg.com> <20191229033101.GE35479@kduck.mit.edu> <m2lfqvitcz.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2lfqvitcz.wl-randy@psg.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bN706gg3e21BHGNTDcRxPTqMKzY>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2019 02:37:15 -0000
On Sat, Dec 28, 2019 at 09:38:36PM -0800, Randy Bush wrote: > > >> these half-assed "the market demands something" panaceas provide > >> false solutions we have to clean up later; emphasis on that last > >> clause. rwhois anyone? the highway is littered with whitepages > >> roadkill. today there is a massive problem with authority in the IRR > >> (which some RIRs throw in with whois); and retrofitting a solution is > >> now years in blah blah blah. > >> > >> no one is asking for the perfect over the good. but it is our > >> obligation, before putting the ietf stamp on it, for it to be as good > >> as we can reasonably get for the time. this proposal is not, as has > >> been enumerated time and again as it has been shoved through the > >> process over objections. > >> > >> imiho, tero's review stands. > > > > I do note the second 'i', but I have to say that to me, "shoved > > through the process over objections" sounds like a pretty serious > > process violation that ought to be remedied. > > that may be what you heard, but that is not what i said, or at least > meant to say. > > > I'd like to better understand what you see as the process violation > > (if any) here, so that I can try to remedy it. > > if i had a process objection, i would say it quite clearly. i have a > reputation to maintain :) Okay, thanks for clarifying. > technical objections have been raised all along the path of this > document. many of them ignored and repeated, many covered in tero's > most excellent secdir review. but the draft marched on. today sm > raised new issues. Well, I do remember some objections raised when this draft was still at SAAG/SECDISPATCH, but I also assigned it a document shepherd and refused to touch it myself until the shepherd had worked with the authors to address those comments to the extent that we understood them. (That was mostly comments from Paul Wouters, if I remember correctly; there may have been others.) So I'm not sure which objections you think have been ignored while "the draft marched on" -- my intent was to get the initial objections addressed (and yes, sometimes that was by attempting to make them "out of scope", which does not always work well), and the next step in the process is AD review followed by IETF LC. Having more issues raised during a single IETF LC isn't surprising (though it is perhaps unusual, with many drafts getting no LC comments other than directorate reviews, which is probably a different thread), so "ignored and repeated" and "but the draft marched on" feel a bit like hyperbole to me. But maybe I messed up and we missed something; I'm sure you won't be shy about telling me if that's the case. > but you're a security guy, have the badge and all, even if your name is > not steve. read the darn thing and tell us what you think of it as > reasonable and prudent secops practice. I mean, I read it when I did the AD evaluation, and what I recall thinking is that it proposes a mechanism that's useful in some cases but potentially harmful in other cases, so the trick would be to get the writing to be clear about the risks. Having it already being in use tends to tilt the scales towards "document the thing so that the semantics are well-defined", though that does not absolve us of the duty to accurately document the drawbacks and risks. It's a mixed bag, and you'll need to think before relying on the information in the file, but that's hardly unique to this mechanism. -Ben
- [secdir] Secdir last call review of draft-foudil-… Tero Kivinen via Datatracker
- Re: [secdir] Secdir last call review of draft-fou… Yakov Shafranovich
- Re: [secdir] Secdir last call review of draft-fou… Tero Kivinen
- Re: [secdir] [Last-Call] Secdir last call review … Paul Wouters
- Re: [secdir] Secdir last call review of draft-fou… Edwin Foudil
- Re: [secdir] [Last-Call] Secdir last call review … Salz, Rich
- Re: [secdir] [Last-Call] Secdir last call review … Paul Wouters
- Re: [secdir] [Last-Call] Secdir last call review … Watson Ladd
- Re: [secdir] [Last-Call] Secdir last call review … Randy Bush
- Re: [secdir] [Last-Call] Secdir last call review … Salz, Rich
- Re: [secdir] [Last-Call] Secdir last call review … Benjamin Kaduk
- Re: [secdir] [Last-Call] Secdir last call review … Randy Bush
- Re: [secdir] [Last-Call] Secdir last call review … Benjamin Kaduk
- Re: [secdir] [Last-Call] Secdir last call review … Randy Bush
- Re: [secdir] [Last-Call] Secdir last call review … Yakov Shafranovich
- Re: [secdir] [Last-Call] Secdir last call review … Rob Sayre
- Re: [secdir] [Last-Call] Secdir last call review … Yakov Shafranovich
- Re: [secdir] [Last-Call] Secdir last call review … Rob Sayre
- Re: [secdir] Secdir last call review of draft-fou… Yakov Shafranovich
- Re: [secdir] [Last-Call] Secdir last call review … Salz, Rich
- Re: [secdir] [Last-Call] Secdir last call review … Paul Wouters
- Re: [secdir] [Last-Call] Secdir last call review … Rob Sayre