TUBA meeting 1: the minutes

[Mark Knopper <[e-mail]>]

Hi. Here are the proposed minutes. 
	Mark

TUBA minutes -- July 14, 1993
-----------------------------

John Scudder
------------

Summary:
0. Tasks (Summarized from Sections 1 & 2)
1. Documents to be moved to Proposed Standard or Informational
2. To-do list
3. Presentations

-----
0. Tasks (Summarized from Sections 1 & 2):

	- Piscitello and Carpenter to present draft-ietf-tuba-sysids-01.txt
	  to ATM Forum.

	- Callon to edit RFC 1237 (NSAP Allocation Guidelines) and send a
	  note to the mailing list, before next IETF.

	- Colella and Manning to edit TUBA DNS I-D for next IETF.

	- 957x to be translated to ASCII text.  (Knopper to work on doing
	  this, Chapin/Rekhter/Piscitello to provide raw dox.)

	- Piscitello changing 9542 to ASCII, Chapin 8473, Kunzinger has done
	  10747. IS-IS and 957x need to be done.  All will be proposed as
	  Proposed Standards and made available both in text and as
	  PostScript.

	- Ford and Curran to write transition document and notify mailing
	  list before next IETF.

	- Katz to edit EON RFC and offer as Proposed Standard.

	- Scudder to try out BSD/386 EON.

	- Callon was requested to write a paper on address translation and
	  publish it as an Internet Draft.

	- Knopper has an outstanding item to write TUBA FAQ.
	
-----
1. Documents to be moved to Proposed Standard or Informational:

   a. 	CLNP for TUBA [draft-ietf-tuba-clnp-03.txt]:
	Will be presented to AD to be moved to Proposed Standard.
   
   b.	Sysids [draft-ietf-tuba-sysids-01.txt]:
		   
	Present to AD to be moved to Proposed Standard.  This is already how
	OSI hosts at Merit are addressed.
	   
	Suggestion to present this to ATM Forum -- Piscatello and Carpenter
	to pursue this off-line.
	   
   c.	NSAP Allocation Guidelines [RFC 1237] :
	Currently a Proposed Standard.  Callon suggests that it needs
	editing (and volunteers to do it, too).  Callon to edit, place in
	tuba-docs directory on merit.edu and send a notice to mailing list
	(maybe to noop list too).

	RFC 1237 to be presented to be moved to Draft Standard after
	editing.  Before next IETF.
   
   d.	FUBAR (FTP and UDP with Bigger AddResses):
	[draft-piscitello-ftp-bigports-01.txt, tuba-only version]:
	
	There are said to exist TUBA and TP/IX implementations of FUBAR.
		
	There was quite a bit of discussion about problems with FOOBAR and
	TUBA translating gateways.  
	
	Some editing is needed on the document:  Five-letter commands need to
	be changed to four-letter, and various frivoloties need to be elided.
	An appendix is to be written specifying use of FOOBAR for TUBA.

	In the spirit of compromise between problems with FOOBAR +
	translating gateways and the need for some spec for big address
	FTP, agreement to move for Experimental status now, to be reviewed
	next IETF and moved to P-S.

   e.	DNS forward lookup (name->NSAP lookup):  There is a doc for f/w lookup
	only, no inverse lookup.

	RFC 1238 needs to expire and go to historical, since reverse lookup
	is "broken."  Inverse lookup has been implemented but is real slow.
	(Manning)  There is a new I-D that does not include reverse lookup.
	Colella and Manning to edit the I-D for next time, 1238 to be left
	in place for now.

	DNS guru volunteer is needed.  Colella interested in working with
	same.

	To be discussed in Wednesday's DNS meeting. 
   
   f. 	Routing and Addressing Architecture -- there is already such an 
	architecture published in ISO 957x (Piscitello or Katz may know the
	real number).

	957x to be translated to ASCII text.  (Knopper to work on doing
	this, Chapin/Rekhter/Piscitello to provide raw dox.)

	Piscitello changing 9542 to ASCII, Chapin 8473, Kunzinger has done
	10747. IS-IS and 957x need to be done.  All will be proposed as
	Proposed Standards and made available both in text and as PostScript.

	Reminder:  Relevant ISO docs are available (in PostScript) for anon
	FTP from merit.edu.

   g.	EON to be proposed for Proposed Standard -- see below, item 2.b.
	   
