Subject: Question on sender descriptor

From: Bob Braden <[email-masked]>
Date: Thu, 2 Dec 1999 17:44:29 GMT

----- Begin Included Message -----

---

From: Masanobu Yuhara <[email-masked]>
Date: Mon, 06 Dec 1999 17:18:51 +0900

See below.

==============================================================
Date: Tue, 5 Nov 96 11:32:44 PST
From: [email-masked]
To: [email-masked]
Subject: New version of RSVP spec
Cc: [email-masked], [email-masked], [email-masked]

Hello.  Version ID13 of the RSVP spec was submitted to the Area
Director for Transport, Allison Mankin, early in September.  She
later came back with some requests for cosmetic changes to the
RSVP spec.

I have made these changes, which are listed later, resulting in
TWO new Internet Draft drafts:

	ftp://www.isi.edu/rsvp/docs/draft-ietf-rsvp-spec-14.ps, .txt

	ftp://www.isi.edu/rsvp/docs/draft-ietf-rsvp-procrules-00.ps, .txt

CHANGES IN ID14 VERSION OF RSVP SPEC

...(snip)...

3. <flow descriptor list> in Resv messages and <sender descriptor>
   in Path messages were made optional.  That is, empty Resv and Path
   messages are now (syntactically) legal.

   This change was made to meet a problem raised by the Area Director.
   The IETF rules require that a protocol spec be logically complete.
   That sounds reasonable, right?  But Resv and Path messages currently
   require flowspec, Tspec, and Adspec objects, which are opaque to
   RSVP but defined in int-serv documents.  Hence, the current RSVP
   spec is not logically complete.

   Our solution to this dilemma was change the RSVP spec to allow empty
   messages.  That is, empty RSVP messages are well-formed
   *syntactically*, although they seem to make little sense
   semantically.  If this feels uncomfortable to you, consider TCP.
   The TCP spec allows a TCP data packet to carry zero data bytes,
   although no reasonable implementation sends zero bytes except when
   it needs to send an ACK.  In the same way, no reasonable RSVP
   implementation will send an empty Resv or Path message, although
   they must be prepared to receive (and ignore) such messages (which
   is completely trivial to implement).

   OK, so it's a little wierd, but it solves the problem and lets us go
   forward.

.......

---

From: Maria Elena Villapol <[email-masked]>
Date: Tue, 07 Dec 1999 11:47:41 +1030

Hi

 Maria

--
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: [email-masked]
       [email-masked]

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm

---

From: Steven Berson <[email-masked]>
Date: Fri, 10 Dec 1999 12:57:29 -0800 (PST)

> >         ftp://www.isi.edu/rsvp/docs/draft-ietf-rsvp-spec-14.ps, .txt

Maria,

This version is out of date.  You should be using RFC2205 which is
available at (among other places):

		ftp://ftp.isi.edu/in-notes/rfc2205.txt

The current set of RSVP documents should always be available from:

		http://www.isi.edu/rsvp/pub.html

Steve
P.S.  Contact me privately if you REALLY are interested in revision 14 of
      the RSVP specification.