Hi Alessandro, At 00:02 21-10-2009, Alessandro Vesely wrote:
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.
The pre-evaluation I-D is used to communicate with the IESG and to avoid "late surprises". The WG informs the IESG about the changes it is considering. If the IESG approves of them, work continues on the document. It saves us and the IESG time if we are all on the same wavelength about what changes should be made.
I'll avoid commenting on whether we can bind the IESG as that's more about process.
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?
The comments from the IESG were about the substance and not about the security consideration section for the pre-evaluation I-D. It is about security considerations for RFC 1652bis and the other specifications this WG will work on.
The IESG had a discussion about the procedure and the WG Chairs received feedback from the AD. The various parties have a clear picture of how they would like things done. Understanding the procedure doesn't necessarily mean that the various parties agree.
If you do not understand Lisa's point, I can ask her to clarify. ADs are busy people and they may not reply immediately. If you disagree with what she said, you have to explain why it is incorrect. It's helpful if you also provide an alternative and explain why it is good. If the WG agrees to that, it then has to decide whether to put up a fight if the IESG is unconvinced.
Regards, S. Moonesamy YAM WG Secretary
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.