From nobody Wed Dec 26 08:11:49 2018 Return-Path: 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 BC788130E04 for ; 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=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 DlaIgj-5rc11 for ; Wed, 26 Dec 2018 08:11:44 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 EB951130E09 for ; Wed, 26 Dec 2018 08:11:43 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id v13so16015657wrw.5 for ; 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=FTvz+IvqWH/ScoA3UUUdc4L3l5vJKgiRhm5shHHQDmqsDrXbSXA6VHjH4NtU0+uJgw i5Mi4eapkIPNC27wVIAAaugCrvRrtL9qhAkQDimbBAWm0M6mKb+ev+5ECXkJ6TbOIaT8 D5cQvwWJjB3NnHVIpynX6WZnr74iiMkPmsujzMV2947JsNGd07M8DsFSkueoKpx1sHU7 u5A34wJU0ZTfvxl4iixd7SoS50J/6o9NSF3RrFsTALpeMJeTTZ3O1a/RyfuamFairv7a QULzagOO+QgjkmJ4eAOBS5qZrSKxUaMMFBekmjwSsp3G3uJygWK2PAW1Nw7bIJK4oUgZ yB1g== X-Gm-Message-State: AJcUukfuG79mxCtjp6B7AXZu6czbGF50tZaXjpW433wBn1ihNLJrogtU b8FGT7rcO1rt6pPBNYJVFGr37DinLsTUvyLJ9gLGEA== 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> In-Reply-To: From: Warren Kumari Date: Wed, 26 Dec 2018 11:11:05 -0500 Message-ID: To: Scott Bradner Cc: Randy Bush , ops-dir , draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Discuss , Sandra Murphy , Alvaro Retana , sidr@ietf.org, SIDROps Chairs Content-Type: multipart/alternative; boundary="000000000000eb5e30057def15d8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 16:11:48 -0000 --000000000000eb5e30057def15d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ + Sandy, Alvaro ] On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > that use of a MUST is commendable but its not exactly an interoperability > issue > > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in t= his 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=3D2397 and wasn't able to find any discussio= n 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 wrote: > > > > mornin=E2=80=99 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 > > --=20 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 --000000000000eb5e30057def15d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[= =C2=A0+ 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 exactl= y an interoperability issue

to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in thi= s document)

but, that said, 2119 has been misused for kinda a long time so its not a ne= w sin


This document has a long history -- it was = originally a product of the SIDR Working Group (as draft-ietf-sidr-rtr-keyi= ng), 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://d= atatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was change= d to Standards Track in -10 (https://www.ietf.org/archive/id/draft-ietf-= sidr-rtr-keying-10.txt).


I have gone back through the agend= a and minutes for IETF 92 (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93= (https://data= tracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 (https://datatracker.ietf.org/doc/a= genda-94-sidr/).=C2=A0
I also went back and watched the video recording= s from IETF 94:=C2=A0http= s://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any discu= ssion of why the change was made, but I *was* able to find some changes mad= e between -09 and -10 which seem to be the outcome of those discussions.=C2= =A0

Authors / SIDROPS [0] & SIDR / chairs -=C2=A0 can y'all re= member why the track change was made?=C2=A0

=
Whate= ver 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, b= ut I don't have full history / inherited the document and don't wan= t to be arbitrarily making changes.


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


=C2=A0
Scott

> On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
>
> mornin=E2=80=99 scott,
>
>> it is hard to see why it should be standards track or why it shoul= d
>> be using RFC 2119 type terminology.
>
> these are two separate issues.=C2=A0
>
> alvaro and the chairs can adjudicate what flavor of ice cream it shoul= d
> be.=C2=A0 it my memory says it was a wg decision.=C2=A0 i really do no= t care.
>
> as to 2119 language, i kinda feel it should remain.=C2=A0 it is used > sparingly. but is crucial when used.=C2=A0 e.g.
>
>=C2=A0 =C2=A0 =C2=A0 all private keys MUST be protected when at rest in= a secure
>=C2=A0 =C2=A0 =C2=A0 fashion.
>
> i suspect we would want to keep that strongly prescriptive; but it is<= br> > 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 ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000eb5e30057def15d8-- From nobody Wed Dec 26 08:29:52 2018 Return-Path: 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 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> In-Reply-To: From: Christopher Morrow Date: Wed, 26 Dec 2018 11:29:29 -0500 Message-ID: To: Warren Kumari Cc: Scott Bradner , SIDROps Chairs , ops-dir , IETF Discuss , sidrops@ietf.org, sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000035ec01057def5677" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 16:29:44 -0000 --00000000000035ec01057def5677 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > [ + Sandy, Alvaro ] > > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > >> that use of a MUST is commendable but its not exactly an interoperabilit= y >> issue >> >> to me =E2=80=9Cmust=E2=80=9D 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 t= o > 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=3D2397 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 wrote: >> > >> > mornin=E2=80=99 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 shoul= d >> > 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 > --00000000000035ec01057def5677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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:
[=C2=A0+ 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 in= teroperability issue

to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in thi= s document)

but, that said, 2119 has been misused for kinda a long time so its not a ne= w sin


This document has a long history -- it was = originally a product of the SIDR Working Group (as draft-ietf-sidr-rtr-keyi= ng), 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.t= xt).


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 (ht= tps://datatracker.ietf.org/doc/agenda-94-sidr/).=C2=A0
I also went bac= k and watched the video recordings from IETF 94:=C2=A0https://youtu.be/fElkBi4UMEA= ?t=3D2397 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 wh= ich seem to be the outcome of those discussions.=C2=A0

Authors / SIDRO= PS [0] & SIDR / chairs -=C2=A0 can y'all remember why the track cha= nge was made?=C2=A0

Whatever the case, the IETF L= C was done as Standards Track (a higher level), and so it could always be &= quot;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 maki= ng changes.


W
[0]: SIDROPS and SID= R participant overlap is almost 100%.


= =C2=A0
Scott

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



--
I don't think th= e 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 pa= nts.
=C2=A0 =C2=A0---maf
=
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--00000000000035ec01057def5677--