Subject: note sent to RSVP group

From: Craig Partridge <[email-masked]>
Date: Tue, 13 Aug 96 16:09:42 -0700

Thought folks might like to see this too.

Craig

E-mail: [email-masked] or [email-masked]

------- Forwarded Message

Date: Tue, 13 Aug 96 13:05:29 PDT
From: [email-masked]
Posted-Date: Tue, 13 Aug 96 13:05:29 PDT
To: [email-masked]
Subject: what's going on...
Cc: [email-masked]
Sender: [email-masked]

Hi,

You may be wondering what's going on with the RSVP spec.  We agreed at
the last IETF meeting that it should go to Proposed Standard ASAP.
What's holding it up, you ask?

Towards the end of the Montreal meeting, a plan was hatched by the
chairs of RSVP and int-serv to make a coordinated submission of RSVP,
with the int-serv specs, since both WGs were at the same point.  Some
of the more foolishly optimistic people involved talked about getting
it done within 3 weeks after the meeting.

There was one problem, which was also an opportunity.  John Wroclawski,
in particular, was concerned that we had defined RSVP, and int-serv had
defined service models, but there were some nagging uncertainties
about how they fitted together.  So he volunteered to write a document
specifying how to use RSVP with integrated services.  In two weeks.
(Hah!)

Actually, he *has* written, and revised, and revised, such a document,
and hopefully it will soon be published.  As we suspected, it was a
very worthwhile exercise that has resulted in clearing up several of
the nagging interface issues and simplifying several aspects of the
encoding.  His document is a substantial step forward, and it will be
very helpful for implementors.

All that is preliminary to explaining about RSVP ID13, which I just
submitted for posting.  It contains changes from ID12 in three areas:

1. Alignment with Wroclawski's RSVP usage document:

    a. A little bit of editorial work was done in the introduction
	to reference the RSVP usage document and other int-serv documents

    b. The Non-RSVP-hop flag has moved into the ADSPEC, so the two
       flags Non-RSVP and Maybe-RSVP were removed from the SESSION object.
       The TC_Advertise call to traffic control was changed so that RSVP can
       pass a Non-RSVP flag if it has one.

    c. The Adspec is now considered end-to-end, so there is now
       an additional parameter to Sender call in the API, allowing a
       sending application to optionally pass an ADSPEC to RSVP.

2. As I discussed at Montreal, an RSVP HOP object has been added to the
   ResvErr message.

3. Yesterday I sent out a message about detailed fixes to the Message
   Processing Rules section; these have been incorporated.

Bob Braden

------- End of Forwarded Message