Re: IPv7 Selection Criteria
Noel Chiappa <jnc@ginger.lcs.mit.edu> Tue, 22 December 1992 21:18 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11202; 22 Dec 92 16:18 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11185; 22 Dec 92 16:18 EST
Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa22491; 22 Dec 92 16:20 EST
Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA15206; Tue, 22 Dec 92 16:13:49 -0500
Received: by ginger.lcs.mit.edu id AA17929; Tue, 22 Dec 92 16:13:31 -0500
Date: Tue, 22 Dec 1992 16:13:31 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9212222113.AA17929@ginger.lcs.mit.edu>
To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu
Subject: Re: IPv7 Selection Criteria
Cc: criteria@ftp.com, ericf@atc.boeing.com
<Catching up on mail....> >> * Last a long time (20 years). > I agree that it's hard to quantify the lifetime of an architecture. > However, don't you think that this is a critical goal. I.e. wouldn't you > agree we've failed if the thing we pick is obsolete in 5 years? Would you care to offer some examples of concrete tests that can be used to determine whether a spec satisfies this requirement? Perhaps you'd be happier if it said something like "maximizing the system lifetime" as opposed to putting a concrete number on it? I agree, it's hard to have a test. On the other hand, look at the possibility of failing to meet this goal: wouldn't you agree we've failed miserably if the thing we pick is obsolete in 5 years? Projected design lifetime, like robustness, is hard to measure concretely (for many of the same reasons, since to some degree it involves predicting the future), but again, I claim good engineers can do this. Just like you sort of get a feel for what is robust and what is not, you develop the same feel for what kind of design methodology leads to long-lived architectures: "clean design" and "flexibilty" are some things that lead to this. Doing a lot of thinking forward to future needs and possibilities (even if the mechanisms for doing them aren't completely specified in the current specification) is something else. For instance, is capability C met by adding a kludgy bag to the side of mechanism P, or have mechanisms P and Q been reorganized into X,Y, and Z, so that capability C is now provided in a natural and flexible fashion? That's the kind of thing you look for... Noel
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Scott_Brim
- Re: IPv7 Selection Criteria Noel Chiappa
- Re: IPv7 Selection Criteria Scott_Brim
- Re: IPv7 Selection Criteria Noel Chiappa
- Re: IPv7 Selection Criteria Noel Chiappa
- Re: IPv7 Selection Criteria Dave Crocker
- Re: IPv7 Selection Criteria Noel Chiappa
- Re: IPv7 Selection Criteria Dave Crocker
- Re: IPv7 Selection Criteria Noel Chiappa
- IPv7 Selection Criteria yakov
- Re: IPv7 Selection Criteria William Allen Simpson
- Re: IPv7 Selection Criteria Dave Crocker
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Frank Kastenholz
- Re: IPv7 Selection Criteria Noel Chiappa
- IPv7 Selection Criteria yakov