Subject: Zone transfer

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jan 2001 11:01:22 -0500

Is there a way to still do zone-transfers? No, I don't want .com, just
.edu. None of the root servers seem to allow it.

Thanks.

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Jan 2001 08:17:13 -0800

> .edu. None of the root servers seem to allow it.

from rfc 2780

   2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
       queries from clients other than other root servers.  This
       restriction is intended to, among other things, prevent
       unnecessary load on the root servers as advice has been heard
       such as "To avoid having a corruptible cache, make your server a
       stealth secondary for the root zone."  The root servers MAY put
       the root zone up for ftp or other access on one or more less
       critical servers.

---

From: [email-masked]
Date: Fri, 12 Jan 2001 09:06:14 -0800 (PST)

ftp://rs.internic.net/domain/ has a reasonably current zone for edu,
as a gzipped file.  Note that the README file for the ftp site is
seriously out of date.
			regards,
				Ted Hardie

---

From: "Hung Pham" <[email-masked]>
Date: Fri, 12 Jan 2001 13:25:09 -0500

Hello;

I'm interested in the "TCP for Transaction or  T/TCP" protocol,
basically this protocol collapses the TCP three way handshake to a
single 
message to reduce latency overhead.
 
I've searched the IETF Internet-Drafts and IETF Working Groups but still
could not find any information about it.  

Does anyone know where I can find such information ?

Thanks for your help.

---

From: Garrett Wollman <[email-masked]>
Date: Fri, 12 Jan 2001 14:49:26 -0500 (EST)

> could not find any information about it.  

It was described in RFC 1644 (by Bob Braden IIRC) and in W. Richard
Stevens' book, _TCP/IP Illustrated, Volume 3_.  It is implemented (but
turned off by default for security reasons) in FreeBSD; I am not aware
of any other operating system which currently ships with it.

The API introduced by Bob Braden's patches to SunOS and carried
forward into FreeBSD has proved useful even where T/TCP is disabled.

-GAWollman

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 12 Jan 2001 20:25:39 +0000 (GMT)

On Fri, 12 Jan 2001, Hung Pham wrote:

> basically this protocol collapses the TCP three way handshake 

five-way, if you remember the two at the _end_ of the connection...

> to a single message to reduce latency overhead.

while increasing processing load and opening the door further to
effective denial-of-service attacks, since buffers must be allocated
for data immediately by the receiver before the sender is verified.

> Does anyone know where I can find such information ?

http://www.amazon.com/exec/obidos/ASIN/0201634953

Stevens volume 3.

RFC1644. http://www.normos.org/ietf/rfc/rfc1644.txt

normos's search engine has improved lately, btw.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Fred Baker <[email-masked]>
Date: Sat, 13 Jan 2001 08:58:05 +0800

At 08:17 AM 1/12/01 -0800, Randy Bush wrote:
>   The root servers MAY put

not that I plan to do it, but is there such an FTP site?

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jan 2001 20:47:40 -0500

ftp://rs.internic.net/domain/ was provided and seems to be current.
com/net/org zones apparently require a license, but the commercially
unattractive edu/mil/etc. are there.

---

From: "Martin J. Duerst" <[email-masked]>
Date: Mon, 15 Jan 2001 09:37:04 +0900

The IETF (anounce) mailing list archive has several problems
that should be fixed:

- The most recent page is
   http://www.ietf.org/mail-archive/ietf-announce/Current/maillist.html
   older pages are
   http://www.ietf.org/mail-archive/ietf-announce/Current/mail2.html
   http://www.ietf.org/mail-archive/ietf-announce/Current/mail3.html
   and so on. If the numbers change every time a new page is
   added, this breaks all URIs. JUST DON'T DO THIS, please!

- The oldest page in the announce archive is currently
   http://www.ietf.org/mail-archive/ietf-announce/Current/mail434.html
   I'm sure older archives are available. If they cannot be made
   available in the same form, then there should at least somewhere
   be a pointer to older archives. Otherwise, a small note saying
   that the list was created in March 1998.

- The 'previous page'/'next page' links go in the opposite direction
   of what one would expect (next goes to the past, previous to the
   future).

- The discussion list is arbitrarily split in Oct. 1998.
   http://www.ietf.org/mail-archive/ietf/Pre_Oct_1998/maillist.html

- The discussion list archive starts in Feb 1998. I'm sure the
   list existed before.
   http://www.ietf.org/mail-archive/ietf/Pre_Oct_1998/mail136.html

