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

Christopher Morrow <morrowc.lists@gmail.com> Wed, 26 December 2018 16:29 UTC

Return-Path: <christopher.morrow@gmail.com>
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 6CA65131012; Wed, 26 Dec 2018 08:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 jWllux0lU-1p; Wed, 26 Dec 2018 08:29:41 -0800 (PST)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 8D99B130E06; Wed, 26 Dec 2018 08:29:41 -0800 (PST)
Received: by mail-it1-x12d.google.com with SMTP id h65so20715007ith.3; Wed, 26 Dec 2018 08:29:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FrhKyEbKNZyaQ7Y7w0ZEiIiKhWWqI5D0dZSGpJmiB0Q=; b=QxQzUQeQ9G1kChZYHmowdVegl64Yf0/KqhTxxiGw1p4mFgY267vrf5IY0h08m4RUTn Z5M8EpV65YrneDALiIdIVEQ+Py0PBJRl0IddrhiykWTPhP3Qw1oxUXLlgbtA2LUIfEcj CmQBBKgK6NQLSTk3DACMwblAcb/Upm6kELwxKlPJGdUpZF8lDwNBkczaJ3Z61gmT6Q4T QKvyaRyxQcpZm7Q+BpwfEsN3AeNxKx9LeWEE8Jrrv1RVH3ZCSAVLYOra0JJ5X1pWEx91 rTn1kCcw8AlVYztlUhnYSkOnaocziI8VrOFjgzMgpYj+fiSYlMNzk0Nr0fPVSHNqJ9SO gUxg==
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=FrhKyEbKNZyaQ7Y7w0ZEiIiKhWWqI5D0dZSGpJmiB0Q=; b=qplmmfpQt7O/mpXz2VuA8kLr40H7tPCJam83JkRT7kHSSrSEApAVAsaUCW/9TNaAwO 1dClWc/oSi/DhQaBRSvIlzq6Fhzyy3F0bnwDvhy9kyxCjyzKGWWWCYscXwjbesEzuThv MuxepztJKab3w3biGcbsOn+DL5qD+q2/3AfkrhfTYQ70Vsb8/iRp9molTeB8EXyO4BPw sSpsRFg0eZ9DTE1Om4oqbL2d79hc4KZcX4NMuqB5FGN7XTaE4arC4XFVSdLQ7JKaGWbC XQxTEvTdeX9q9Luy1TaIEe2vzgEZJQedIWD7AjLFjZBTGYDKCwiZSQhhpkk0UQnGghpP mjvw==
X-Gm-Message-State: AA+aEWZbJBZvFXlo87RAVumz0rdQg0h40GmPR9PjnWmE6RxqN6lBxhVV 4lPwg4Z/oGKP5EKo4wRTe1esofB8iJxI/j8ey0nHcA==
X-Google-Smtp-Source: AFSGD/Vt1h8JaUAUHt2qy/7Q33vyZIAvWkuUsmVk0oSlwtW2DJ0LsTe5CLSjJ4OH+hFC2J8qTfNLhL8AU1v4hswCCYQ=
X-Received: by 2002:a02:6019:: with SMTP id i25mr13875083jac.137.1545841780581; Wed, 26 Dec 2018 08:29:40 -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>
In-Reply-To: <CAHw9_i+hbRwUjccD3-Q7-fzgNsb5HZpv64YUhmiwd_cwKGCYRA@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 26 Dec 2018 11:29:29 -0500
Message-ID: <CAL9jLaa3T72oJZCm0pHpjjkf3AXY2Fz5sk+7ZFC=_BzGMTYEbg@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Scott Bradner <sob@sobco.com>, SIDROps Chairs <sidrops-chairs@ietf.org>, ops-dir <ops-dir@ietf.org>, IETF Discuss <ietf@ietf.org>, sidrops@ietf.org, sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000035ec01057def5677"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/m9mxgoE3gEYB7NCsvliu_w7hBXE>
Subject: Re: [Sidrops] [sidr] 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:29:44 -0000

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
>