Skip to main content

Resource Reservation Protocol (RSVP) Proxy Approaches
RFC 5945

Revision differences

Document history

Date Rev. By Action
2017-05-16
09 (System) Changed document authors from "Jukka Manner, Dan Wing" to "Jukka Manner, Dan Wing, Francois Le Faucheur, Allan Guillou"
2015-10-14
09 (System) Notify list changed from tsvwg-chairs@ietf.org, draft-ietf-tsvwg-rsvp-proxy-approaches@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Gonzalo Camarillo
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2010-10-11
09 Cindy Morgan State changed to RFC Published from RFC Ed Queue by Cindy Morgan
2010-10-11
09 Cindy Morgan [Note]: changed to 'RFC 5945' by Cindy Morgan
2010-10-10
09 (System) RFC published
2010-04-26
09 (System) IANA Action state changed to No IC from In Progress
2010-04-26
09 (System) IANA Action state changed to In Progress
2010-04-26
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-04-26
09 Amy Vezza IESG state changed to Approved-announcement sent
2010-04-26
09 Amy Vezza IESG has approved the document
2010-04-26
09 Amy Vezza Closed "Approve" ballot
2010-04-26
09 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-04-23
09 Gonzalo Camarillo [Ballot Position Update] Position for Gonzalo Camarillo has been changed to No Objection from Discuss by Gonzalo Camarillo
2010-04-19
09 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to Yes from No Objection by Lars Eggert
2010-04-16
09 Gonzalo Camarillo
[Ballot discuss]
I am picking up Cullen's discusses on draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt and draft-ietf-tsvwg-rsvp-proxy-proto-11

Discuss (2010-03-22)

Need to discuss the applicability of deployment - as previous RSVP …
[Ballot discuss]
I am picking up Cullen's discusses on draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt and draft-ietf-tsvwg-rsvp-proxy-proto-11

Discuss (2010-03-22)

Need to discuss the applicability of deployment - as previous RSVP discussions,
this is likely only deployable inside a single trust domain.

For a proxy that does inspection or path triggered, how does it know which ones
to "proxy" and what to ignore. It seems this will break all end to end RSVP that
behind a proxy.

Why are section 4.1 and 4.1 SHOULD and MAY implement. It seem like they need to
be MUST.

How do proxies know what bandwidth to request for a flow? If they assume some
certain bandwidth, this makes it much harder to deploy new services.

Need to specify "predetermined time" in section 4.1. Not willing to have it be
zero.

Why is the Receiver-Proxy-Needed needed?

RAO paragraph in security consideration does not seem right.

The dissection in last para of stein 5 is no longer true with the other changes.

Don't understand why this needs the group-keying work

For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in
firewalls has proven this is a really bad idea and mostly fails. Not to mention
SIP over TLS.

The draft seems to hint at detecting RTP packets - I have no idea how to do
this, please clarify.

ICE is sometime used to signal media flows, but not always - how would the
device know. Even worst, how would it know what bandwidth to use.

Has the working group considered if there are ways to achieve this that are not
IPR encumbered?
2010-04-16
09 Gonzalo Camarillo [Ballot Position Update] New position, Discuss, has been recorded by Gonzalo Camarillo
2010-03-30
09 Magnus Westerlund Responsible AD has been changed to Lars Eggert from Magnus Westerlund
2010-03-22
09 Cullen Jennings
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For …
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy.

Why are section 4.1 and 4.1 SHOULD and MAY implement. It seem like they need to be MUST.

How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services.

Need to specify "predetermined time" in section 4.1. Not willing to have it be zero.

Why is the Receiver-Proxy-Needed needed?

RAO paragraph in security consideration does not seem right.

The dissection in last para of stein 5 is no longer true with the other changes.

Don't understand why this needs the group-keying work

For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS.

The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify.

ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use.

Has the working group considered if there are ways to achieve this that are not IPR encumbered?
2010-03-08
09 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt
2010-01-14
09 Cullen Jennings
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For …
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy.

Why are section 4.1 and 4.1 SHOULD and MAY implement. It seem like they need to be MUST.

How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services.

Need to specify "predetermined time" in section 4.1. Not willing to have it be zero.

Why is the Receiver-Proxy-Needed needed?

RAO paragraph in security consideration does not seem right.

The dissection in last para of stein 5 is no longer true with the other changes.

Don't understand why this needs the group-keying work

For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS.

The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify.

ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use.

Has the working group considered if there are ways to achieve this that are not IPR encumbered?

The example in A.3 seems really confused about how SBC work.

As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.
2009-10-26
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-10-26
08 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-08.txt
2009-09-01
09 Magnus Westerlund State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Magnus Westerlund
2009-09-01
09 Magnus Westerlund Trying to resolve discuss. But will require updated draft.
2009-05-28
09 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup by Amy Vezza
2009-05-26
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2009-05-21
09 Cindy Morgan State Changes to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer by Cindy Morgan
2009-05-21
09 Cullen Jennings
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For …
[Ballot discuss]
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.

For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy.

How does one migrate out proxy RSVP to end to end RSVP?

How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services.


For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS.

The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify.

ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use.

Has the working group considered if there are ways to achieve this that are not IPR encumbered?

The example in A.3 seems really confused about how SBC work.

As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.
2009-05-21
09 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2009-05-21
09 Ross Callon
[Ballot comment]
I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which …
[Ballot comment]
I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network).

I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail.

I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.
2009-05-21
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-05-21
09 Ralph Droms
[Ballot comment]
In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the …
[Ballot comment]
In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure."  It's not clear to me why the sender needs to be notified of reservation failure.  Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy?  I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right?  Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification?  I'm happy to be educated as I'm not well-versed in RSVP.

Nit: "cater for" might read better as "cater to" or "provide for"
2009-05-21
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-05-21
09 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-05-21
09 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-05-21
09 Dan Romascanu
[Ballot comment]
In Section 4.5:

  Candidate protocols for realizing such interface
  include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644 …
[Ballot comment]
In Section 4.5:

  Candidate protocols for realizing such interface
  include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the
  Extensible Markup Language (XML) and DIAMETER ([RFC3588]). 

SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol.

