[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Review: IPv6 Operations (v6ops)
Hi Pekka,
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Tuesday, September 10, 2002 5:51 AM
> To: Bound, Jim
> Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> v6ops@ops.ietf.org
> Subject: RE: WG Review: IPv6 Operations (v6ops)
>
>
> On Tue, 10 Sep 2002, Bound, Jim wrote:
> > > (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.
>
> 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.
>
> > 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.
>
> 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.
>
> [...]
>
> > > 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.
>
> 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.
>
> > 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.
>
> 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
>
> --
> 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
>
>