[ + Sandy, Alvaro ]
On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner <sob@xxxxxxxxx> 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@xxxxxxx> 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
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