Subject: RE: what happened to newtrk?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 12 Sep 2006 13:26:24 -0700

John,

While I agree that the IESG unlikely to change how it behaves I still don't think you have explained why it should resist changing the process so that it describes how it behaves in actual practice.

Phill 

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Tuesday, September 12, 2006 2:51 PM
> To: Eliot Lear
> Cc: IETF Discussion
> Subject: Re: what happened to newtrk?
> 
> Eliot,
> 
> The discussion of the question you asked here seems to have 
> been immediately sidetracked.  I, at least, believe the 
> original question is worth some community discussion and 
> possibly a conclusion.  More below.
> 
> --On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear 
> <[email-masked]> wrote:
> 
> > All,
> >
> > As a participant in the newtrk working group and someone 
> who  actually 
> >ran one of the only reasonably successful experiments  in 
> that group, I 
> >think the community is owed a better  accounting of why WG 
> failed, and 
> >that steps should be taken to  see that such efforts do not 
> fail in the 
> >future.  The newtrk  working group was chartered to revise the 
> >standards track,  with an understanding that the current one is 
> >demonstrably not  working as it should.
> >...
> >  However, the end result was that we had a working  group 
> chartered to 
> >do a specific task, do the task, and then  have the work rejected.  
> >Quite frankly we don't have the  resources to have that happen.  I 
> >suspect anyone who had any  involvement with that group will be 
> >extremely reticent to work  on process proposals in the 
> future, because 
> >they will assume  that any given IESG is likely to reject any output.
> 
> That is certainly the conclusion to which I, and at least 
> some others who put energy into Newtrk and related work, have come.
> 
> > What I would like to know is what we could have done to 
> prevent this 
> > from happening.  Was the newtrk charter not sufficiently narrow to 
> > accomplish a task for which there was community consensus?  Is a 
> > working group the appropriate place to make process changes?  I am 
> > leaning heavily toward "no" on that last one.  Should the 
> IESG simply 
> > both propose and dispose?  Perhaps the IAB has a role of proposing 
> > changes.
> 
> I do not believe that WG-or-not is the key issue, even though 
> I continue to have doubts as to whether a regular WG is 
> adequately representative of the IETF participants impacted 
> by significant 
> process changes to be the ideal final review mechanism.   Within 
> limits, a WG may be a reasonable mechanism for proposing 
> approaches and solutions and/or working through details of 
> them, but we do need to be careful about creating WGs that 
> are dominated by would-be process experts with little actual 
> experience in the technical work of the IETF.
> 
> > Eventually, as I wrote in a previous note, we must circle back and 
> > actually fix the standards process to reflect reality.
> > But how that is to be done remains to me an open question.
> 
> I think the lesson to be drawn is that one that you have implied
> above: it is unlikely that any serious process changes will 
> succeed as long as the IESG is the body that must approve 
> such changes.  This is not a criticism of any particular IESG 
> or IESG member.  Instead, it is the result of observation and
> experience: the IESG is appointed to do a particular job, is 
> under huge pressures to do that job, and tends to "train" new 
> members about how that job works.  Any new model of the job 
> to be done naturally leads to a very conservative reaction: 
> doing things differently will always involve more work, if 
> only in developing new detailed procedures and non-disruptive 
> transition mechanisms, and we tend (properly) to select IESG 
> members whose primary commitment is to the short-term 
> objective of processing as much of the IETF's technical work 
> as possible.
> 
> The consequence is that it is unreasonable to expect the IESG 
> to evaluate and agree to non-trivial process changes.  Even 
> if I had not been convinced of that after the Newtrk 
> meltdown, the recent response to draft-klensin-norm-ref would 
> have been completely persuasive.  That response isn't wrong 
> -- both the model in RFC 3933 and the I-D were written to 
> give the IESG the discretion to reach the conclusion they 
> reached -- but it shows a response so conservative as to make 
> the writing of the proposal not worth the effort, at least IMO.
> 
> That, I think, leaves two questions for the community:
> 
> (1) How should things be arranged so that the IESG does not make 
> the final decisions about process changes?   And,
> 
> (2) If the community can reach some rough consensus on the 
> answer to that question, how does one get the IESG --which 
> has not been sympathetic to efforts to reduce their perceived
> authority-- to approve it or how does it get adopted without 
> IESG approval.
> 
> I am not yet to the point that I would try to get the 
> community to convince the Nomcom that a promise to approve a 
> proposal to transfer approval of process changes away from 
> the IESG should be a precondition for appointment (or 
> reappointment) to the IESG but, if the community is serious 
> about process changes, it could come to that.
> 
> Just my opinion
> 
>     john
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Sep 2006 18:06:08 -0400

