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

From: "Bound, Jim" <[email-masked]>
Date: Wed, 4 Sep 2002 22:35:33 -0400

I believe Fred has made a valid point on input to the charter.  The one-size-fits-all is  not a good way to view a tool.  This is a good catch in the wording of the charter.

thanks
/jim

> -----Original Message-----
> From: Fred L. Templin [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 7:49 PM
> To: [email-masked]
> Subject: Re: WG Review: IPv6 Operations (v6ops)
> 
> 
> Comments on the new proposed charter follow:
> 
> 
> >     * To: IETF-Announce: ;
> >     * Subject: WG Review: IPv6 Operations (v6ops)
> >     * From: Steve Coya <[email-masked]>
> >     * Date: Tue, 27 Aug 2002 10:05:36 -0400
> >     * Cc: [email-masked]
> > 
> > A new IETF working group has been proposed in the Operations and
> > Management Area.  The IESG has not made any determination as yet.
> > 
> > The following Description was submitted, and is provided for
> > informational purposes only:
> > 
> > 
> > IPv6 Operations (v6ops)
> > -----------------------
> > 
> >  Current Status: Proposed Working Group
> > 
> > Description of Working Group:
> > 
> > The global deployment of IPv6 is underway, creating an IPv4/IPv6
> > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 
> networks and
> > nodes. This deployment must be properly handled to avoid 
> the division
> > of the Internet into separate IPv4 and IPv6 networks while ensuring
> > global addressing and connectivity for all IPv4 and IPv6 nodes.
> > 
> > The IPv6 Operations Working Group (v6ops) develops 
> guidelines for the
> > operation of a shared IPv4/IPv6 Internet and provides guidance for
> > network operators on how to deploy IPv6 into existing IPv4-only
> > networks, as well as into new network installations.
> > 
> > The v6ops working group will:
> > 
> > (1) Solicit input from network operators and users to identify 
> >     operational or security issues with the IPv4/IPv6 Internet,  and
> >     determine solutions or workarounds to those issues.  
> This includes
> 
> The term "operational" needs to be defined. The above could
> be interpreted as implying that sub-optimal solutions are
> satisfactory, as long as they work in some fashion. I would
> like to see the term "operational" defined in such a way that
> the best solution for the problem space is considered; not
> just a one-size-fits-all solution that may be sub-optimal.
> 
> > (7) Identify open operational or security issues with the deployment
> >     solutions documented in (5) and fully document those open
> >     issues in Internet-Drafts or Informational RFCs. Work to find
> >     workarounds or solutions to basic, IP-level deployment issues
> >     that can be solved using widely-applicable transition 
> mechanisms,
> >     such as dual-stack, tunneling or translation.
> > 
> >     If the satisfactory resolution of a deployment issue requires
> >     the standardization of a new, widely-applicable transition
> >     mechanism that does not properly fit into any other IETF WG or
> >     area, the v6ops WG will standardize a transition mechanism
> >     to meet that need.
> 
> I find the above wording biased, since "widely-applicable" seems to
> be the only selection criteria mandated for the standardization of
> new mechanisms. I would like to see the above changed to allow for
> standardization of the best mechanism for a particular scenario;
> not just a one-size-fits-all.
> 
> By way of analogy, four-door sedans are "widely-applicable"
> vehicles. But:
> 
>    - minivans are a better choice for large families
>    - pick-ups are a better choice for hauling large loads
>    - 4wd's are a better choice for off-road driving
>    - etc.
> 
> Summary - the wording in sections (1) and (7) seems to mandate
> lowest-common-denominator solutions and ignore solutions that
> provide a better fit.
> 
> Fred Templin
> [email-masked]
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 4 Sep 2002 22:55:22 -0400

Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 7:00 AM
> To: Fred L. Templin
> Cc: [email-masked]
> "Fred L. Templin" wrote:
> ...
> 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: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 6 Sep 2002 16:07:44 +0200

> >=> Well, not everyone has to use 6-to-4 in a pure IP
  > >backbone. If they don't use 6-to-4 they need some other
  > >way of discovering the tunnel end point, I think the 
  > >BGP extensions do that job well. How else would you 
  > >do it, 6-to-4 for every site? 
  > 
  > 	what do you mean by 6-to-4?  assuming that you mean 
  > IPv6 over IPv4
  > 	tunnel, you can deal with it well enough with manual 
  > configuration.
  > 	you don't need any automation.
  > 	(you know, ISPs set up IBGP full mesh manually so we 
  > can deal with
  > 	it too)

=> Are ISPs also happy to setup there EGPs manually? 
I don't understand why we should drop something that makes
it either to setup tunnels instead of relying on manual
configuration. Just because people do it manually 
today is not enough to justify dropping it. If people
did that a few years ago, DHCP would not have been developed :)

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 6 Sep 2002 16:48:19 +0200

