Subject: (ngtrans) NGTRANS "BOUND" Matrix Parts from IETF 44

From: Jim Bound <[email-masked]>
Date: Thu, 25 Mar 1999 11:11:27 -0500

Bob asked me to send this.  This is not cast in stone and was only my
attempt to get the cells started for the matrix and input to the Roadmap
Team (which I am on).

I think in my opinion these parts should be specified in all transition
specs.

Matrix Parts:

Columns are solutions and Rows are parts.
Transition Assumptions how users will deploy IPv6.
Evolution Assumptions of IPv6 and Transition.
IPv6 deployed at edge or core.
Site supports IPv4 and IPv6 or just IPv6.
Platform supports IPv6 ONLY, IPv4 ONLY, or BOTH.
Whether IPv6 is dominant in the site.
IPv4 Global Addresses Required in the part.
IPv4 Pool of Global Addresses Required in the part.
Are implementation defined parts discussed and with examples.
What parts are Required, Optional in the mechanism, this must be very
clear.
How is the part managed.
Is the part a Protocol or Pure Mechanism.
Flow Chart of the mechanism provided.
Is new software required on IPv4 ONLY systems.
Is new software Required in platform user space.
Is new software Required in platform kernel space.
Is there an OS context switch because of the part.
What are the performance implications of each part.
What are the business costs of the part to a user.
What are the DNS assumptions and dependencies.
How are the parts retired and garbage collected when
not needed, is it creating a legacy problem in software.
How are IPv4 addresses assigned to IPv6/IPv4 hosts.
Is translation required.
Is tunneling required.
What are the affects to IPsec.
What are the affects to Renumbering.
Is static configuration Required and where.
Is dynamic configuration Required and where.
Where are configuration parameters learned.
Are specialized APIs Required.

/jim