Subject: RE: WG Review: IPv6 Operations (v6ops)

From: "Bound, Jim" <[email-masked]>
Date: Thu, 5 Sep 2002 09:18:11 -0400

Brian,

I can agree with what you say below for sure.  Except for host stacks.  I think if there is enough money on the table vendors will collaborate quite well.  Look at RDMA if the IETF moves to slow here trust me RDMA with copy avoidance et al will happen while we are still discussing it in the IETF.  The IETF is too slow now and in the mission to find the perfect spec we have lost time-to-market in our processes.  Not all host stacks have to be used to adopt a technology like RDMA but if just 3 or 4 major vendors agree it does cause an effect in the market.

Don't get me wrong I would love to see the IETF move faster, better, and lately in a more fair process.  And one thing that would really help is something I said to Scott Bradner (one of the area directors I keep voting for fyi and him an allison run one of the most efficient areas in the IETF and why I have hopes for RDMA in the IETF) at a plenary about 2 years ago is: "It is imperative that "consistency" be used across the IETF.  For example lets take the silence vs no silence for consensus in a working group. One does one thing the other does the other.  For processes of governing I think this should be consistent whether I am working on IPv6 transition or Routing or SCTP.  It is not today.  Also Area Directors need to be more like "managers" than "engineers".  And leave technical work to us in the working group and the chairs.  My view is the IESG is a management body more than a technical body.

But if we want to start an advanced transition area I will support that but we need that started A.S.A.P.  

regards,
/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, September 05, 2002 6:11 AM
> To: Bound, Jim
> Cc: Fred L. Templin; [email-masked]
> Subject: Re: WG Review: IPv6 Operations (v6ops)
> 
> 
> "Bound, Jim" wrote:
> > 
> > also I do not consider 6to4 an LCD.  It is a custom 
> solution for many users.  And a method that can be used by 
> other mechanisms to work with.
> 
> That's why I was concerned about special pleading, but 6to4 
> wasn't intended
> as a custom solution, but as a general technique to help 
> bootstrap IPv6 adoption.
> 
> Anyway look again at what I said (or meant to say). I think it's
> appropriate to limit an ops WG to simple, hopefully 
> universal, solutions
> and it's also appropriate to work on advanced solutions *in their
> own WG*. I think that's a win-win. If you look at the amount of
> agenda time that DSTM, ISATAP or Teredo have been getting in NGTRANS
> meetings recently you can see why they would be better in a separate
> group. Just doing it in the market doesn't cut it for solutions that 
> require host stacks to collaborate.
> 
>    Brian
> 
> 
> > 
> > /jim
> > 
> > > -----Original Message-----
> > > From: Bound, Jim
> > > Sent: Wednesday, September 04, 2002 10:55 PM
> > > To: Brian E Carpenter; Fred L. Templin
> > > Cc: [email-masked]
> > > Subject: RE: WG Review: IPv6 Operations (v6ops)
> > >
> > >
> > > Brian,
> > >
> > > > -----Original Message-----
> > > > From: Brian E Carpenter [mailto:[email-masked]]
> > > > Sent: Wednesday, September 04, 2002 7:00 AM
> > > > To: Fred L. Templin
> > > > Cc: [email-masked]
> > > > Subject: Re: WG Review: IPv6 Operations (v6ops)
> > > >
> > > >
> > > > "Fred L. Templin" wrote:
> > > > ...
> > > > > Summary - the wording in sections (1) and (7) seems to mandate
> > > > > lowest-common-denominator solutions and ignore solutions that
> > > > > provide a better fit.
> > > >
> > > > It's hard to avoid special pleading (since the 
> transition solution
> > > > with my name on it is in the list), but I do think that there
> > > > is a strong
> > > > argument for concentrating on LCD solutions for the first wave.
> > >
> > > Then stated it please Brian.  Your really not responding to
> > > Fred's wording.
> > > The market wants special solutions like ISATAP, Teredo, and
> > > DSTM and they are all being deployed by customers I know of
> > > and will not share so no one ask.  Granted its trial networks
> > > but that is how it starts.  An LCD solution is good but not
> > > for all cases. Fred's car to minivan to truck is a perfect
> > > analogy he sent out.  In my case I require a truck to haul my
> > > guns and german shepherds around :--).
> > >
> > > That being said I am being silent on all of this because as
> > > far as I am concerned ISATAP, Teredo, and DSTM all got
> > > screwed by the IETF process after years of support and work
> > > by the working group.  But that is OK because if we don't
> > > continue this work in the v6ops group under some valid
> > > assumption based on the charter definition I for one will go
> > > do the work in the market and not in the IETF.  I don't know
> > > how Christian and Fred feel but I know DSTM is being deployed
> > > and we can create a defacto spec if necessary and move it
> > > into the market.  I am not playing this game much longer.
> > > Its absurd.  In fact its not just IPv6 transition.  Its in
> > > many places of the IETF.
> > >
> > > If someone finds technical flaws or problems in design of
> > > specs thats cool and they have to debate and state and defend
> > > their position.  But to just tell a working group and authors
> > > "we just don't like it and its not needed" is hardly the IETF
> > > process I have come to spend so much energy on because it is
> > > completely unfair.  I won't put up with it and I think many
> > > vendors won't put up with it.  We have enough momentum and
> > > forums and lots of coordinated efforts in the industry now it
> > > might be time to just by-pass the IETF and just go do it and
> > > maybe that will give our process a wake up call.  Because one
> > > is needed.
> > >
> > > But I would really like to hear you technically defend or
> > > even from market perspective why you believe the LCD is a 
> good idea.
> > >
> > > >
> > > > We might contemplate a separate IETF activity for advanced
> > > transition
> > > > solutions.
> > >
> > > I don't think so.  We will just do it in the market thank you.
> > >
> > > regards,
> > > /jim
> > >
> > > >
> > > >    Brian
> 
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Sep 2002 14:20:09 -0400