--On Tuesday, 12 September, 2006 13:26 -0700 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> John,
> 
> While I agree that the IESG unlikely to change how it behaves
> I still don't think you have explained why it should resist
> changing the process so that it describes how it behaves in
> actual practice.

You are correct.  I did not address that issue, partially
because, personally, I do not consider it very important.  While
documenting what we are doing would be nice, I don't believe the
community is completely happy with what we are doing and, hence,
that energy would be better spent figuring out how to move
forward.

That said, if I were on the IESG, with many demands on my time,
I'd have serious doubts about the value of time spent getting
agreement on exactly what the current procedures are, probably
contraining behavior to those procedures, etc.   In addition,
I'd have doubts, based on experience, that any effort to fully
document existing procedures would not result in a debate about
whether those procedures are appropriate (one which, as you
know, is ongoing already), tuning or modifying those procedures,
etc.  So one might rationally conclude, first, that fully
describing the behavior as practiced would be nearly impossible
and, second, that it wouldn't be worth the effort.  

Making improvements is another matter; it is at least possible
to justify that effort as worthwhile if the proposed
improvements really are improvements.

--On Tuesday, 12 September, 2006 16:32 -0400 "Steven M.
Bellovin" <[email-masked]> wrote:

> The IAB spends -- or spent; I haven't been on the IAB since
> 2000 -- an amazing percentage of its time on layer 9 issues.
> Most IAB members dislike that (and some ignore that part), but
> much of it seemed to be stuff that the IETF had to do.  I
> suppose we could ask the Nomcom to select an IPB or an IPSG as
> well, but all things considered (and as one of the former
> stuckees) I think we're better off if our political relations
> were handled by folks with technical clue -- that is why the
> IETF's participation is generally sought.

Steve, I agree about layer 9 issues and the problems associated
both with investing the IAB in them and in seeking other
alternatives.   But I see process change issues --ones that
impact how the IETF operates and makes decisions-- as somewhat
different from external political and policy issues.  The impact
of decisions about them is different, as is the kind of
expertise needed to evaluate proposals against how the people
who do work in the IETF do, or might optimally do, that work.

That said, the only suggestion I've made over the last several
years about shifting process approval responsibility to the IAB
involved having that shift be temporary and part of a process of
figuring out some other model.   I don't consider the IAB a good
long-term solution for process review and approval, partially
because I prefer an IAB that has a bit of distance from and a
different perspective on, active IETF standards-development and
decision-making (that view is probably controversial).  But, if
we are going to make process changes we need, IMO, to get
unstuck from a situation in which the IESG is both naturally
resistant to, or at least very conservative about, such changes
and is the group that makes decisions about whether they are
appropriate for the community.

It _might_ be plausible to make the IAB --just because it is
there-- the review and consensus-evaluation body for a single
new proposal or package of proposals about how we make process
decisions going forward.  The only alternative I can see (other
than bloody revolution) involves the selection of some sort of
"constitutional convention" body. I fear that such a body would
not be close enough to the IETF's technical work and how it gets
done to produce a satisfactory result that optimizes that work,
rather than elegant process models for those who like process
models.

    john

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Sep 2006 18:48:30 -0400

> that energy would be better spent figuring out how to move

I think that if people are interested in documenting what we are currently 
doing, the most effective way to do that is for someone to write one or 
more informational, descriptive internet-drafts that attempt to document 
the current state of affairs, and then ask for input on them.  The 
author(s) of such documents should feel free to reject input suggesting 
that the process should be changed as out of scope.

I think that if someone had the desire and energy to do this work, it could 
be done relatively easily and without much controversy, provided it was 
understood to be non-normative in nature.  I don't consider such an effort 
useful enough to engage in it myself, or to actively encourage someone else 
to do so.  But I certainly won't _discourage_ someone who's interested in 
spending time on such an effort.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Sep 2006 11:57:30 +0200

Jeffrey Hutzelman wrote:
> I think that if people are interested in documenting what we are 
> currently doing, the most effective way to do that is for someone to 
> write one or more informational, descriptive internet-drafts that 
> attempt to document the current state of affairs, and then ask for input 
> on them.  The author(s) of such documents should feel free to reject 
> input suggesting that the process should be changed as out of scope.

I have written draft-carpenter-rfc2026-critique-02.txt. There's a
convenient version at
http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-02.html
I hereby ask for input on it.

     Brian

> 
> I think that if someone had the desire and energy to do this work, it 
> could be done relatively easily and without much controversy, provided 
> it was understood to be non-normative in nature.  I don't consider such 
> an effort useful enough to engage in it myself, or to actively encourage 
> someone else to do so.  But I certainly won't _discourage_ someone who's 
> interested in spending time on such an effort.
>