On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:
Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus.However, if it makes the IAB more comfortable for the IAB chair to do theconsensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process.
Sam,the underlying point of my question is that the streams are independent and that the IETF (stream) has no say about the other streams. IETF consensus or not. I am not even sure the IAB has a roll in calling the consensus.
But there is a nugget in the introduction of a last call: I think that the ISE has a very hard time explaining to the RSE that a note that has backing of IESG consensus will not be published. (I am assuming the use of the appeal procedure as described in RFC5620, which I think is appropriate for a difference of opinion between RFC entities such as the ISE and the IESG). If in such conflict the RSE would choose sides of the ISE then I am pretty sure something is severely broken and the appearance of a note is the least of our problems.
So in other words what I am saying is don't invent process but follow existing pieces:
- put a note in front of the ISE o if the ISE pushes back- last call the note in the IETF, to make sure the IESG actually represents IETF consensus --whereby the consensus is called by the IESG following normal process and appeal--, and go back to the ISE telling that the note has IETF backing.
o if the ISE pushes back- consider this a disagreement between stream entities and follow RFC 5620 appeal process. o if the RSE chooses sides with the ISE the note gets published but the IAB, the IESG, and the RSE have some serious talking to do because something is severely broken elsewhere than just the note. The RFC will most probably be published without the note but the IESG has the possibility to publish a "This RFC sucks for this reason RFC" while the real problems are being addressed
Obviously publication of the document should be delayed on request from the IESG while the above is sorted out in a timely manner.
-- Olaf
________________________________________________________
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf