Skip to main content

Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
RFC 4860

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from tsvwg-chairs@ietf.org, flefauch@cisco.com, bdavie@cisco.com,pratik.bose@lmco.com,christou_chris@bah.com,davenport_michael@bah.com to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2007-05-08
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-05-08
05 Amy Vezza [Note]: 'RFC 4860' added by Amy Vezza
2007-05-04
05 (System) RFC published
2007-03-20
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-03-15
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2007-03-15
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-13
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-12
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-02-26
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-02-22
05 (System) IANA Action state changed to In Progress
2007-02-21
05 Amy Vezza IESG state changed to Approved-announcement sent
2007-02-21
05 Amy Vezza IESG has approved the document
2007-02-21
05 Amy Vezza Closed "Approve" ballot
2007-02-21
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-02-19
05 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2007-02-14
05 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2007-02-14
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-14
05 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-05.txt
2007-02-09
05 (System) Removed from agenda for telechat - 2007-02-08
2007-02-08
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-02-08
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-02-08
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-02-08
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-02-08
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2007-02-07
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-02-07
05 Sam Hartman
[Ballot discuss]
The security considerations section talks about the Kerberos RSVP key
exchange mechanism.  That would be a really great option.
Unfortunately it depends on …
[Ballot discuss]
The security considerations section talks about the Kerberos RSVP key
exchange mechanism.  That would be a really great option.
Unfortunately it depends on some details that were unspecified in RFC
1510
--the use of a ticket rather than an ap-req message, and
assumptions about what Kerberos session keys can be used for.  Sadly,
the RSVP community interpreted RFC 1510 one way and the Kerberos
community interpreted RFC 1510 another way, publishing RFC 4120.

It would be possible to write a new Kerberos identity option for RSVP
that worked with modern Kerberos, but I feel uncomfortable encouraging
people to use the existing option.  I'd like the text discussing
Kerberos to be removed.
2007-02-07
05 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2007-02-06
05 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2007-02-05
05 Lars Eggert [Ballot discuss]
* Downref: Informational Normative Reference: RFC 2209 (ref. 'RSVP-PROCESS')
2007-02-05
05 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2007-02-05
05 Russ Housley
[Ballot comment]
Typographical errors found by Charlie Kaufman during SecDir review:

  Page 4, fourth from bottom line:
  "discusses in details" -> "discusses in …
[Ballot comment]
Typographical errors found by Charlie Kaufman during SecDir review:

  Page 4, fourth from bottom line:
  "discusses in details" -> "discusses in detail"

  Page 25, third from bottom line:
  "andwidth" -> "Bandwidth"

  Page 27, 8th line:
  "mailto:" -> ""
2007-02-05
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-02-05
05 Dan Romascanu
[Ballot comment]
1. The Abstract Section includes citations to references to documents using the abbreviations specific to this documents. This is contrary to the recommended …
[Ballot comment]
1. The Abstract Section includes citations to references to documents using the abbreviations specific to this documents. This is contrary to the recommended practice that an Abstract section should be complete in itself, so it should contain no citations unless they are completely defined within the Abstract.

2. The Intellectual Property section at page 27 includes a 'mailto:' line which seems out of context.
2007-02-04
05 Russ Housley
[Ballot comment]
Typographical error found bt Charlie Kaufman during SecDir review:

  Page 4, fourth from bottom line:
  "discusses in details" -> "discusses in …
[Ballot comment]
Typographical error found bt Charlie Kaufman during SecDir review:

  Page 4, fourth from bottom line:
  "discusses in details" -> "discusses in detail"

  Page 25, third from bottom line:
  "andwidth" -> "Bandwidth"

  Page 27, 8th line:
  "mailto:" -> ""
2007-02-04
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-02-04
05 Brian Carpenter
[Ballot comment]
The choice of draft filename in this case was very confusing. Personally, I would have reviewed this draft a long time ago if …
[Ballot comment]
The choice of draft filename in this case was very confusing. Personally, I would have reviewed this draft a long time ago if the filename had even hinted that it concerned diffserv PHBs.
2007-02-04
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2007-02-01
05 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2007-02-01
05 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2007-02-01
05 Magnus Westerlund Created "Approve" ballot
2007-01-25
05 Magnus Westerlund A update to adress the ID-nits prior to the agenda deadline next week has been requested.
2007-01-25
05 Magnus Westerlund Placed on agenda for telechat - 2007-02-08 by Magnus Westerlund
2007-01-25
05 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Magnus Westerlund
2007-01-24
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-01-24
04 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-04.txt
2006-11-17
05 Magnus Westerlund State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::Point Raised - writeup needed by Magnus Westerlund
2006-11-08
05 (System) Request for Early review by SECDIR Completed. Reviewer: Charlie Kaufman.
2006-10-19
05 Magnus Westerlund Waiting for resolution on IETF last call comment.
2006-10-19
05 Magnus Westerlund State Changes to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for AD Go-Ahead by Magnus Westerlund
2006-10-13
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-09-29
05 Amy Vezza Last call sent
2006-09-29
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-09-29
05 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund
2006-09-29
05 Magnus Westerlund Last Call was requested by Magnus Westerlund
2006-09-29
05 (System) Ballot writeup text was added
2006-09-29
05 (System) Last call text was added
2006-09-29
05 (System) Ballot approval text was added
2006-09-28
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-09-28
03 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-03.txt
2006-09-05
05 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Magnus Westerlund
2006-09-05
05 Magnus Westerlund
I have made my AD evaluation of draft-ietf-tsvwg-rsvp-ipsec-02 and do have some comments and questions.

