Ben:
>>>>>> 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.
I do not think the real message here is how to write security considerations regarding transient identifiers.
I also agree with EKR's position.
Russ
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
