Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02

Warren Kumari <warren@kumari.net> Wed, 26 December 2018 16:11 UTC

Return-Path: <warren@kumari.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB67130E39 for <sidrops@ietfa.amsl.com>; Wed, 26 Dec 2018 08:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 ROZV0DpGumhM for <sidrops@ietfa.amsl.com>; Wed, 26 Dec 2018 08:11:44 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8E1130E04 for <sidrops@ietf.org>; Wed, 26 Dec 2018 08:11:43 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id x10so15993734wrs.8 for <sidrops@ietf.org>; Wed, 26 Dec 2018 08:11:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YKVf69+bv3XPhUD+qGoUnRQ4vwojsj5mlc+lZRkur7A=; b=lFiav7VdfR1FAsdY6C2FauERrIOrvQ/ndYxZn2X9yhMnV+FXF0jk8iptECVsHLTJFq qNmdOmcVSghTwikTel9ftfAn3hJgrvfx7NTww00kexqi8a/icin0tAOmk+AhyT/7MbSp RmtSXtcANIDAgMFsyavGj6bzCIt2rLomB0r7vE/CS7p7IJeVbyc5xQCk1kGtmPtvILiG jlysKxsaYYi0SphSNi3MhIubWYe7+wnEzdNRwj1hGiO93lvXFVLrTRTm7xljDh1BQciL ZZHTy1RCNI9j2D1UboVXnWqz22Wr2HD6RmWaqXLuK2eI/F8MDb0hbmRZUzal4fZ0hiJ6 4ejA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YKVf69+bv3XPhUD+qGoUnRQ4vwojsj5mlc+lZRkur7A=; b=nFdyp2FQ2+LPyo/uKlY2LeQrBg8K27cSX/AzqxzJeywZT+FDxEFn2TUI7yHmDxO0tK fR80OziWWAA1c74jiG7f/JIQ/JKEmF3Mjr1vlTM1p1LwrU8DT/55JvBgzfgUeorwZeSg Yh2hpLG9yIvwnik+qnfG0MPNrgtNflEp08hCl/zC4BHeKVg1/hO8JZVeVKe3pnvm1ijU B/B9lZrrH0EtKg7/7WriIBLZEJz4aANItNwwdxfeqekinFCdWcSgHfGAl8yjvi+mYOYw m9zBh28u8BTK5pFqclVrMp2NXGliG7m4OXy3M93+atyEzqeDfWds5d9yKhDqaGIuQOT7 uxOA==
X-Gm-Message-State: AJcUukdAvrqgztLWhI8MM+DMtslbAZMUFQRT2jRUGTZd5YI6w2LxDNlu kBKVHtN1dluYSLN/P5ElOz/EBrZo3XeBNVAsQJPgKVoXL+atcw==
X-Google-Smtp-Source: ALg8bN4TBcJelFq7DHeOAaT0tPCguHbmCwu3F2ePfICmIcGI8+2Hqz9jjqy8oqSyL8SiKh7XY0Z0W97pXbxRm3PLga4=
X-Received: by 2002:adf:fa90:: with SMTP id h16mr20215238wrr.326.1545840701949; Wed, 26 Dec 2018 08:11:41 -0800 (PST)
MIME-Version: 1.0
References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> <m28t0cgyay.wl-randy@psg.com> <AF37EC12-1CA0-40B2-9224-698AF44B6286@sobco.com>
In-Reply-To: <AF37EC12-1CA0-40B2-9224-698AF44B6286@sobco.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 26 Dec 2018 11:11:05 -0500
Message-ID: <CAHw9_i+hbRwUjccD3-Q7-fzgNsb5HZpv64YUhmiwd_cwKGCYRA@mail.gmail.com>
To: Scott Bradner <sob@sobco.com>
Cc: Randy Bush <randy@psg.com>, ops-dir <ops-dir@ietf.org>, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Discuss <ietf@ietf.org>, Sandra Murphy <sandy@tislabs.com>, Alvaro Retana <aretana.ietf@gmail.com>, sidr@ietf.org, SIDROps Chairs <sidrops-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eb5e30057def15d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3oTqNMmdIuf6xT3I2AJL0ihagmI>
X-Mailman-Approved-At: Wed, 26 Dec 2018 08:27:21 -0800
Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Dec 2018 16:11:48 -0000

[ + Sandy, Alvaro ]

On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner <sob@sobco.com> wrote:

> that use of a MUST is commendable but its not exactly an interoperability
> issue
>
> to me “must” works in this case (and the other cases in this document)
>
> but, that said, 2119 has been misused for kinda a long time so its not a
> new sin
>
>
This document has a long history -- it was originally a product of the SIDR
Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to
SIDROPS recently, when SIDR closed down (
https://datatracker.ietf.org/wg/sidr/about/).

The document was originally a BCP (
https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was
changed to Standards Track in -10 (
https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt).


I have gone back through the agenda and minutes for IETF 92 (
https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 (
https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 (
https://datatracker.ietf.org/doc/agenda-94-sidr/).
I also went back and watched the video recordings from IETF 94:
https://youtu.be/fElkBi4UMEA?t=2397 and wasn't able to find any discussion
of why the change was made, but I *was* able to find some changes made
between -09 and -10 which seem to be the outcome of those discussions.

Authors / SIDROPS [0] & SIDR / chairs -  can y'all remember why the track
change was made?

Whatever the case, the IETF LC was done as Standards Track (a higher
level), and so it could always be "downgraded" to BCP / informational
during IESG Eval.
I personally think it "feels" like BCP, but I don't have full history /
inherited the document and don't want to be arbitrarily making changes.


W
[0]: SIDROPS and SIDR participant overlap is almost 100%.




> Scott
>
> > On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
> >
> > mornin’ scott,
> >
> >> it is hard to see why it should be standards track or why it should
> >> be using RFC 2119 type terminology.
> >
> > these are two separate issues.
> >
> > alvaro and the chairs can adjudicate what flavor of ice cream it should
> > be.  it my memory says it was a wg decision.  i really do not care.
> >
> > as to 2119 language, i kinda feel it should remain.  it is used
> > sparingly. but is crucial when used.  e.g.
> >
> >      all private keys MUST be protected when at rest in a secure
> >      fashion.
> >
> > i suspect we would want to keep that strongly prescriptive; but it is
> > not a hill on which i am interested in dying.
> >
> > randy
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf