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

Warren Kumari <warren@kumari.net> Wed, 16 January 2019 20:15 UTC

Return-Path: <warren@kumari.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A38131131 for <sidr@ietfa.amsl.com>; Wed, 16 Jan 2019 12:15:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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=unavailable 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 wDSsgJ5rBH_t for <sidr@ietfa.amsl.com>; Wed, 16 Jan 2019 12:15:09 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 818B1130ED0 for <sidr@ietf.org>; Wed, 16 Jan 2019 12:15:08 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id v13so8464898wrw.5 for <sidr@ietf.org>; Wed, 16 Jan 2019 12:15:08 -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=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=irUvobGH9rOn+AXxosD0ppx775WHBWv3GKvd/S+nyGTHuuKrt6tf2i4Y03gxhZYAPp 2Tp3ktkHkqZnbxeiEhqTnvwrltJ2oQP5IgZvDwLPdGC+pMbeP7zqVF5Mh6inWJNgdOXu RAyBRiXnU5+kS59KLhLr4zFL4NwaoJ4gUKlvKHS7qbfrjwqhHwHe9d6Cfur8fKhh0Vxe jAeSjTzH1aMuC/1G3PPi2eoR25zR8f3dkhvZHmGzBi2BGLN/O65ikAJcQFno31J0XIr6 e7WYenmGWcml5NwxByxS4W5Er5OXSr/rcHfQ1+4o+Bs5kDaUhO++dFa7xBg4pw7WtAIH Xi5A==
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=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=a7xB2SBdy3yT+j1VXZX0phu2XfOQpE5FWHjmVgWmWxGQHjdpjaURistRT5IfCBU5bn 176O2ubiWN7Y+WFMQDyOCaU/mpjqg0mYVn3U9FxdmOCiJbZyCpT1DRLf4kivYvvUIvFE APkbBEqK3skdaL86NzgdQ4hjMPqtr0b9KKCekSMb94ZGgM9GoTeXN5HxsHaUOuqfYwS7 jokbh+FtmTMR7H3DhATU2/hnI0aqLA6CsD1y/sAMhoyBxulhioeLF5y6eguq/OkF4z8W VGP7iDDN5xmchOBCl8sdg1j5Q+tNwbnlxEoGnxSX+vQ0U/tFU8R5mIJtXM9tYckx3g/u JwVg==
X-Gm-Message-State: AJcUukfgdED7V3IXCz7SqXMW6uPNYXv1WVbL62yUObNVEjcy+3hcI9Sj yqNKcbp6QdJvgIK17uG/CqaVH0C8dSc3WpNrlVv/PA==
X-Google-Smtp-Source: ALg8bN54OJsrsgCj4s5bNJ5BXNTozwjr7DY7dipfscK5jXZYw6aQx6W99sKm4qTQG3QRsyd4hmO1Klll8nBpGm7wGTk=
X-Received: by 2002:adf:f0c5:: with SMTP id x5mr8649261wro.77.1547669706604; Wed, 16 Jan 2019 12:15:06 -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> <CAHw9_i+hbRwUjccD3-Q7-fzgNsb5HZpv64YUhmiwd_cwKGCYRA@mail.gmail.com> <CAL9jLaa3T72oJZCm0pHpjjkf3AXY2Fz5sk+7ZFC=_BzGMTYEbg@mail.gmail.com> <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com>
In-Reply-To: <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 16 Jan 2019 15:14:30 -0500
Message-ID: <CAHw9_iJSV3B1i4D5njb26CVT=3+uVkS09Mv6_n31YYb5yjtS_w@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Christopher Morrow <morrowc.lists@gmail.com>, Scott Bradner <sob@sobco.com>, SIDROps Chairs <sidrops-chairs@ietf.org>, ops-dir <ops-dir@ietf.org>, IETF Discuss <ietf@ietf.org>, SIDR Operations WG <sidrops@ietf.org>, sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001799f9057f98efd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/bPufLFQDLBzNK8hf7pk17GuA_NM>
Subject: Re: [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jan 2019 20:15:13 -0000

On Tue, Jan 15, 2019 at 11:56 PM Sean Turner <sean@sn3rd.com>; wrote:

> Apologies for just finding this now …
>
> I seem to remember a WG discussion about whether this draft should be BCP
> or ST.  We discussed BCP addressing both what the IETF wanted to be the
> best practice as well as what is the actual current practice.  Since BGPsec
> was/is new it was/is hard to say it fell in the latter bucket and there was
> at least one person who felt that the router and operator driven methods
> weren’t the way to go in the future (hence why there is s8 the "advanced
> deployment scenarios” section).  So the WG said go ST and because this
> draft has exhausted me we just changed it to ST.


Ah, awesome, I'm glad someone remembers the original reason.



> I will note that the SECDIR and RTGDIR both had this same comment it seems
> like we’re back to BCP.  I think there was another message somewhere about
> changing this to BCP so I will do that in -03 unless I hear otherwise.
>

Yes please, and thank you for solving the mystery.
W



>
> spt
>
> > On Dec 26, 2018, at 08:29, Christopher Morrow <morrowc.lists@gmail.com>;
> wrote:
> >
> > BCP seems like a fine answer here, I'm not remembering why we would have
> swapped to ST from BCP.
> >
> > On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari <warren@kumari.net>;
> wrote:
> > [ + 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
> > _______________________________________________
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>
>

-- 
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