My thoughts about the problems of the IETF

[Bound, Jim]

Well said Scott.  Key is that the process is open and IESG state their
technical positions and if necessary also defend them in public.  Very
important the IESG be careful with non technical decisions and have
better gauge to determine community consensus.  Back room tactics in the
IETF are part of most problems.  The IESG also has to admit it when they
are technically proven wrong or it is shown they do not have the
technical expertise to answer an issue.

That being said all good processes require a check and balance.  The
IESG has two: The IAB for appeals, and the market who can ignore them
and build a standard they don't agree with and that affects the IETF
overall regarding perception in the market.  I think we need another
check and balance when the IESG makes significant errors.

I also think the IESG members should not be in anyway involved with the
nomcom process at all.  As I said before that is like having the
government in a voting booth with you.

I also think IESG members should never respond to mail lists with
philosopy quips or meaningless phrases with no technical or direction or
et al content during technical discussion.  First, many working group
members believes they are being intellectually dishonest and are really
unable to keep up with the technical discussion, and Second once you're
an IESG member you have a certain decorum required of you and
responsibility that maybe we should document for IESG members.  Good
examples of two Ads that respond in depth and think out very well the
response and focus on the problem are Erik Nordmark and Thomas Narten.
Their technical responses are par excellence.  Even if I don't agree I
can have good deep technical discussion with them.  Scott you were this
way too and why I was quite not happy you were not on the IESG.

But.....the IESG is only a fraction of the overall IETF problem, and
should not be blamed for the many many problems of this SDO. 

I read the minutes, I read this mail, I read Harald's response, the IETF
problem is happening right on the problem list.

What is our mission?
What is our objective?
What is our deliverable?
What is our due date for that deliverable?
What is our penalty if that deliverable is not met?

The above should be our focus and meeting a deliverable.  Otherwise we
are simply the proof that the IETF cannot solve this and it will either
bog down and die or long term competing Forums, Consortia, or other SDOs
will move without the IETF.  

/jim

> -----Original Message-----
> From: Scott Bradner [mailto:sob at harvard.edu] 
> Sent: Thursday, April 17, 2003 10:28 AM
> To: problem-statement at alvestrand.no
> Subject: Re: My thoughts about the problems of the IETF
> 
> 
> > It is a fundamental precept of the IETF that the rough consensus of 
> > the "mobs", developed in a fair and open process, will produce good 
> > results.  And, all of our processes and systems are built 
> around that 
> > assumption.
> 
> this is far to simplistic
> 
> To me, one of the principal things that makes the IETF the 
> IETF and not "just" one of the many other SDOs, and in 
> particular, other multi-disciplinary SDOs, is that the IETF 
> has an overarching *technical* management as part of its process.  
> 
> The role of the IESG is not just to verify that the processes 
> have been followed, but to also do an actual technical 
> review.  Consensus in a working group, by itself, has never 
> been sufficient in the IETF to cause publication as a 
> standards track RFC.  
> 
> The idea that a technical review of the output of a working 
> group is part of the IETF is not new.  See RFC 1310 (RFC 
> 2026's grand parent) sec 2.6. At that time the IAB was the 
> formal approval committee (not the IESG) and technical review 
> could be quite a production, potentially being done by a 
> specially commissioned technical review committee 
> commissioned by the AD or IESG even before it got to the IAB 
> where the IAB did its own technical review.  This process was 
> simplified somewhat in RFC 1602 (RFC 2026's
> parent) but a technical review was still an important part of 
> the IETF process.  This importance was retained in RFC 2026.
> 
> It is my opinion that it is the IESG's responsibility (not 
> just right) under 2026 to do a technical review and pushback 
> on a working group if finds a *technical* (or clarity) 
> problem with a proposal.  Even if 
> the working group has a strong consensus in support of a proposal.
> 
> I think the IESG has this responsibility under RFC 2026 sec 6:
> 
>    "The experienced collective judgment of the IESG     
>    concerning the technical quality of a specification 
> proposed for     
>    elevation to or advancement in the standards track is an 
> essential   
>    component of the decision-making process."
> 
> and RFC 2026 sec 6.1.2
> 
>   "The IESG shall determine whether or not a specification 
> submitted to
>    it according to section 6.1.1 satisfies the applicable criteria for
>    the recommended action (see sections 4.1 and 4.2), and shall in
>    addition determine whether or not the technical quality and clarity
>    of the specification is consistent with that expected for the
>    maturity level to which the specification is recommended."
>    . . .
>    "the IESG may, 
>    at its discretion, commission an independent technical 
> review of the
>    specification."
> 
> and RFC 2026 sec 4.1.1
> 
>     "A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it."
> 
> Also, in my opinion, proposals which have inadequate security 
> or might have a significant negative impact on the health of 
> the Internet (e.g., no or poor congestion control) fail this 
> requirement for "no known technical omissions"  and the IESG 
> is required to push any such proposals back to the working group.
> 
> As an aside, I think that the IESG needs to be quite public 
> when doing any pushback, it should not just interact in a 
> back room with a document editor
> -- any pushback (or other IESG or AD comments on a proposal) 
> must be in public and recorded for the record.
> 
> As hinted above, I do have a problem with the IESG making 
> decisions based on non-technical issues (other than document 
> clarity, which is specifically called out in RFC 2026) unless 
> the decision is supported by community consensus.
> 
> Scott
>