Many thanks in advance for fixing these problems,

Regards,   Martin.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 14 Jan 2001 20:36:47 -0500

I suggest trying ftp to <ftp://ftp.ietf.org/ietf-mail-archive/ietf> or
<ftp://ftp.ietf.org/ietf-mail-archive/ietf-announce>.  In general,
when looking for stuff at organizations that predate the web, trying
ftp is a good idea.

Donald

From:  "Martin J. Duerst" <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Mon, 15 Jan 2001 09:37:04 +0900
To:  [email-masked]
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
	     <[email-masked]>

---

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Mon, 15 Jan 2001 10:52:07 +0700

> when looking for stuff at organizations that predate the web, trying

Yet other alternate archives:

http://www.egroups.com/messages/ietf-announce
http://www.egroups.com/messages/ietf-last_call 
http://www.egroups.com/messages/ietf-protocol_action 
http://www.egroups.com/messages/ietf-document_action
http://www.egroups.com/messages/ietf-i-d_action 
http://www.egroups.com/messages/ietf-pre2000 
http://www.egroups.com/messages/ietf-rfc 
http://www.egroups.com/messages/ietf-wg_action 
http://www.egroups.com/messages/ietf-wg_review 

regards,

-- 
Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org
--- Aku ini si gembala sapi... oie... http://sapi.vlsm.org

---

From: Mohsen BANAN-Public <[email-masked]>
Date: Mon, 15 Jan 2001 11:28:05 -0800 (PST)

>>>>> On Fri, 12 Jan 2001 13:25:09 -0500, "Hung Pham" <[email-masked]> said:
>>>>> On Fri, 12 Jan 2001 20:25:39 +0000 (GMT), Lloyd Wood <[email-masked]> said:

  Hung> Hello;
  Hung> I'm interested in the "TCP for Transaction or  T/TCP" protocol,
  Hung> basically this protocol collapses the TCP three way handshake to a

  Lloyd> five-way, if you remember the two at the _end_ of the connection...

  Hung> single message to reduce latency overhead.
 
  Lloyd> while increasing processing load and opening the door further to
  Lloyd> effective denial-of-service attacks, since buffers must be allocated
  Lloyd> for data immediately by the receiver before the sender is verified.

The problem domain which T/TCP attempts to address is clearly valid.

However, I agree that T/TCP's approach of being bundled with
TCP is not effective and pragmatic.

There are various other protocols (including ESRO -- RFC-2188)
which address the same problem space as T/TCP. A survey of
these protocols and my assessment of where they fail is
included in the article:

   ESRO: A Foundation for the Development of Efficient Protocols
   =============================================================

available through:

 http://www.leapforum.org/LEAP/Manifesto/article/ESROcomponent/one/index.html

The segment related to mention of other protocols in the
reliable RPC (transactions / reliable connectionless
transports) problem space is reproduced below in plain text
format.

Those interested in further discussing this topic are invited
to join the relevant mainling lists at 
	
        http://www.esro.org/
and 
        http://www.leapforum.org/

...Mohsen.

------

2  Other Related Protocols
==========================

The overall model of ESRO is similar to and consistent with
many existing protocols.  The distinguishing characteristic
of ESRO is its efficiency.  Also, the scope of ESRO is very
narrow and well defined.  The options and selections that
it provides for are few and clear.

A brief comparison of ESRO to other similar protocols is
provided in the sections below.

2.1  RPC
--------

Remote Procedure Call (RPC) is specified in RFC-1831 [24]
and RFC-1833 [23].

The RPC specifications define a remote procedure model that
is essentially the same as ESRO. However, the notation of
RPC uses a syntax which is quite different from that of
ESRO. RPC can rely on a connection-oriented or a
connectionless transport mechanism.  When using the
connectionless mechanism, the retransmission and
reliability issues are considered to be beyond the scope of
the RPC specification.  RPC is usually used in combination
with External Data Representation, XDR (RFC-1832) [25].
When using RPC over UDP, no meaningful reliable transport
mechanism is defined.  For this reason use of RPC over UDP
has been limited to LANs.

2.2  ROSE
---------

Remote Operations Services Element (ROSE) is specified in
[7] and [8].  ROSE is a complete and heavyweight
traditional OSI application which assumes availability of
all of the underlying OSI layers.  The ESRO protocols can
accomplish short operations with much less overhead than
ROSE.

2.3  WAP's WTP
--------------

