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

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 May 2003 17:10:07 -0400

Hi 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.
> 
> There seems to be some misunderstanding. My understanding 
> (after having happened to talk with Randy who doesn't have 
> email access right
> now) is that multi6 will be allowed 2 slots, but that a 
> request for 3 (yes _3_) was denied.

Yep. Big time.  We did not get this on email and the chair just asked
yesterday and I have been watching the list religiously.  But could be
chairs agreed in last few days with Randy.  We did not even ask for two.
We asked for one and would do the other on our own knowing how busy the
IETF is and the ADs.  So big confusion going on here.  

> 
> > 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.
> 
> As you know, all of the specific transition proposals 
> (excluding those already RFCs) are out-of-scope for v6ops 
> until the scenarios work is done. The purpose of this is to 
> make sure that we validate the actual transition scenarios 
> that we believe are important and then find/develop the right 
> transition tools for those scenarios. This was done to 
> counter the seeming plethora of transition tools that the 
> IETF was developing with no clear roadmap of which ones 
> should be used when, where and by whom..

What really happened was the ones that were being used by the market
which are Teredo, Tunnel Broker, DSTM, and ISATAP go lumped with all the
other ones that were not being used at all and it was never we have 15
solutions.  We had 7 and that is not to many at all and that is the
discussion that the WG did not participate in and should have IMO.
Transition will require many methods and that is just the nature of the
beast.  So plethora is hardly the correct description to my view.

The point for this list is that we did not have a "discussion" but a
decision.  That is not an open process.

> 
> This was not a one AD decision. I (and other ADs) were 
> involved in the recharter and I supported it (and still do). 
> So let's be clear to separate the issue of what the WG is 
> working on from the notion that the current activity is the 
> unchecked action of a single AD.

This should have been communicated and those ADs should have come to the
WG and discussed it with the WG.

This is water under the bridge (or over) and we are all working on v6ops
but doing the others for now out of the IETF and deploying them which is
the end result we are not waiting for the v6ops or IETF process.  

The point for this list is that the decision caused a set of events that
could have been avoided had there been more discussion and the ADs
working with the WG and hearing them.
Specifically on the issue of why there will be a few transition
mechanisms.

/jim

> Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 May 2003 08:09:47 +0300 (EEST)

> IETF is and the ADs.  So big confusion going on here.  

I think folks are reading too much to Randy's email:

--8<--
Date: Thu, 15 May 2003 18:36:38 +0200
From: Randy Bush <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: [email-masked]
Subject: Re: Agenda for Vienna

> So, why not have three 2H sessions and stop saying "time constraint"?

because you will need a different AD to approve it.  this wg has yet
to show good use of one session.  you don't get any pudding unless
you eat your meat.
--8<--

(The history is that multi6 has not met in about a year because there has 
not really been a good agenda, etc.)

This is a response to an individual who keeps pestering the WG to schedule 
3 sessions so he could yet again present his own proposal (among other 
things).  I may be biased in here, though..

Some may have read the message as "nyah nyah, you don't get even one
session, suckers!!".   I didn't.  I read it to say that as there hasn't 
been a plan to schedule even one session before this, it is completely 
unrealistic to now bump to 3.  So 3 is out of question, but others are 
still on the table.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings