Hi SM, I don't quite understand the procedure you described: S Moonesamy wrote:
Now that I have more information about the procedure to be followed by the Working Group, I'll elaborate on it. A pre-evaluation Internet-Draft is submitted and the WG is asked to comment on it. There is a WGLC for the pre-evaluation I-D. I write a deployment report for the document being revised. If there is WG consensus about the pre-evaluation I-D, the WG Chairs request an IESG Evaluation of it. The way the evaluation is handled ("Management Item") is an internal IESG matter. The IESG issues a statement about the specification being evaluated. The WG decides what to do about any issues that may arise. There is another WGLC if there is an updated document. The WG submits the document for an IETF-wide Last-Call and the normal process is followed.
I'm not sure rfc1652bis can serve as a full-featured prototype of what we are going to do. In that case, the pre-evaluation I-D only contains added/ removed references. In the general case, the charter expressly allows changes that (a) contribute in a substantial and substantive way to the quality and comprehensibility of the specification, while they (b) don't change the existing protocol. 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?
Please review what Lisa said [1] about security considerations and post your comments to this mailing list.
I cannot get the point: the text you quoted and the current Section 5, Security Considerations, of RFC 1652 seem equivalent to me (up to reference changes). However, I think we may treat that the same way as boilerplate replacement, can't we?
Text you quoted Since this is an extension to SMTP, the main security concerns have to do with SMTP itself rather than this document. The WG feels the security considerations of this document will be sufficient for Full Standard status. Section 5 in RFC 1652 This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of [RFC 821].I feel particularly dumb today, as I post this stuff. My apologies for your time, but I can't reach the cherries :-(
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.