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

"Joel M. Halpern" <joel@stevecrocker.com> Mon, 02 October 2006 20:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUPY-0007c5-Q3; Mon, 02 Oct 2006 16:29:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUPX-0007by-AH for ospf-manet@ietf.org; Mon, 02 Oct 2006 16:29:11 -0400
Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUUPW-00034v-2O for ospf-manet@ietf.org; Mon, 02 Oct 2006 16:29:11 -0400
Received: from [71.161.34.244] (helo=JMHLap3.stevecrocker.com) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GUUPV-00054f-GT; Mon, 02 Oct 2006 16:29:09 -0400
Message-Id: <7.0.1.0.0.20061002162346.036b1f10@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 02 Oct 2006 16:29:04 -0400
To: Richard Ogier <rich.ogier@earthlink.net>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
In-Reply-To: <45216D6C.7020401@earthlink.net>
References: <E1GUPOB-0000FA-SD@megatron.ietf.org> <6.2.3.4.2.20061002125614.036ec290@mailserver.opnet.com> <45214EB8.5030605@cisco.com> <45216D6C.7020401@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120fe5f52ac02aa33cb86366e701bb0c28c71a773784d65292b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 71.161.34.244
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: ospf-manet@ietf.org
X-BeenThere: ospf-manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions of OSPFv3 extensions supporting MANET <ospf-manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf-manet>
List-Post: <mailto:ospf-manet@ietf.org>
List-Help: <mailto:ospf-manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=subscribe>
Errors-To: ospf-manet-bounces@ietf.org

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
Ospf-manet@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-manet