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

From: Randy Bush <[email-masked]>
Date: Wed, 26 Dec 2018 09:25:25 -0500

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Dec 2018 10:12:39 -0500

> that use of a MUST is commendable but its not exactly an
> interoperability issue

is

    The operator MUST ensure that the installed CA certificate is valid.

an interop issue?

this is an opsec doc; not protocol on the wire.  hence its MUSTs are
security and operational prudence.

but enough already.

randy

---

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Dec 2018 05:09:18 -0800

Reviewer: Scott Bradner
Review result: Serious Issues

This is an OPSDIR review of Router Keying for BGPsec
(draft-ietf-sidrops-rtr-keying).

This seems like a useful document but it is hard to see why it should be
standards track or why it should be using RFC 2119 type terminology.

Standards track should be reserved for technology specifications where
interoperability is an issue.  I do not see interoperability issues being
addressed in this document since it focuses on how to create keys rather than
the features of keys that might be important for interoperability.  (as an
aside, if this document were adopted on the standards track how would it ever
demonstrate interoperability to progress?) This seems much more of an
informational document to me and not even a BCP since the practices it
describes do not meet what I consider to be BCP material (see RFC 2026 section
5)

The same issue arises with the use of RFC 2119 type terminology – RFC 2119
terminology is only to be used where interoperability is an issue – see RF 2119
section 6:

6. Guidance in the use of these Imperatives
   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

I did not discover any issues worth mentioning with the document if it is
viewed as operational guidance.

Scott

---

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Dec 2018 09:51:06 -0500

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

Scott

> On Dec 26, 2018, at 9:25 AM, Randy Bush <[email-masked]> wrote:
> 
> mornin’ scott,
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Dec 2018 11:11:05 -0500

[ + Sandy, Alvaro ]

> but, that said, 2119 has been misused for kinda a long time so its not a
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%.

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

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Dec 2018 11:29:29 -0500

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 <[email-masked]> wrote:

> 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
> 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.
>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>