Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2

[Richard Ogier <[e-mail]>]

Stan Ratliff (sratliff) wrote:

> 
>
>>-----Original Message-----
>>From: Richard Ogier [mailto:[e-mail]] 
>>Sent: Tuesday, October 03, 2006 2:44 AM
>>To: Stan Ratliff (sratliff)
>>Cc: Acee Lindem (acee); [e-mail]
>>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
>>
>>Stan Ratliff (sratliff) wrote:
>>
>>>Richard, 
>>>
>>>>I was hoping that the WG would want to standardize the best possible
>>>>extension of OSPF.  
>>>>
>>>First off, there are those of us that aren't convinced that MDR's are
>>>the 
>>>"best possible extension of OSPF".
>>>
>>Right.  (Otherwise we would have consensus.)  My point is that the WG
>>should try to choose the best solution, rather than let politics
>>dictate the choice.  To achieve this, it would be very helpful to
>>agree on criteria.  I am starting to have doubts that this WG
>>can succeed in choosing the best solution, and it seems that Tom and
>>Joe have similar doubts (based on their recent posts).
>>
>>>
>>>>But from what Joel is saying, Cisco could pay
>>>>several people to implement their solution, and it would be adopted
>>>>as the standard regardless of how good the solution is?
>>>>
>>>Wow. Now, Cisco is going to "pay several people to implement" the
>>>OR solution, just to get it adopted?
>>>
>>That is just a hypothetical example (as I'm sure you know but 
>>you prefer
>>to distort my intended meaning).  Cisco would probably be more
>>tricky or subtle.  My point is that it is quite possible that the
>>
>
>Ah yes, of course. More tricky or subtle. *This* was the point 
>of my post -- I was illustrating your absurdity by being absurd.
>

Actually, that was intended as a compliment.  Most large companies
use clever tricks to promote their products.  Consider for example
how Bill Gates originally got lots of people to use Windows.
But that was just a side comment, not my main point, which was
that people do not always implement the best solution, but often
choose a particular solution for political reasons.
Actually, this may not be my main concern, since I am sure the
MDR solution will also get implemented.  Instead, my main concern
is how consensus can be achieved without any agreed on criteria,
especially if each team prefers their own solution.
For example, Joel Halpern said

> If several get implemented and deployed, then we hope to learn things 
> from that deployment.  We may discover that factors that never 
> occurred to the working group will turn out to be important.  It may 
> be that factors the working group thought important turn out to be 
> irrelevant. 

That may sound good, but how do we define what is "important"?

As you suggest below, I agree that we should focus on technical
discussions.  For example, that is why Aniket and I have been
explaining why the MDR approach is a "natural extension".
This is a very important point, since once people understand
*why* we claim it is a "natural extension", they will understand
the MDR approach better.

Richard