The Wireless Appliction Protocol (WAP) includes a layer
which is similar to ESRO, called ``Wireless Transaction
Protocol'' (WTP) [1].  The WTP specification was published
after ESRO was published, and is similar in functionality
to ESRO. In many ways WTP can be considered to be patterned
after ESRO; however, WTP is in fact a step backwards.

The clear and simple Remote Operations model of ESRO is
renamed as ``Wireless Transactions'' in an inappropriate
context.  The notation specification conventions are not
used, and the state machines are not as robust.

More importantly, the WTP specifications are not stable,
have not been published as Internet RFCs, and have not been
declared to be patent free.

As early as 1995, those involved in the development of WTP
were made aware of LSROS and ESRO. The only reason we know
of for their re-specification of WTP, rather than re-use of
ESRO, is the WAP Forum's desire for control.  More details
on the problems of the WAP Forum's approach are provided in
the article The WAP Trap [18].

2.4  T/TCP
----------

Transaction/TCP is specified in [5] and [6].  T/TCP is a
backwards-compatible extension of TCP which provides
efficient transaction-oriented service in addition to
virtual-circuit service.  Use of T/TCP often involves
replacing existing TCP implementations.  This
non-evolutionary aspect of T/TCP is one of the reasons why
T/TCP has not been widely adopted.

Various lessons can be learned from why T/TCP has not been
widely adopted.

2.5  RDP
--------

Reliable Data Protocol (RDP) is specified in [11] and [10].
RDP can be considered to be a specialized TCP, specified
for particular circumstances in which some of TCP's
facilities are needed.  One of the reasons why RDP has not
been heavily used is because the set of specialized
circumstances that it addresses do not justify the cost of
implementing it.  RDP allows for many options and
selections, which makes its use difficult.

Various lessons can be learned from why RTP has not been
widely adopted.

2.6  VMTP
---------

Versatile Message Transaction Protocol (VMTP) is specified
in [9].  VMTP can be considered to be a specialized
transport protocol, targeted for what it calls the
transaction model of communications.

One of the reasons why VMTP has not been heavily used is
because it tries to address too broad of a software
engineering-centric model.  VMTP allows for many options
and selections, which makes its use difficult.

Various lessons can be learned from why VMTP has not been widely adopted.

2.7  TCP
--------

Transmission Control Protocol (TCP) is specified in [22]
and [6].  TCP is mature, well understood and stable.
Congenstion control and flow control mechanisms for TCP
have been developed over the years, and incorporated into
TCP implementations.

The simplest and shortest TCP interaction involves 5 PDU exchanges.  For
applications wishing to accomplish short and occasional communications in
less than 5 PDU exchanges, ESRO is more efficient that TCP.

2.8  UDP
--------

UDP (User Datagram Protocol) is specified in [21].

UDP is a very simple and thin layer on top of IP, which
does not provide reliability or sequence ordering.
Applications requiring a reliable connectionless transport
need to build on top of UDP. ESRO provide an efficient and
reliable transport service on top of UDP.

2.9  UDP Plus Ad Hoc Re-Transmissions
-------------------------------------

Various protocols have added their own specific
re-transmission policies on top of UDP to make it more
reliable.  Examples of such efforts include the Domain Name
System (DNS) [13] [14], Network Time Protocol (NTP) [12],
and NNTP for Usenet News Reading.

These efforts have all resulted in incomplete and limited
solutions.  The problems with such approaches were
understood as early as 1985 [4].

References
==========

 [1] WAP Wireless Transaction Protocol Specification, February 2000. The
     WAP-201-WTP article available at
     http://www.wapforum.org/what/technical.htm.

 [2] M. Banan. Neda's Efficient Mail Submission and Delivery (EMSD)
     Protocol Specification Version 1.3. Request for Comments
     (Informational) 2524, Neda Communications, Inc., February 1999. Online
     document is available at ftp://ftp.isi.edu/in-notes/rfc2524.txt.

 [3] M. Banan, J. Cheng, and M. Taylor. AT&T/Neda's Efficient Short Remote
     Operations (ESRO) Protocol Specification Version 1.2. Request for
     Comments (Informational) 2188, Neda Communications, Inc., September
     1997. Online document is available at
     ftp://ftp.isi.edu/in-notes/rfc2188.txt.

 [4] B. Braden. Towards a transport service for transaction processing
     applications. RFC 955, Internet Engineering Task Force, September
     1985.

 [5] B. Braden. Extending TCP for transactions -- concepts. Request for
     Comments (Informational) 1379, Internet Engineering Task Force,
     November 1992.

 [6] B. Braden. T/TCP -- TCP extensions for transactions functional
     specification. Request for Comments (Experimental) 1644, Internet
     Engineering Task Force, July 1994.

 [7] Remote Operations:  Model, Notation and Service Definition. The
     International Telegraph and Telephone Consultative Committee, March
     1988. Recommendation X.219.

 [8] Remote Operations:  Protocol Specification. The International
     Telegraph and Telephone Consultative Committee, March 1988.
     Recommendation X.229.

 [9] D. Cheriton. VMTP: versatile message transaction protocol:  Protocol
     specification. Request for Comments (Experimental) 1045, Internet
     Engineering Task Force, February 1988.

