S Moonesamy wrote:
At any rate, a second I-D, which will become the final FS, has to be actually written. For rfc1652bis it will be straightforward, while in general it may require some work. Does that imply a second round of WGLC + LC for the second I-D?A second I-D will be written for RFC1652bis. That is the actual specification. There will be a WGLC for it (the second round you mentioned). There is a (IETF-wide) Last-Call after that.
Thanks for the clarification. Then, the pre-evaluation I-D does not bear any formal value, outside of the WG: I don't think we can bind the IESG to compulsorily approve an I-D, given that they had already approved its pre-evaluation and the changes we have carried out were just what we had anticipated in it. Of course, they can save us a good deal of time and annoyance in case they can anticipate from the pre-evaluation that they are not going to approve a specific change. However, we don't really need the pre-evaluation I-D to be formally approved in order to proceed, do we? As much as we don't, the IESG should rather consider the substance of pre-evaluations and not bother with their form.
Some of these RFCs were written before the guidelines for writing a Security Considerations section was formalized. The text I quoted covers what the IESG asked.
RFCs 3552 and 2223 talk about security considerations sections for _RFCs_. If pre-evaluation I-Ds will never become RFCs, they shouldn't need such sections. Is it possible that the IESG asked for a formal suitability just because they too --like me and possibly more-- did not have a clear picture of our procedure?
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.