>
>You have assigned some eeeeeeeeevil, nefarious, "conspiracy-
>theory" motive to *everyone* that has disagreed with you, and
>I'm tired of it. Quite a few days ago, I laid out my technical 
>concerns with proceeding with the MDR draft. You chose not 
>to refute my points. Instead, you have chosen to question my 
>(and everyone else's) motives. (As an aside to Tom Henderson,
>*this* is what Russ was referring to when he said that people
>have been "shouted down".)  It's wrong, it's out of line, it 
>doesn't forward the debate, and it needs to stop.
>
>I've been trying to forward the debate in a professional manner, 
>understanding that people have technical reasons for advocating 
>their positions, and that honorable people can disagree honorably.
>I can most assuredly state that I have not questioned *your* 
>motivation; so why is it "in bounds" for you to question mine? 
>Why is it that ad hominem attacks are allowed from one side of 
>the debate only?  I have technical reasons for disagreeing with 
>you. I deserve to be heard, without all of this non-productive 
>noise. And I think we *all* need to agree that it's wrong and 
>needs to stop. 
>
>Stan
>
>
>
>
>>solution that is implemented by the most people is not the 
>>best solution,
>>since people can be influenced to implement a particular solution for
>>political or financial reasons.
>>
>>But we can avoid politics simply by agreeing on criteria
>>and then comparing the solutions in a fair manner.
>>This was the original plan when the design team was started.
>>
>>Regarding INRIA and MPRs, it is well known that INRIA has an interest
>>in MPRs and would like to promote them.  But if they truly believed
>>MPRs were the best way to extend OSPF, then why don't they cooperate
>>and implement their proposal in GTNetS?
>>
>>If you don't like the term "natural extension", then ignore the term
>>and just focus on what we *mean* by it, as explained in recent messages
>>by me and Aniket.  For example, the way OSPF-MDR achieves 
>>scalability in
>>MANETs is similar to the way OSPF uses DRs to achieve scalability in
>>broadcast networks.  An MDR is a true generalization of a DR, but
>>an MPR is not a true generalization of a DR.  In fact, there are no
>>MPRs in a single-hop MANET.
>>
>>Richard
>>
>>>And this after some of the INRIA
>>>folks "are trying to fit [MPR's] in because you have a 
>>>
>>special interest
>>
>>>in 
>>>MPRs", and just because some of us disagree with you, we're guilty of 
>>>"politics"?!?!?   ...sigh.... I shudder to think of what's 
>>>
>>coming next,
>>
>>>but 
>>>just in case, met me emphatically state for the record -- I like
>>>puppies!
>>>And it can be argued that it's a "natural extension" that I like
>>>kittens, too!     
>>>
>>>;)
>>>
>>>Stan
>>>
>>>
>>>>-----Original Message-----
>>>>From: Richard Ogier [mailto:[e-mail]] 
>>>>Sent: Monday, October 02, 2006 6:59 PM
>>>>To: Acee Lindem (acee)
>>>>Cc: [e-mail]
>>>>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
>>>>
>>>>Acee Lindem wrote:
>>>>
>>>>>Richard,
>>>>>
>>>>>I'd have to agree with Joel. Addiitonally, reaching 
>>>>>
>>consensus on the 
>>
>>>>>criteria
>>>>>and who has the mandate to make the decision may be as difficult as 
>>>>>agreeing
>>>>>on an approach.  So, we could bring in others, e.g. the 
>>>>>
>>>>routing ADs or 
>>>>
>>>>>members of the
>>>>>routing directorate, but this may not bring us any closer to 
>>>>>
>>>>concensus.
>>>>
>>>>>Thanks,
>>>>>Acee 
>>>>>
>>>>Acee,
>>>>
>>>>In that case, I am strongly opposed to having multiple drafts.
>>>>As Joe implied, this would just create another MANET WG scenario
>>>>which is what we were trying to avoid. Tom Henderson also said
>>>>
>>>>>I strongly believe it should be an agreed goal to avoid 
>>>>>
>>>>multiple draft
>>>>
>>>>>standards on this topic.
>>>>>
>>>>He also said
>>>>
>>>>>If the WG decides to adopt multiple experimental drafts, 
>>>>>
>>>>there should be
>>>>
>>>>>some criteria defined for making technical progress in the 
>>>>>
>>>>evaluation,
>>>>
>>>>>so we do not come to the end and have the results and whole 
>>>>>
>>>>methodology
>>>>
>>>>>questioned once again. 
>>>>>
>>>>So, several of us seem to be opposed to going with multiple drafts
>>>>(although I will let the others speak for themselves).
>>>>
>>>>I was hoping that the WG would want to standardize the best possible
>>>>extension of OSPF.  But from what Joel is saying, Cisco could pay
>>>>several people to implement their solution, and it would be adopted
>>>>as the standard regardless of how good the solution is?
>>>>If this is how things will be decided, then I would not want to
>>>>waste my time.  I.e., if we go with multiple drafts and have no
>>>>criteria, then I am not sure I would want to participate.
>>>>
>>>>So I guess that leaves alternatives 1, 2, and 4 in your 
>>>>
>>previous email.
>>
>>>>I think the best approach is to try to find a team of 3 unbiased
>>>>judges, possibly including one or both ADs, and give the teams a few
>>>>months to come up with a draft, a position paper, and data to support
>>>>their solution (alternative 3).
>>>>
>>>>Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Joel M. Halpern wrote:
>>>>>
>>>>>>Why must the teams agree on a methodology?
>>>>>>The point of experimental publication is to get the 
>>>>>>
>>definitions out 
>>
>>>>>>there so that people can implement and use them.
>>>>>>If it does not get used, then there is no need to move anything to 
>>>>>>Proposed Standard.
>>>>>>If one gets used, and the others do not, then that one ends 
>>>>>>
>>>>up on the 
>>>>
>>>>>>standards track.  Probably with improvements from the 
>>>>>>
>>>>implementation 
>>>>
>>>>>>and deployment experience.
>>>>>>If several get implemented and deployed, then we hope to 
>>>>>>
>>>>learn things 
>>>>
>>>>>>from that deployment.  We may discover that factors that never 
>>>>>
>>>>>>occurred to the working group will turn out to be 
>>>>>>
>>>>important.  It may 
>>>>
>>>>>>be that factors the working group thought important turn out to be 
>>>>>>irrelevant.
>>>>>>
>>>>>>The IETF has almost never agreed on criteria for moving from 
>>>>>>experimental to proposed standard, other than "lets see 
>>>>>>
>>>>what happens."
>>>>
>>>>>>And I would be amazed at the IETF giving significant weight to 
>>>>>>simulation experience for that transition.
>>>>>>
>>>>>>Yours,
>>>>>>Joel M. Halpern
>>>>>>
>>>>>>PS: When this has been done in the past, it has been with the view 
>>>>>>that it was intended to get real world deployment experience.  And 
>>>>>>that such experience was what mattered for any possible 
>>>>>>
>>>>eventual move 
>>>>
>>>>>>from experimental to standards track status.
>>>>>
>>>>>>At 03:50 PM 10/2/2006, Richard Ogier wrote:
>>>>>>
>>>>>>>I think that if we decide to go forward with multiple experimental
>>>>>>>drafts, then we MUST first agree on a methodology for 
>>>>>>>
>>comparing the
>>
>>>>>>>proposals, and all participants MUST agree to cooperate with this
>>>>>>>methodology.  (E.g., if one team refuses to implement 
>>>>>>>
>>>>their solution
>>>>
>>>>>>>in GTNetS, then they will be disqualified.)
>>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Ospf-manet mailing list
>>>>>>[e-mail]
>>>>>>https://www1.ietf.org/mailman/listinfo/ospf-manet
>>>>>>
>>>>
>>>>_______________________________________________
>>>>Ospf-manet mailing list
>>>>[e-mail]
>>>>https://www1.ietf.org/mailman/listinfo/ospf-manet
>>>>
>>>
>
>



_______________________________________________
Ospf-manet mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-manet