> Are you talking about the BGP Tunneling specification?

=> Yes.

  > 
  > Even if it were absolutely necessary to have some sort of BGP
  > extensions to make shared IPv4/IPv6 networks work (about which
  > there is apparently some disagreement), why would we want to
  > standardize BGP extensions in an OPS area WG, instead of doing
  > it within the WG responsible for BGP (the idr WG).

=> I don't care why or where it is done, why was it in 
the ops area to start with ?? 
I only care about seeing it done.

  > 
  > Based on the v6ops charter, the v6ops WG might identify a need in
  > this area, but then we would work within the idr WG to devise
  > an appropriate solution.

=> Fine, as I said I don't care where it's done, I want
to make sure it's not dropped, and it's very easy for a WG
to drop a spec without trying to help its authors find 
the right place.

Hesham

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 06 Sep 2002 11:31:15 -0400

Hi Hesham,

>to drop a spec without trying to help its authors find 

Before we officially disband the ngtrans WG, we will have
to make a decision about what to do with all of its WG
IDs.  There are a number of choice, but the main
options are:

        - The draft is reverted to an individual submission.

                This is the default choice for documents that
                don't find a new home.  Most of the ngtrans
                drafts will probably fall into this category.

                There is a further choice here -- whether to 
                change the name of the draft immediately, or 
                leave it as draft-ietf-ngtrans-*...  New
                revisions of these drafts would need to be
                done under the authors' names, as ngtrans 
                would no longer exist.

        - The draft is moved to v6ops or to another WG.

                In order for this to happen, the document
                would need to fit within the charter of
                another WG, and there would need to be a
                consensus within the WG to accept the 
                document as a work item
.
                I expect that we will officially accept 
                a few of the ngtrans work items (ones that 
                clearly fit into the v6ops WG charter) as 
                v6ops work items in Sunnyvale.

        - The draft is immediately expired.

                I don't think we will do this with any of the
                ngtrans work items, unless we have active 
                documents whose authors would prefer to have
                them expired, rather than reverting them to 
                an individual submission.

I realize that these aren't great choices.  The authors of ngtrans
work items have worked very hard to produce good documents that have
been accepted by the ngtrans WG and reflect WG consensus, and these
choices will represent an official step backwards for many of those 
documents.

In most cases, though, the actual status of this work won't really
have changed.  For the past several months, all ngtrans transition
mechanism work has been on-hold pending the outcome of our efforts
to define deployment scenarios and solutions, and none of this work
could be advanced unless it met most of the same criteria that are
listed in the v6ops charter.

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Sep 2002 00:11:09 -0400

also DSTM will not stop in the market that I gurantee.

/jim