[10] B. Hinden and C. Partridge. Version 2 of the reliable data protocol
     (RDP). Request for Comments (Experimental) 1151, Internet Engineering
     Task Force, April 1990.

[11] B. Hinden and J. Sax. Reliable data protocol. Request for Comments
     (Experimental) 908, Internet Engineering Task Force, July 1984.
     (Updated by RFC1151).

[12] D. Mills. Network time protocol (v3). Request for Comments (Draft
     Standard) 1305, Internet Engineering Task Force, April 1992.
     (Obsoletes RFC1119).

[13] P. Mockapetris. Domain names - concepts and facilities. Request for
     Comments (Standard) STD 13, 1034, Internet Engineering Task Force,
     November 1987. (Obsoletes RFC882); (Obsoletes RFC883); (Obsoletes
     RFC973); (Obsoleted by RFC2065); (Updated by RFC1101); (Updated by
     RFC1876); (Updated by RFC1982); (Updated by RFC2181); (Updated by
     RFC2308).

[14] P. Mockapetris. Domain names - implementation and specification.
     Request for Comments (Standard) STD 13, 1035, Internet Engineering Task
     Force, November 1987. (Obsoletes RFC973); (Obsoleted by RFC2136);
     (Obsoleted by RFC2137); (Updated by RFC1348); (Updated by RFC1995);
     (Updated by RFC1996); (Updated by RFC2065); (Updated by RFC2181);
     (Updated by RFC2308).

[15] Mohsen Banan. Efficiency Study of EMSD vs. SMTP/POP3/IMAP. Neda
     Published Document 103-101-01.01, EMSD Organization, 1996. Online
     document is available at
     http://www.emsd.org/pubs/biblio/103-101-01_01/index.html.

[16] Mohsen Banan. ESROS Application Programming Interface. Neda Published
     Document 103-101-06.03, ESRO Organization, 1996. Online document is
     available at http://www.esro.org/pubs/biblio/103-101-06_03/index.html.

[17] Mohsen Banan. Lightweight & Efficient Application Protocol (LEAP)
     Manifesto. FPF Published Document 108-101-01, Free Protocols
     Foundation, Bellevue, WA, January 2000. Online document is available
     at  http://www.freeprotocols.org/pubs/biblio/108-101-01/index.html.

[18] Mohsen Banan. The WAP Trap. FPF Published Document 108-102-01, Free
     Protocols Foundation, Bellevue, WA, January 2000. Online document is
     available at
     http://www.freeprotocols.org/pubs/biblio/108-102-01/index.html.

[19] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, and N. Vaidya. Long
     Thin Networks. Request for Comments (Informational) 2757, The Internet
     Society, January 2000. Online document is available at
     ftp://ftp.isi.edu/in-notes/rfc2757.txt.

[20] Information Processing Systems --- Open Systems Interconnection:  Basic
     Reference Model. International Organization for Standardization and
     International Electrotechnical Committee, 1984. Interational Standard
     7498.

[21] J. Postel. User datagram protocol. Request for Comments (Standard) STD
     6, 768, Internet Engineering Task Force, August 1980.

[22] J. Postel. Transmission control protocol. Request for Comments
     (Standard) STD 7, 793, Internet Engineering Task Force, September 1981.
     (Obsoletes RFC761).

[23] R. Srinivasan. Binding protocols for ONC RPC version 2. Request for
     Comments (Proposed Standard) 1833, Internet Engineering Task Force,
     August 1995.

[24] R. Srinivasan. RPC: remote procedure call protocol specification
     version 2. Request for Comments (Proposed Standard) 1831, Internet
     Engineering Task Force, August 1995.

[25] R. Srinivasan. XDR: external data representation standard. Request for
     Comments (Proposed Standard) 1832, Internet Engineering Task Force,
     August 1995.