Subject: Re: Comments on draft-ietf-rsvp-proxy-00.txt

From: "Dinesh G Dutt" <[email-masked]>
Date: Mon, 17 Jul 2000 20:33:39 -0700 (PDT)

Hi,

I regret the delay in responding to these comments. I have addressed all the
points raised by Andrew below. A new version of the draft has been submitted
last week. More comments inline.

Andrew Smith writes:

 > 2. Scope: there is no reason to tie RSVP proxy to NULL service; no reason to
 > tie it to DiffServ/DSCPs: instead, should use generic examples of wanting to
 > replace or add RSVP objects. No reason to include discussion of SBM here. No
 > reason to tie the mechanism to outsourced policy management: this should be
 > described as a general mechanism for RSVP.
Fixed. The wording has been modified to address this.
 > 
 > 3. Subflows? what is this all about?
This has been removed.

 > 
 > 4. The draft talks about "generation of the Resv message": are we talking
 > about individual messages or installation of state here? I always thought
 > that RSVP messages were just a mechanism to install/refresh/delete state in
 > intermediate and terminal nodes. I think this draft uses the wrong model for
 > what is being done here.
Clarified in detail what we're talking about.

 > 
 > 5. Section 3: the discussion of where along the path to locate the proxy
 > function does not give much help. I think this discussion is outside the
 > scope (yes, it is a policy or configuration issue).
 > 
 > 6. Section 3.1: There is no need to specify all those details of RSVP
 > message syntax and rules: the behaviour of what goes in a RESV message is
 > already defined by RFC2205.
This section (3.1) has been removed.

 > 
 > 7. Section 3.2: what is special about SBMs? yes, you have to have the proxy
 > at the right point along the path: same issue exists with pure RSVP.
Fixed. 

 > 
 > 8. Section 5: should not be making any changes to RSVP recommendations here.
Agreed. Fixed to reflect issues raised by RFC2205.

 > 
 > 9. Section 6: IPR - still waiting to see these claims: I do not think it is
 > appropriate to forward this as an RFC with this still pending.
We have submitted a statement to IETF that Steve Coya indicated would be posted
on IETF's web page.

Dinesh
-- 
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information? - T. S. Eliot