I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.
2009-05-21
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-05-21
09 Jari Arkko
[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end …
[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end RSVP model). However, I think the documents should
describe more clearly their implications and limitations. A
Surgeon General's Warning if you will.

I'll note that I am not an RSVP expert. I may have missed something.
In that case, please educate me and I'll clear this Discuss.

In particular, Section 4.1 says:

  In order to build the Resv message, the RSVP Receiver Proxy can take
  into account information received in the Path message.  For example,
  the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
  message which mirrors the SENDER_TSPEC object in the received Path
  message.

RSVP has separate flow reservations for the two directions, and
just copying the flow spec from one direction to another is
a severely limited approach. Or perhaps even a potentially harmful
approach. For instance, in any streaming or IPTV situation this
approach would clearly lead to problems. One could ask how well the
network works (a) with the proxy QoS reservations or (b) without any
reservations. The ability to make the reservations allows bandwidth
to be reserved, and increases the likelihood of, say, successful
video transmission. However, the guessing involved in the mirroring
process leads to incorrect reservations. For instance, the user's DSL
link might have 24 megabits downlink and 1 megabit uplink capacity.
Without any reservations a 10 megabits/s stream can easily be downloaded.
But with proxy reservations, the system would report a conclusive
error that the capacity is insufficient. Compare this to the situation
where you would just not answer the RSVP messages and the sender would
attempt best effort service.

The application triggered mechanisms have a better chance of a
successful outcome, but they imply fairly severe involvement in the
application signaling process, such as the introduction of a b2bua.
What's the likelihood of a b2bua on the signaling path disrupting
your intended communication setup? I'd claim its a non-zero probability...

I would suggest that Section 4.1 needs to include additional text to
document the problems associated with mirroring. Also, the introduction
should provide stronger guidance on the overall benefits vs.
disadvantages associated with the proxies, and suggest that the proxies
only be setup for very specific networks, applications, and flows to
specific destinations.
2009-05-21
09 Jari Arkko
[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end …
[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end RSVP model). However, I think the documents should
describe more clearly their implications and limitations. A
Surgeon General's Warning if you will.

I'll note that I am not an RSVP expert. I may have missed something.
In that case, please educate me and I'll clear this Discuss.

In particular, Section 4.1 says:

  In order to build the Resv message, the RSVP Receiver Proxy can take
  into account information received in the Path message.  For example,
  the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
  message which mirrors the SENDER_TSPEC object in the received Path
  message.

RSVP has separate flow reservations for the two directions, and
just copying the flow spec from one direction to another is
a severely limited approach. Or perhaps even a potentially harmful
approach. For instance, in any streaming or IPTV situation this
approach would clearly lead to problems. One could ask how well the
network works (a) with the proxy QoS reservations or (b) without any
reservations. The ability to make the reservations allows bandwidth
to be reserved, and increases the likelihood of, say, successful
video transmission. However, the guessing involved in the mirroring
process leads to incorrect reservations. For instance, the user's DSL
link might have 24 megabits downlink and 1 megabit uplink capacity.
Without any reservations a 10 megabits/s stream can easily be downloaded.
But with proxy reservations, the system would report a conclusive
error that the capacity is insufficient. Compare this to the situation
where you would just not answer the RSVP messages and the sender would
attempt best effort service.

The application triggered mechanisms have a better chance of a
successful outcome, but they imply fairly severe involvement in the
application signaling process, such as the introduction of a b2bua.
What's the likelihood of a b2bua on the signaling path disrupting
your intended communication setup? I'd claim its a non-zero probabilit...

I would suggest that Section 4.1 needs to include additional text to
document the problems associated with mirroring. Also, the introduction
should provide stronger guidance on the overall benefits vs.
disadvantages associated with the proxies, and suggest that the proxies
only be setup for very specific networks, applications, and flows to
specific destinations.
2009-05-21
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-05-19
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-05-19
09 Ron Bonica [Ballot discuss]
2009-05-19
09 Ron Bonica
[Ballot comment]
I am abstaining not so much because of the content of this document, but because this document extends other work which is not …
[Ballot comment]
I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.

For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.

Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.

The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.
2009-05-19
09 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to Abstain from Discuss by Ron Bonica
2009-05-17
09 Robert Sparks [Ballot comment]
Agree with Tim's concern #2 (what happens when you unintentionally (or intentionally) end up with more than one proxy in a path?
2009-05-17
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-05-14
07 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-07.txt
2009-05-08
09 (System) Removed from agenda for telechat - 2009-05-07
2009-05-06
09 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-05-05
09 Pasi Eronen State Change Notice email list have been change to tsvwg-chairs@tools.ietf.org, draft-ietf-tsvwg-rsvp-proxy-approaches@tools.ietf.org from tsvwg-chairs@tools.ietf.org, draft-ietf-tsvwg-rsvp-proxy-proto@tools.ietf.org
2009-05-05
09 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2009-05-05
09 Tim Polk
[Ballot comment]
section 1:

"presents several fundamental RSVP proxy approaches insisting on how ..."

I don't think "insisting" is the right word here!

section 4.4: …
[Ballot comment]
section 1:

"presents several fundamental RSVP proxy approaches insisting on how ..."

I don't think "insisting" is the right word here!

section 4.4:
s/cortresponding/corresponding/
s/implicitely/implicitly/
2009-05-05
09 Tim Polk
[Ballot discuss]
Two issues: number one is actionable, the second is a discuss-discuss...

Issue #1:
The security considerations do a nice job highlighting the issues …
[Ballot discuss]
Two issues: number one is actionable, the second is a discuss-discuss...

Issue #1:
The security considerations do a nice job highlighting the issues introduced by proxies, but
more detail is needed with respect to RSVP proxies that operate under control of another
entity (Para 4).  These models introduce new security requirements for communication between
the proxy and the controlling entity that are outside the scope of RSVP or this document.
Specifically, these models introduce authentication and confidentiality requirements to protect
against a variety of attacks.  The current text indicates the controlling entity needs to be
trusted, which is also true, but is insufficient.

Issue #2:
(Section 1, Introduction)  What are the consequences of violating the topological constraints
and having two Receiver Proxies on path?  It seems that RSVP would not be used to its
fullest, and the resource reservation would cover less of the path than it could, but this
seems to be sub-optimal rather than broken.

I also wonder whether this merits discussion in the security considerations... perhaps that will
become clear as we discuss the consequences of violating the topological constraints.
2009-05-05
09 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-05-04
09 Ron Bonica
[Ballot discuss]
At this point, this is a DISCUSS DISCUSS.

I we were to massively deploy RSVP proxies, would that cause a massive increase in …
[Ballot discuss]
At this point, this is a DISCUSS DISCUSS.

I we were to massively deploy RSVP proxies, would that cause a massive increase in the amount of RAO traffic arriving at provider boundaries? Would that traffic be dropped? If not, could it cause problems for provider equipment?
2009-05-04
09 Ron Bonica
[Ballot discuss]
At this point, this is a DISCUSS DISCUSS.

I we were to massively deploy RSVP proxies, would that cause a massive increase in …
[Ballot discuss]
At this point, this is a DISCUSS DISCUSS.

I we were to massively deploy RSVP proxies, would that cause a massive increase in the amount of RAO traffic arriving at provider boundaries? Would that traffic be dropped? If not, could it cause problems for provider equipment?
2009-05-04
09 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica
2009-05-04
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-05-03
09 Alexey Melnikov
[Ballot comment]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a …
[Ballot comment]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a direct mechanism for notifying
  the application (since it is not participating itself actively in
  application signaling) so that the application is not in a position
  to take appropriate action (for example terminate the corresponding
  session).  To mitigate this problem, the inspection-triggered RSVP
  Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.


I am also agreeing with Adrian's comment, I was wondering about this myself.
2009-05-03
09 Alexey Melnikov
[Ballot comment]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a …
[Ballot comment]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a direct mechanism for notifying
  the application (since it is not participating itself actively in
  application signaling) so that the application is not in a position
  to take appropriate action (for example terminate the corresponding
  session).  To mitigate this problem, the inspection-triggered RSVP
  Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.
2009-05-03
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-04-29
09 Adrian Farrel
[Ballot comment]
Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.

draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
---
I am …
[Ballot comment]
Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.

draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
---
I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?
---
2009-04-29
09 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Yes by Adrian Farrel
2009-04-29
09 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2009-04-29
09 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2009-04-29
09 Magnus Westerlund [Note]: 'Read this before the Protocol document' added by Magnus Westerlund
2009-04-29
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel
2009-04-29
09 Adrian Farrel Created "Approve" ballot
2009-04-22
09 Magnus Westerlund Placed on agenda for telechat - 2009-05-07 by Magnus Westerlund
2009-04-22
09 Magnus Westerlund Note field has been cleared by Magnus Westerlund
2009-04-22
09 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead::External Party by Magnus Westerlund
2009-02-19
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Scott Kelly.
2008-11-27
09 Magnus Westerlund State Changes to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Magnus Westerlund
2008-11-27
09 Magnus Westerlund [Note]: 'Waiting for some conclusion on the RSVP RAO issues.' added by Magnus Westerlund
2008-11-14
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-12
09 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2008-11-11
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Scott Kelly
2008-11-11
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Scott Kelly
2008-10-31
09 Cindy Morgan Last call sent
2008-10-31
09 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-10-31
06 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
2008-10-31
09 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Magnus Westerlund
2008-10-31
09 Magnus Westerlund Last Call was requested by Magnus Westerlund
2008-10-31
09 (System) Ballot writeup text was added
2008-10-31
09 (System) Last call text was added
2008-10-31
09 (System) Ballot approval text was added
2008-10-31
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-10-31
05 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt
2008-09-08
09 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Magnus Westerlund
2008-09-08
09 Magnus Westerlund Still waiting for updated version to address AD comments
2008-09-08
09 Magnus Westerlund State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Magnus Westerlund
2008-07-01
09 Magnus Westerlund
This is writeup for the two documents:
draft-ietf-tsvwg-rsvp-proxy-proto (proposed standard)
draft-ietf-tsvwg-rsvp-proxy-approaches (informational)

  (1.a)  Who is the Document Shepherd for this document?  Has the
  …
This is writeup for the two documents:
draft-ietf-tsvwg-rsvp-proxy-proto (proposed standard)
draft-ietf-tsvwg-rsvp-proxy-approaches (informational)

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
         
Magnus Westerlund is the Document shepherd. The AD review made it
clear some improvements where needed.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
         
It has received reasonable review from the RSVP interested folks. I
think the document could have benefitted from more wide review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?
         
I think the operational aspects may require more review.         

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
       
I hope by clarifying the AD review comments these concerns will be removed.

  (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?
         
Strong consensus from a couple of individuals.         

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

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Yes, there is one downref needed to be take care of.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
         
Yes, one downref that can be changed to informational ref.         

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?
         
Yes, protos IANA seems okay.         

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
No formal language used.         

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
                RSVP signaling can be used to make end-to-end resource
                reservations in an IP network in order to guarantee the
                QoS required by certain flows.  With conventional RSVP,
                both the data sender and receiver of a given flow take
                part in RSVP signaling.  Yet, there are many use cases
                where resource reservation is required, but the
                receiver, the sender, or both, is not RSVP-capable. 
                Where the receiver is not RSVP-capable, an RSVP router
                may behave as an RSVP Receiver Proxy thereby performing
                RSVP signaling on behalf of the receiver.  This allows
                resource reservations to be established on the segment
                of the end-to-end path from the sender to the RSVP
                Receiver Proxy.
               
                The Proto document defines the RSVP extensions that are
                needed to facilitate operations with an RSVP Receiver
                Proxy whose signaling is triggered by receipt of RSVP
                Path messages from the sender. 

          Working Group Summary
            The consensus for the publication was strong but from a
            small group within the WG.

          Document Quality
            The shepherd doesn't know of any implementations.
           
          Personnel
            WG Shepherd and responsible AD is Magnus Westerlund.
2008-07-01
09 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Magnus Westerlund
2008-07-01
09 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2008-05-30
09 Magnus Westerlund Note field has been cleared by Magnus Westerlund
2008-05-30
09 Magnus Westerlund Merged with draft-ietf-tsvwg-rsvp-proxy-proto by Magnus Westerlund
2008-05-30
09 Magnus Westerlund Draft Added by Magnus Westerlund in state Publication Requested
2008-04-11
04 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-04.txt
2007-12-14
03 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt
2007-11-09
(System) Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt
2007-09-12
02 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt
2007-07-11
01 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt
2007-02-28
00 (System) New version available: draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt