Ah. Dave, you misunderestimate my stance. Thanks for pursuing it to get to that point. >> I think it's reasonable that we might get to a point in reviewing and >> adding/updating security considerations, where we think it's time to >> kick the document off. What I meant by this was to address the process BEFORE we take it to the IESG. What I've been advocating from the beginning is that we should look at the documents with the current documentation standards in mind. That means considering the Security Considerations (and perhaps, though it seems less likely, IANA Considerations. If the document has none, or what it has does not conform to current practice, we add or update it appropriately, as part of OUR process. It might be that this review leads us to a point where we think that the work required to make the Security Considerations acceptable is more than we want to do, and then we kick the document out. That decision may come because we think we can't just say "Go look there," and we can't reasonably document security concerns, adding that current and historical usage demands that this be brought to full Standard anyway. I am not suggesting that we should change any protocols to deal with new security considerations. And if the IESG comes back to us and says, "No, we can't go ahead with this because of [X]," we likely WILL say, "OK, put this one on the other pile," and move on (though I do think that decision would depend upon what, specifically, the issue is). The charter tells us that the default answer would be to set it aside. I definitely agree with the consensus when we chartered YAM, that "battles" with the IESG over each document are not appropriate to what we want to do. Now, all that said: consensus when we wrote the charter was NOT to add or update things like Security Considerations. I bring it back up now because we have some early feedback from the IESG, and that's new information. It may be that the WG's consensus is still against what I say above, and that's fine. I just think we should look at it again, in light of Lisa's feedback (and I'm sure Lisa is not alone in what she asks). Barry
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.