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 |