This is a bit off topic, but I want to respond anyway.

"Bound, Jim" <[email-masked]> writes:

> Don't get me wrong I would love to see the IETF move faster, better,
> and lately in a more fair process.  And one thing that would really
> help is something I said to Scott Bradner (one of the area directors
> I keep voting for fyi and him an allison run one of the most
> efficient areas in the IETF and why I have hopes for RDMA in the
> IETF) at a plenary about 2 years ago is: "It is imperative that
> "consistency" be used across the IETF.

I am in support of consistency, where it make sense. 

> For example lets take the silence vs no silence for consensus in a
> working group. One does one thing the other does the other.

There are good reasons for this. In some WGs, the WG never says
(hardly) anything, even when something seems like a bad or even
dangerous idea. The WG chairs (and ADs) are supposed to ensure that
specs are baked and won't cause problems when deployed. So, asking for
explicit support is a useful tool to force people to come out and say
"I have looked at this, and I think it is good stuff". One doesn't
always need this. It depends on the WG and the specific document at
hand. I (as an AD) have asked to see explicit WG support when I have
concerns about a document and it seems like nobody is actually looking
at the document and it seems like a document is moving forward only
because nobody seems to be objecting. If no one is willing to speak up
on behalf of a document (other than the authors) that is often cause
for concern...

> For processes of governing I think this should be consistent whether
> I am working on IPv6 transition or Routing or SCTP.  It is not
> today.  Also Area Directors need to be more like "managers" than
> "engineers". And leave technical work to us in the working group
> and the chairs. 

ADs are (and need to be) both. ADs certainly believe they are
obligated to ensure that specs are baked and complete from a technical
perspective. This is not just a managerial function, it requires being
able to do technical assessments and reviews. The motivation comes
straight out of RFC 2026.

If the ADs don't intervene when there are technical problems with a
document, who will?

Thomas