Hi, Russ,
On 11/12/20 13:52, Russ Housley wrote:
Fernando:
On Wed, Dec 09, 2020 at 04:09:07PM -0500, Russ Housley wrote:
I have to comments.
1) I do not see this document as a BCP. Despite the inclusion of the boilerplate, there is not a single MUST in the document. I have no objection to an Informational RFC.
The assumption/expectation was that this would become part of BCP 72 along
with RFC 3552. Do you think it should be a standalone document, or can you
propose normative language that would make it more appropriate as a BCP?
I'd advise an Informational document.
FWIW, our intent is to have a BCP document that is part of (i.e., updates) BCP72. Given that flawed transient identifiers have plagued most IETF protocols we can think of, we believe the topic deserves a BCP.
I think an additional section with normative text would be needed or additional normative paragraphs after each of the problem descriptions would be needed.
Could you please elaborate?
It is not a Best Current Practice if the document does not provide MUST and SHOULD statements for implementers to follow.
The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.
This document is meant to update RFC2552/BCP72, which was published as a
BCP. I've just scanned BCP72 for all "MUSTs" and "SHOULDs", and the
document is written in exactly the same way as the one we have authored
-- provided we were to intruduce the numbered list in Section 5 with a
"MUST" or "SHOULD".
Am I missing something?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