-----
2. To-do list

   a.	DNS inverse lookup:  See above
	
   b.	Transition plan:  To be discussed next meeting.  Some anxiousness
   	expressed that the plan is really important to finish well before
   	next IETF.
   
	Peter and John Curran working on transition plan but haven't done it
	yet.  
   
	Real rough transition outline:
	   
	   	Dual stacked hosts
	   	CLNP in routers
	   	CLNP over IP infrastructure
	   	IP over CLNP infrastructure
	   
	This segued into a discussion of the existing infrastructure, which
	led to discussion of EON:  The EON RFC (RFC 1070) is still in
	Experimental status.  Some discussion of whether changes to EON are
	needed (or worthwhile). Katz volunteered to edit it and offer it as
	a Proposed Standard.  Scudder to try out EON in BSD/386.

	It might also be useful to have an IP in CLNP tunneling docs.
	
   c.	Mobile hosts:  Rekhter comments:  "TUBA will adopt whatever the 
	Internet community decides on for IP."  
	
   d.	Formulate RFC 1380 responses.

   e.	WGs we have/want liason with:  DNS, FTP, ATM, RARE, NOOP.  Also any
   	WGs arising from the OSI BOF.

-----
3. Presentations
   
   a.	Autoconfiguration a la DEC:  (Chris Gunner)
	
	NSAP struct:  

		|-Area Addr---------|-ID-------|-SEL-|
		 <----n octets-----> <-6 oct--> <-1->
	   		
	- Routers are configged (by hand) w/ Area Addrs
	- End systems "know" their IDs (e.g. MAC addr) and "know" SEL(s)
	- Routers send IS hellos (ISO 9542) with NET (NSAP)
	- End Systems receive IS Hello and:
		- Extract Area Addr
		- Create NSAP(s) -- Area Address + ID + SEL(s)
	  	- Send ES Hello(s) with NSAP(s)
	   		
	(Migration to new area addrs said to be pretty easy since an ES can
	have both an "old area" and a "new area" NSAP.)
   
	- Named objects, e.g. "node" (system) may have protocol "stack" 
	  attribute information, e.g.:  (in DEC DNS)
	     
		+---------------+     +-------------+
		| Upper Layers  | ==> | SNMP        |
		| CLNP, NSAP(s) |     | UDP, Port # |
		+---------------+     | CLNP, NSAPs |
				      +-------------+
		 					   
	- When an end system's NSAP(s) change:
		- Update naming service entry for objects for that system
	   	- requires name service protocol to do update
	   	- system needs to have write access to these objects
	   			
	(This is basically a way for ES to update the DNS automatically when
	addrs change.  There was some concern of how to do this in regular
	ol' DNS -- Rekhter comments, "when standard IP DNS knows how to do
	this, TUBA will adopt it unchanged.")
   			
	- Issues:
		- Frequency of updates
		- Update failure -- e.g. no write access -- requires manual 
		  DNS override ability
		- System state information about interaction with name 
		  service (transient failures)
		 					   
   b.	Multicast:  (Dave Katz)
	 
	- Group NSAP addresses hack
		- Paralell AFI space (10-99 --> A0-F9) (since AFI is in BCD)
			- Sytactically distinct but paralell space
			- Hierarchy possible (unlike IP multicast space)
	- CLNP
		- MD PDU (MD = Multicast Data)
			- Distinct from DT PDU
		- Scope control options?  ("I want this packet to go only this
		  many administrative hops")
	- ES-IS
		- NSAP->SNPA dynamic binding
		- Group membership announcement
		- Extra unicast hop -- if you want to send multicast, you 
		  unicast your packet to an IS which then forwards it 
		  appropriately.  You never get a redirect to start multicasting 
		  on the LAN.
	- IS-IS
		- Could be changed to be MOSPF-like
		- No active work
	- IDRP
		- No work yet
	- For more information see OSI extensions for use in the Internet BOF
	
   c.	ES-IS address administration (Dave Katz)
	
	See ES-IS 2nd Ed. PostScript file on merit.edu.
	
	ES				IS
	--------			--------
	"who am I?"	--->
	(to ask for an
	address)
				<---	"You are foo" (for 18 hours)
				<---	"You are bar"
					(offers some addresses, guaranteed
					to be reserved for ES for holding
					timer duration)
	"I am bar" (ESH) --->
	(to notify IS of
	who ES has decided
	to be, incl holding
	time of up to 18 
	hours)

	Issues:
		- May not want really automatic assignment (security concerns)
		- IS doesn't know some host info (e.g., IP address) -- might 
		  be nice to provide this input to construct the NSAP 
		  (or MAC addr, other host-specific info).
		- How can we deny service to undesired hosts?  (e.g., send ES 
		  a bogus address to "shut him up".