Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of I

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 the
> consensus 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

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf