Hi Russ,
On Fri, Dec 11, 2020 at 11:52:43AM -0500, 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.
RFC 3552 is pretty sparing with normative language, with most of the key
requirements living in its Section 5 ("Writing Security Considerations
Sections"), which boil down to "you are obligated to accurately depict the
security properties of your protocol, and here are a list of specific
things that are extra-mandatory to consider". However, RFC 3552 also has a
substantial list of "Common Issues" in its Section 4 and subsections. My
question to you, is what mechanism(s) you would consider appropriate to add
to the list of "Common Issues". I think it's pretty clear that a full-on
"bis" document should be able to add to (or or remove from, I suppose) the
list, but what else? Please consider that as a separate question from
whether these issues would merit inclusion in the RFC 3552 §5 list of
mandatory-to-consider topics -- we may well need to consider that question
as well, in the course of this IETF LC, but I would prefer to hear answers
to the first question at this point.
Thanks,
Ben
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
