Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?)

Bound, Jim Jim.Bound at hp.com
Sat Jun 7 23:07:57 CEST 2003


Brian,

I in base principle agree with you.  But when an AD tells me this bit
shifting this way will cause a problem and I feel the AD is completely
wrong in a private discussion as author I think the AD and I should
debate that bit shifting technically in front of our peers not giving me
a mandate or holding up the spec or process because they are an AD.
The only AD on the IESG I have ever worked with that could stand in the
technical fire with me is Erik Nordmark and he is willing to go head to
head technically on total technical details not the politics of
interoperability (which is the next step).  Scott and Allison manage
that process very well as a note (or Scott Bradner did) so this was not
an issue I ever saw in the Transport Area.  I am not talking about
architecture I am talking down dirty deep code stuff from the outcome of
a protocol on implementation.

An AD not being able to do this but be suspect of a spec part is fine.
But:

1.  That should happen early on the WG should not spend 1 year on
soemthing that has been sitting in the spec and then 1 year later the AD
brings it up.  They should get an aw shit for that act and then later it
is an aw shit with the next NOMCOM.  Example declaring IPsec is wrong
choice for Mobile IPv6 at the last minute a few years ago was perfect
example.

2.  Open up as AD in the role of AD stating they fear this or that and
let the WG air it out and debate it.

/jim

/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian at hursley.ibm.com] 
> Sent: Tuesday, June 03, 2003 11:27 AM
> To: John C Klensin
> Cc: problem-statement at alvestrand.no
> Subject: Re: Trusting the IESG to manage the reform process 
> (was: Re:Doingthe Right Things?)
> 
> 
> John C Klensin wrote:
> > 
> > Summary: If we can't trust the current IESG for reform-process 
> > management, we are in deep trouble.
> 
> We have no choice except to trust them, because the IESG 
> approving a BCP is the only way (short of anarchy) of 
> effecting change.
> 
> So, as you were suggesting, let's divide-and-conquer by 
> cutting off bite sized problems, designing solutions, and 
> sending them to the IESG.
> 
> Er, I'm working on one of those. If everybody here worked on 
> one, we might be done soon.
> 
>    Brian
> 


More information about the Problem-statement mailing list