1. Section 2.1:

For the session objects shouldn't they point …
I have made my AD evaluation of draft-ietf-tsvwg-rsvp-ipsec-02 and do have some comments and questions.

1. Section 2.1:

For the session objects shouldn't they point at the definition of the FLAGS field?

2. Section 2.1: Extended VDstPort: Can IP addresses really be used as global identifiers. What about RSVP in private address domains?

3. Section 2.2:

4. Section 7. The c-type allocation behavior for the new Class SESSION-OF-INTEREST should that be according to BCP 96 (RFC 3936)? I think it could be good to indicate what rules to apply for future C-types in this class.
2006-09-05
05 Magnus Westerlund State Change Notice email list have been change to tsvwg-chairs@tools.ietf.org, flefauch@cisco.com, bdavie@cisco.com,pratik.bose@lmco.com,christou_chris@bah.com,davenport_michael@bah.com from tsvwg-chairs@tools.ietf.org
2006-07-11
02 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-02.txt
2006-07-10
05 Magnus Westerlund
TSVWG request that "Generic Aggregate RSVP Reservations"
(draft-ietf-tsvwg-rsvp-ipsec-01.txt) is published as Standards Track.

    1.a) Have the chairs personally reviewed this version …
TSVWG request that "Generic Aggregate RSVP Reservations"
(draft-ietf-tsvwg-rsvp-ipsec-01.txt) is published as Standards Track.

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Yes, Shepherd is James Polk (jmpolk@cisco.com), TSVWG co-chair

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes, this document has had thorough review by the WG, and a separate review
by Steve Kent and Russ Housley (at IETF 64) ensuring security
considerations were in line - which I was present for. I have no concerns

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

    1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There was WG consensus.  This doc has been reviewed by many people, but not
all in the WG understood it, as this WG is not filled with RSVP or IPsec
expertise, necessitating the separate security review (see above).  There
is enough RSVP expertise in the WG, and there was solid consensus from that
group.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

No.

    1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.  The boilerplate is good, but the ID is 27 pages and lacks a
TOC.  This will be added once the ID blackout is lifted.

    1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publication).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

<References split or not>.

References split. There are no normative references that are a "work in
progress" (i.e. no ID as a normative ref).


    1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

RFC 3175 defines aggregate RSVP reservations allowing resources to be
reserved in a Diffserv network for a given DSCP from a given source to a
given destination. RFC 3175 also defines how end-to-end RSVP reservations
can be aggregated onto such aggregate reservations when transiting through
a Diffserv cloud. There are situations where multiple such aggregate
reservations are needed for the same source IP address, destination IP
address and DSCP. However, this is not supported by the aggregate
reservations defined in RFC 3175. In order to support this capability, the
present document defines a more flexible type of aggregate RSVP
reservations, referred to as generic aggregate reservation. Multiple such
generic aggregate reservations can be established for a given DSCP from a
given source IP address to a given destination IP address. The generic
aggregate reservations may be used to aggregate end-to-end RSVP
reservations. This document also defines the procedures for such
aggregation. The generic aggregate reservations may also be used end-to-end
directly by end-systems attached to a Diffserv network.


        *    Working Group Summary

There is consensus in the WG to publish this document. It has been reviewed
by several people prior to the WG last call. Comments raised have been
addressed.

        *    Protocol Quality

This document has been well reviewed in the WG and comments raised has been
addressed.
2006-07-10
05 Magnus Westerlund Draft Added by Magnus Westerlund in state Publication Requested
2006-07-10
05 Magnus Westerlund [Note]: 'Shepherd is James Polk (jmpolk@cisco.com)' added by Magnus Westerlund
2006-06-15
01 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-01.txt
2006-03-09
00 (System) New version available: draft-ietf-tsvwg-rsvp-ipsec-00.txt