Penultimate TUBA Charter

[[e-mail]]

Hi. Since I am the chair I will try to appear chairpersonlike and
attempt to get the charter finalized. The following is a message
I sent to Peter a few days ago about the charter, and following
after that is a new draft, the Penultimate Tuba Charter, which is
my attempt at incorporating the comments I saw on the list from
Brian Carpenter, Dave Piscatello and Peter. Please comment and
we'll try to get this finalized soon.

I have set up an archive for the list, on merit.edu in the
directory pub/tuba-archive. All of the previous archive from
July to Sept 22 or so is in one file, and our archiving program
breaks things down into one file for each month after that.

I am not sure which Area this group fits into and I will try to
resolve this with various Area Placement Officials (APOs).

	Mark


========================

Peter,
  Here are some comments on the tuba charter. First some editorial
changes and such and then some questions.

- second paragraph, why not change "a large, global, multilateral
  public data network" to "the Internet". Seems a little less pretentious
  or redundant.

- later in that paragraph, should mention that TUBA will work with
  ANSI as well as ISO, RARE, etc.

- 2nd sentence in that paragraph, fix spelling of "interoperability".

- 3rd sentence, fix spelling of "IDRP-for-IP".


I don't think the overall scope of the charter is clear. I like the
idea of thinking very operationally (and I can contribute to that),
but we need to further discuss whether the entire internet routing
architecture for CLNP should be handled in this WG. It should be clear
that an important first step that can be separated from the larger
issue is whether the "packet format" will work, ie. using the
IP-ID method and standardizing how upper layer protocols will
need to be changed. It might be reasonable to define a multi-step
plan to first achieve basic interoperability and then introduce
more and more advance routing concepts to the whole plan.

Feel free to talk me out of any of this. 

	Mark
 


>>>>>>>>>>>>>>>>>>>>>>>>>> cut here <<<<<<<<<<<<<<<<<<<<<<<

TCP and UDP with Bigger Addresses  (tuba)

Charter 
 
Chair:
	Mark Knopper, Merit	[e-mail]

Deputy Chair:
	Peter Ford, LANL	[e-mail]

Internet Area Director(s):

     Philip Almquist <[e-mail]>
 
Mailing lists: 
     General Discussion: [e-mail]
     To Subscribe:       [e-mail]
     Archive:            merit.edu:pub/tuba-archive/		 

Description of Working Group:

The TUBA working group will work on extending the Internet Protocol
suite and architecture by increasing the number of end systems which
can be effectively addressed and routed.  The TUBA effort will expand
the ability to route Internet packets by using addresses which support
more hierarchy than the current Internet Protocol (IP) address space.
TUBA specifies the continued use of Internet Transport Protocols, in
particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets.
This will allow the continued use of Internet application protocols
such as FTP, SMTP, Telnet, etc." An enhancement to the current system
is mandatory due to the limitations of the current 32 bit IP
addresses.  TUBA seeks to upgrade the current system by a transition
from the use of the Internet Protocol version 4 to ISO/IEC 8473 (CLNP)
and the corresponding large Network Service Access Point address
space.


In addition to protocol layering issues and "proof of concept" work,
the TUBA approach will place significant emphasis on the  engineering
and operational requirements of a large, global, multilateral public
data network.  TUBA will work to  maximize interoperatability with  the
routing and addressing architecture of the global CLNP infrastructure.
The TUBA working group will work closely with the IETF NOOP and
IPRP-for-IP working groups to coordinate a viable CLNP based Internet
which supports the applications which Internet users depend on such as
Telnet, FTP, SMTP, NFS, X, etc.  The TUBA working group will also work
collaboratively with communities which are also using the CLNP
protocol, and will consider issues such as interoperability,
applications coexisting on top of multiple transports, and the
evolution of global public connectionless datagram networks, network
management and instrumentation using CLNP and TUBA, and impact on
routing architecture and protocols given the TUBA transition.

The TUBA working group will consider how the TUBA scheme will support
transition from the current IP address space to the future NSAP address
space without discontinuity of service, although different
manufacturers, service providers, and sites will make the transition at
different times. In particular, the way in which implementations
relying on current 32 bit IP addresses will migrate must be considered.
TUBA will ensure that IP addresses can be assigned, for as long as they
are used, independently of geographical and routing considerations. One
option is to embed IP addresses in NSAP addresses, possibly as the NSAP
end-system identifier. Whatever scheme is chosen must run in a majority
of *-GOSIPs and other NSAP spaces. The TUBA strategy will require a new
mapping in the DNS from NAMEs to NSAP addresses.

The rationale RFC (RFC-1347) documents issues of transition and
coexistence, among unmodified ``IP'' hosts and hosts which support
``TUBA'' hosts.  Hosts wishing full Internet connectivity will need to
support TUBA.  


Goals and Milestones: 
 
     RSN   Review and approve the charter 

     DONE  Post the initial TUBA rationale and discussion as a RFC, 
		Callon, RFC 1347.

     DONE  Post the initial TUBA DNS spec as a RFC, 
		Manning, RFC 1348.

     DONE  Post the initial profile of the use of CLNP for TUBA as an I-D,
		Piscitello.

     Oct 92 Post an initial "Routing and  Addressing" specification as 
    		 an Internet Draft, coordinate with NOOP and IDRP-for-IP.    
		 This may end up being a pointer to existing documents and
		 efforts.

   Nov 92 Post an overall report on TUBA in the Internetas an I-D.

   Nov 92 Present work of the TUBA working group to the IETF.                  


Additional Documentation Needed:

   Revision of RFC1347 to record what we have learned over the
   past months on tuba mailing list, ie. one that describes
   the addressing architecture, routing architecture, global
   effects of these on applications, specific effects on applications.

   CLNP for TUBA RFC covering the CLNP "profile" used in the TUBA
   Internet.

   Operations Plan document covering methodologies, instrumentation,
   address administration, routing coordination, etc.

   A set of documents covering changes to applications affected by
   the presence of TUBA, eg. the DNS document.