Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt)

[Bound, Jim]

Thomas,

OK here is one example not a document real-time.  multi6 is working
through their process to get to point where they can discuss next steps
for a very complex technology effort.  The WG and WG Chairs want to meet
in Vienna and multiple specs and ideas have been provided. The WG team
is working and an agenda is being worked.  The AD says we have nothing
to discuss because no proposal.  None of us agree with the AD.  The AD
was asked to please be more specific what they want and all we got so
far is one liners that have no depth or explanation and what we are
doing wrong.  That is a problem.  It also is real time example of us
getting one liners in the IETF that are completely not helpful to us in
the community.  The AD should defend now their case with explicit
positioning.

Rather than try to change this as multi6 has before we have created a
non IETF mutli6 list by invitation only and several solutions are being
implemented now for commercial use and will be driven in the market.  In
addition we try to meet offline at the IETF on our own dime and time.
In the Interim many of us propose RFC 3178 as temporary solution with
users doing SLAs that have multiple providers which will work for now.

This is happening with RDMA, Teredo, DSTM, ISATAP out of the IETF now
and will be deployed and in some cases are currently in the market on
IPv6 pre-production test beds and RDMA for IPv4.  Note the same AD would
not permit the latter transition mechanisms to be part of v6ops till a
set of scenarios are going to be defined.  OK fine we will do it out of
the IETF and drive it in the market without the IETF.  These were worked
on with consensus for 3 years.  We the WG were never permitted in the
debate to work on existing ngtrans work or if we all agreed with the
method of v6ops.  Don't get me wrong I am doing the v6ops thing and we
all are but the technology from ngtrans in fact was useful, is being
deployed, and will be used.  Just without the IETF.  I believe all will
put up experimental RFCs to put it in some IETF process.

So this is a REAL problem and we in the market are NOT going to wait for
the IETF any more I highly suggest we do have blockage at the AD level
and it is hurting the IETF and possibly its image because all of this
out of IETF work would not be supported or happening if real customers
includinug Providers, Industry, and Government were not intereested.
And no we are not going to reveal our customer efforts within a
standards body so don't ask (thats not to you really but general comment
and we do not lie and I suggest if I hear that response will be legal
one from me).

The IETF has to realize their scope and that is to do standards they are
not the visionaries or responsible for the deployment of the Internet.
If the IESG could get that around their brain and just do the job they
were hired for and that is specs based on IP architecture I think
progress would be better.

So blockage is a problem in some cases.  

Respectfully,
/jim



> -----Original Message-----
> From: Thomas Narten [mailto:narten at us.ibm.com] 
> Sent: Monday, May 19, 2003 9:57 AM
> To: Pete Resnick
> Cc: problem-statement at alvestrand.no
> Subject: Re: Document Blocking (Was: 
> I-DACTION:draft-ietf-problem-process-00.txt) 
> 
> 
> Pete Resnick <presnick at qualcomm.com> writes:
> 
> > On 5/16/03 at 2:49 PM +0200, Brian E Carpenter wrote:
> 
> > >  >          5. Modify IESG-internal processes to make it 
> impossible for one
> > >>              or two IESG members to block a document.
> > >
> > >There is a strong implication here that ADs might do this for
> > >spurious reasons.
> 
> > I don't think it makes a difference to the issue, but let's even
> > assume that it is *not* done for spurious reasons.
> 
> I have to say something here, as this issue keeps being 
> brought up. Reading this list, one could easily get the idea 
> that the ADs love to block documents, usually don't have a 
> good reason for doing so (and thus fall back to procedural 
> tricks), and that the ADs actually are hostile towards each 
> others with tit-for-tat happening if one AD blocks a document 
> belonging to someone else.
> 
> That is not the IESG I know or that I would want to be a part of.
> 
> It is my assumption and belief that when an AD puts in a 
> discuss, other ADs _do_ support that. [Note: this is a topic 
> I will bring up explicitely within the IESG, in case I'm 
> totally clueless about how others really feel here.] When 
> this isn't the case, the shepherding AD will object, argue 
> the issue isn't worth pushing back on, or provide other 
> context for why raising the issue doesn't make sense. Then 
> there is discussion and give and take. Sometimes the 
> objecting AD will withdraw their discuss, sometimes not. In 
> fact, it is quite common for other ADs to agree, but to 
> explicitely NOT put in a formal discuss, trusting the one AD 
> to deal with the issue satisfactoraly and not wanting to add 
> more process overhead (i.e., another AD that must clear their 
> discuss). One of the common "votes" that happens during the 
> telechats is "no further objection" which formally means "no 
> objection" but in practice means "I agree with others, but 
> don't have more to add and don't need to be in the process 
> loop to see that the document gets fixed".
> 
> Forcing the IESG to have "consensus" or "unanimity" (those 
> words have been used on this thread) on all discusses 
> procedurally seems like a high overhead approach for dealing 
> with a particular problem.
> 
> I'd actually like to better understand how much of a REAL 
> problem it is that individual ADs are impropropely blocking 
> documents with the "single AD veto". There are many comments 
> that imply it happens "all the time" and that "everyone has 
> examples". But I wonder sometimes if we are all thinking of 
> the same document from 3 years ago. We can't fix what 
> happened 3 years ago, but we can fix things that are broken _today_.
> 
> > >But if one or both Security ADs are deeply convinced that a draft
> > >constitutes a major security risk, or one or both Routing ADs are 
> > >convinced that a draft will lead to routing loops, isn't it quite 
> > >appropriate for them to block the document?
> 
> > Absolutely not, but *not* because the document shouldn't be stopped.
> > The ADs who think that there is a serious problem with a document 
> > should convince the rest of the IESG that the document is a bad
> > idea.
> 
> This in effect is happening AFAIK. The IESG does support the 
> security ADs when this happens.
> 
> > Then, the IESG can come to consensus (or unanimity) to reject a
> > document (or at least stop it until the problem is fixed).
> 
> I think it would be inefficient at best to force this level 
> of process onto discusses.
> 
> > The problem with the current process (as I understand it) is that it
> > allows documents to be blocked by one or two IESG members 
> without the 
> > consensus of the group.
> 
> In theory, yes. But in practice? It would be instructive for 
> the IESG to ask itself where this has happened, and I will 
> bring up the topic. My sense is very rarely, but I could be wrong.
> 
> But at least some on the community assume this happens often 
> enough that we need more procedure to prevent it from 
> happening. Concrete examples would be useful to provide context.
> 
> > The current procedure assumes that one or two IESG members must be 
> > able to block a document because the rest of the IESG is so 
> stupid or 
> > ignorant that they cannot be convinced that the document is a bad 
> > idea, even if one or two experts on the IESG know that it is.
> 
> That is one way to look at it, but it would be inconsistent 
> with my understanding of things. The way I see it is is that 
> when someone raises an issue, and the IESG supports the 
> objection, a one-person discuss is the staightforward way to 
> deal with the problem. Should responses to every discuss get 
> reviewed by the entire IESG? There is a scaling issue here...
> 
> > If that were actually the case, it points to a much worse state of 
> > affairs, where IESG members don't trust each other to do the right 
> > thing.
> 
> This is not the case, from what I know.
> 
> Note: This note might come across as sounding like I don't 
> think there are any problems that need fixing. There are. But 
> I am unconvinced that the "one AD veto" is one of the real 
> problems. Given that at least some in the community appear to 
> think it is a problem, I'd really appreciate some concrete 
> examples. My suspicion is that if we look at specifics, the 
> reality may be quite a bit different than the appearance.
> 
> Thomas
>