> From: Bound, Jim 
> Sent: Tuesday, September 10, 2002 12:00 AM
> To: Pekka Savola
> Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> [email-masked]
> Subject: RE: WG Review: IPv6 Operations (v6ops) 
> 
> 
> Hi Pekka,
> 
> > From: Pekka Savola [mailto:[email-masked]]
> > Sent: Sunday, September 08, 2002 1:14 PM
> > To: Bound, Jim
> > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> > [email-masked]
> > Subject: RE: WG Review: IPv6 Operations (v6ops) 
> > 
> > 
> > Hello,
> > 
> > Getting back to a few points.
> > 
> > On Thu, 5 Sep 2002, Bound, Jim wrote:
> > > > On Wed, 4 Sep 2002, Bound, Jim wrote:
> > > > > I don't hear that from any user in that way.  What I hear 
> > > > is there are
> > > > > several good mechanisms they like and want to apply for 
> > different
> > > > > reasons.
> > > > 
> > > > For (over?) 95% of folks, they're just distraction.  And what 
> > > > we want here
> > > > is to get deployments going.  There's little need for 
> > > > anything fancy if
> > > > you don't require it. 
> > > 
> > > Deployment is going as best it can right now.  See the NTT MSC
> > > announcment that came out yesterday in Malaysia that is 
> > native IPv6.  
> > 
> > Native IPv6 is the proper and easy way.  The press release does not 
> > elaborate on the tunneling mechanisms used though.  And 
> > there's nothing to 
> > suggest v6-only (which was one of my "not of this world" 
> > arguments) there.
> 
> Nothing to suggest it is not v6 only and my impression is 
> that v6 only will be part of the solution.
> 
> > 
> > > I
> > > don't think ISATAP, DSTM, or Teredo are "fancy" but solid 
> mechanisms
> > > that work and for those moving at very fast pace.
> > 
> > Some are more useful than others.  I suppose they work, more 
> > or less, in
> > more or less restricted topologies.  I have doubts about the 
> > stability in
> > the long term or when more people would start to use them.
> >  
> > > The mechanisms I feel are imperative for wide deployment 
> > are as follows:
> > > 
> > > Basic Tunnels
> > > 6to4
> > 
> > Sure.
> > 
> > > ISATAP
> > 
> > May be useful in some scenarios (IMO, especially large 
> > enterprises with 
> > slow and sparse deployment or a lot of internal traffic).
> 
> I agree and to jump start IPv6.
> 
> > 
> > > Teredo
> > 
> > Have you read the latest versions of the draft?  It's a patch 
> > over a patch
> > over a patch against (mis)features of NAT (not a fault of the 
> > author of
> > course).  It's just too complex to work reliably.
> > 
> > I would rephrase this as:
> > 
> > "Some reliable and simple mechanism to provide v6 behind a NAT"
> 
> Yes I have read it and still state what I state.  It is a 
> solution to many customer problems who will adopt v6. 
> 
> > 
> > (Yes, it's possible -- but there are some engineering tradeoffs!)
> > 
> > > DSTM
> > 
> > I'm not yet convinced of this.  Especially I have huge doubts about 
> > temporary address management scalability and robustness.
> 
> There is not other mechanisms that treats IPv4 as DSTM does.  
> Our job here is not to decide if temp addr mgmt is scalable 
> the market will decide that.  Our job here is to decide if 
> the DSTM spec is functional.  I could argue a lot of what we 
> work on here is not scalable.  That is not our job.  The 
> market and vendors won't use it if its not scalable.
> 
> As far as robust?  What does that mean?  Why would you call 
> 6to4 robust?
> And define robust.  What is robust to you may not be robust 
> to my customers?
> And what I call robust may not be robust to your customers? 
> 
> Robust is to subjective we cannot state specs are robust or 
> not in the IETF.
> 
> > 
> > > BIA (in some cases but caution is needed)
> > 
> > May be useful for legacy apps, yes.
> >  
> > > NAT-PT and SIIT should be last resort and not used unless 
> > there is no choice.
> > 
> > Agreed.
> >  
> > > What is happening is that unless vendors, operators, and 
> some other
> > > entities I won't mention begin to make money on IPv6 they 
> > are going to
> > > stop momentum.  Fortuneately we are seeing real purchase 
> > orders for IPv6
> > > and boxes and software be sold at significant levels to warrant
> > > continued engineering and market investments. But those 
> > returns are not
> > > from the large mass that will move with LCD mechanisms or 
> > the 80% that
> > > will do as you say and want universal solutions (as Brian 
> > suggested).
> > > 
> > > So the catch-22 is that the 20% of custom users is where 
> we will all
> > > make our money for the next 3 years.  Then the masses will begin
> > > conversion.  So my issue is that to stop work on what we 
> > are doing that
> > > will make money is crazy in the IETF.  Maybe we need an 
> > advanced Ipv6
> > > transition area as Brian suggested but if that don't 
> happen fast the
> > > vendors and entities that want to deploy this 20% will not 
> > wait for the
> > > IETF and do it out of band and create a storm of defacto 
> > standards for
> > > IPv6 that will compete with the IETF in the market.  They 
> > have no choice
> > > and will not loose the mony waiting on 2 and 3 year 
> > discussions of how
> > > to do transition or settle for universal compromised solutions.
> > 
> > But are those 20% of users such that they *need* a "custom" 
> > transition 
> > mechanism?  Why not e.g. consulting them how to build their 
> > network using 
> > current mechanisms?
> 
> See we don't agree.  DSTM is a current mechanism but now its 
> been stopped by the IETF. It is being deployed and 
> specifically for Mobile IPv6.  See the market is not going to 
> wait for the IETF anymore in several spaces or 3G for that matter.
> 
> DSTM permits a Mobile IPv6 node that is doing mostly IPv6 to 
> get an IPv4 address if it needs one.
> 
> Users with IPv4 address space can use DSTM to leverage their 
> IPv4 address space to deploy IPv6.
> 
> > 
> > > > I don't think all of these non-basic, complex, fringe(?) 
> > > > mechanisms should
> > > > be discarded -- quite the contrary.  But this is probably(?) 
> > > > not the right 
> > > > place.
> > > 
> > > I am not sure yet.  Randy Bush has been saying IPv6 is here 
> > as operator
> > > and I agree. How IPv6 deploy is still TBD.  Why should not 
> > this true 20%
> > > deployment sector recieve the work from v6ops effort?  I 
> > think not doing
> > > it is not wise.
> > 
> > Randy Bush has a network/ISP operator background AFAIK.  
> > Deploying IPv6 
> > there is a much more simple task than deploying it properly in 
> > organizations.
> > 
> > There's much more to 'IPv6 is here' than having it enabled on 
> > dual-stack
> > routers.
> > 
> > > > I could say probably over 99% of folks doing this are not 
> > living in 
> > > > today's world.
> > > 
> > > This is simply not true I hope my above mail helps change 
> > your mind on
> > > this statement above as its as far as I can take to 
> convince you and
> > > others.
> > 
> > See comment above, I don't think v6-only is really here yet.
> 
> We will have to agree to disagree.  Thats ok it is two 
> distinct views of the market I guess.  As a product engineer 
> I know its working for my work and making money.
> 
> > > 
> > > > 
> > > > IPv4 just isn't ready to be "as-needed" at the moment, or 
> > > > you're probably
> > > > using it in very simple ways (e.g. www browsing only 
> > which works quite
> > > > well with NAT too :-).  It's IMO very questionable to 
> > approach IPv4 
> > > > needs with an "ad-hoc" ways when clearly the requirements for 
> > > > IPv4 are 
> > > > not, in reality, ad-hoc.
> > > 
> > > Ad hoc means the use of IPv4 is dicouraged as a policy 
> and used only
> > > when necessary.  So maybe adhoc was wrong term on my part.
> > 
> > And if it's necessary for a node to use it, 10, 100, 1000 
> > times a day?  Is 
> > Ad-hoc really the best way to go?
> 
> OK.  But you have not provided one technical argument against 
> DSTM nor has anyone else since the last draft-08 because the 
> working group did their job and the authors did their job 
> with updates.
> 
> All your arguments are a "gut" feeling against DSTM and "your 
> OPINION" of how IPv6 will be deployed.
> 
> Hardly an argument to not move forward with DSTM.  This is 
> not a club or social group it is the Internet Engineering 
> Task Force and DSTM performed that process and is being used 
> as all the mechanisms above.  Just because you don't like it 
> is not a fair way to stop it from being move forward.  In 
> fact if that happens it proves all I am beginning to dislike 
> about the IETF processes of late.
> 
> regards,
> /jim
> 
> >  
> > -- 
> > Pekka Savola                 "Tell me of difficulties surmounted,
> > Netcore Oy                   not those you stumble over and fall"
> > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> > 
> > 
> > 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Sep 2002 10:08:42 -0400

Hi Pekka,

> Sent: Tuesday, September 10, 2002 4:18 AM
> To: Bound, Jim
> Cc: Francis Dupont; Jun-ichiro itojun Hagino; Brian E 
> Carpenter; Fred L.
> Templin; [email-masked]
> On Tue, 10 Sep 2002, Bound, Jim wrote:
> > > No it *definitely* isn't, or I've misunderstood the 
> intent.  What has
> > > been proposed is something like 'when application requests and
> > > address, get it from somewhere, after application exists, 
> return it'.  
> > > That's very far from DHCPv4.  Add the ports option to the 
> stew and you
> > > have a mess..
> > > 
> > > Running DHCPv4 over DSTM (with reasonable address lifetimes etc.)
> > > would sound much better than currently proposed.
> > 
> > Read the DSTM Assumptions in the Spec.  This just 
> frustrates me to no
> > end.  The DSTM assumption is as follows.  "THE USER DOES NOT WANT
> > ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment 
> native".  They do
> > not want to begin their new IPv6 networks or update their 
> networks with
> > DHCPv4.
> 
> Perhaps I failed to convey my intent or you misunderstood it.  
> 
> What I meant was v6-only network + DSTM _without_ temporary address 
> management.  IPv4 addresses would be handled over IPv6 
> tunnels by DHCPv4 
> server, not the temporary address management system.   The 
> only difference 
> would be using existing protocol DHCPv4 for the task;  
> temporary address 
> management would indeed also be possible, and perhaps even 
> useful in the 
> cases that addresses are used by a very small number of 
> applications for 
> short periods of time only.  But otherwise, it seems like a 
> complication 
> right now.

I responded why not DHCPv4 for the main DSTM spec in other mail last night.
But clearly there can be spec with DHCPv4 but that complicates DSTM and DHCPv6 fits exactly within the architecture of DSTM.

But as I said one user has chosen this path but more because there was no dhcpv6 implementation 6 months ago.

>  
> > And to answer Rob's question.  Yes I know many customers who do
> > understand the DSTM assumptions.
> > 
> > But one DSTM deployment is using DHCPv4 this way but only 
> because DHCPv6
> > was not done.  The prime systems integrator just delivered a dhcpv6
> > solution to resolve that.  Again this is a trial network 
> but it will be
> > the production network of tommorrow.
> > 
> > Have you read the latest DSTM spec (like you asked me about Teredo)?
> 
> Indeed, I have read the latest spec (but only cursorily, the 
> only major
> thing that has changed is the applicability statement).  I 
> also commented
> on -07 (and DSTM-* technologies) on the ngtrans list (17 Mar 
> 2002).  Have
> you read my comments (I have received zero direct feedback)?

Hmmm.  I recall Octavio responding to you?  Can you repost I don't store IETF mail normally and for DSTM I just scanned and cannot find your input?  The update to draft 7 was just applicability per Alain Durand as chair and author too.\

Was it technical issue or deployment issue?  

thanks

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Sep 2002 10:21:42 -0400

Hi Pekka,

> Sent: Tuesday, September 10, 2002 5:51 AM
> To: Bound, Jim
> Well, but there could be.  Personally I've toyed with an idea 
> of writing
> Dual Stack Tunneling Mechanism (DSTM) draft.

I think it would be more productive if you would state what DSTM is missing now?
Other than the DHCPv4 issue and I have commented on that already.

> 
> > Our job
> > here is not to decide if temp addr mgmt is scalable the market will
> > decide that.  Our job here is to decide if the DSTM spec is 
> functional.  
> > I could argue a lot of what we work on here is not 
> scalable.  That is
> > not our job.  The market and vendors won't use it if its 
> not scalable.
> 
> I think our job is to provide properly engineered, technically sound 
> specifications.  Specifications that don't have any known technical 
> issues, or at least ones that aren't clearly identified.

That is the case we feel with DSTM and it is totally technically sound.

> > And define robust.  What is robust to you may not be robust to my
> > customers? And what I call robust may not be robust to your 
> customers?
> > 
> not in the
> > IETF.
> Sure, one cannot really define robust in general terms.  For 
> some it's one
> thing, for others something else.  But mechanisms that should 
> be widely
> deployed would use even more (and perhaps a tighter interpretation for
> analyzing robustness) scrutiny.

Bottom line this cannot be a bar for a draft to jump over if we cannot clearly define it and hence should not be a bar.

> [...]
> > OK.  But you have not provided one technical argument 
> against DSTM nor
> > has anyone else since the last draft-08 because the working 
> group did
> > their job and the authors did their job with updates.
> 
> Read my comments from 6 months back.

Please resend them.  I don't recall them other than being you did not like DSTM?

The one area I would like to improve is the use the gethostent struct time field.
But we have been forced to only product architecture doc. 

>  
> > All your arguments are a "gut" feeling against DSTM and 
> 
> There are more, but gut feelings are part of it, yes.  Is that a bad 
> thing.  Did people have "technical arguments" against NAT?  
> Gut feelings, 
> at least surely (I'm not saying DSTM == NAT, but to make a point: gut 
> feelings, intuition etc. do play a valid role).

And that is why we have NAT specs mine and others gut feelings were not used to prevent that work from reaching an RFC number.  And that was the right decision. 

But they should not hold up or prevent work.  If a spec is technically correct and the working group has worked it on its scope of merit it should move forward. 

The place to put our gut feelings is in the applicability section of documents as a note.

> 
> > "your OPINION"
> > of how IPv6 will be deployed.
> 
> Can anyone say anything else?  It's all opinions, hopefully 
> informed ones
> of course.

Yes they can.  I for example objected to entire notion of 6to4 relays I don't think they are technically required or technically defined well in the spec.  I lost that discussion and now accept and make the spec work as best I can in the industry.  You know how I feel about site-locals and my technical arguments against them.  But in all my counter non consensus input it was based on technical input not gut input.  My gut is 6to4 is to general and I don't like general except for general cases.  IPv6 as I said in other mail for initial deployment requires non-general mechanisms and that is the crux of where you and I and others disagree.  It like so many of our specs are a design by committee and that just waters it down.  SCTP on the hand is an excellent example of a design by an engineering team and then worked on by the IETF processes.  That is how I want DSTM to be done.  DHCPv6 is now suffering from design by committee and we are trying to make sure it is not watered down.

> not a club or
> > social group it is the Internet Engineering Task Force and DSTM
> > performed that process and is being used as all the 
> mechanisms above.  
> 
> ...
> 
> > Just because you don't like it is not a fair way to stop it 
> from being
> > move forward.  
> 
> There are reasons I don't like it, and I'd like to see it 
> changed so that
> both operational procedures would be possible (with "core" 
> procedure being
> the simplest one).

Then suggest your changes but I don't buy the DHCPv4 idea at all.  

> 
> > In fact if that happens it proves all I am beginning to
> > dislike about the IETF processes of late.
> 
> You'd like the IETF take out the rubber stamp?

Not what I am saying.  What I am saying is the IETF needs to just do technical work and not pretend they can do all things for all people.  When that technical work is done then a stamp is important for sure.  But stopping work because of gut feelings and power plays by authority don't sit well with me.  It is simply not fair.

Also DSTM discussions have existed and have been discussed this is not new.

/jim