Re: Last Call for draft-ietf-rolc-apr-00.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> > 
> > But I'm not arguing that the local/remote not be QoS based.  If you
> > look at the quote that you responded to it says "the application
> > passes QoS requirement or traffic characterisitics through RSVP
> > (possible passed it within the same box) and indirectly controls SVC
> > management, not directly".
> 
> And I'd like to finess the issue of whether this control is done directly
> or indirectly. I think it should be sufficient if we'll just say that "SVC ma
> nagement
> should be driven by the QoS and/or traffic requriements of the application".
> 
> Yakov.

Sounds like we are near convergence on this issue.  The remaining
difference may be that I wish to document the desirable case to be a
standardized parameterization which could be used to allow indirection
in cases where it was needed.  I'd like to document the case where no
appropriate parameterization is available in a standard protocol
making it necessary to restrict SVC management for an application
class as a practical reality that is less desirable and hopefully
temporary situation as the reservation parameterization can be
expected to evolve slowly but steadily.  Some vendors may decide they
don't want their proprietary local/remote "trick" standardized.  IMO
the architecture document can acknowlege this (if you insist) but
strongly discourage the practice.

I'd like to say more than "SVC management should be driven by the QoS
and/or traffic requirements of the application".  I'd like to say more
about the desirability of working with the reservation protocols and
that it is desirable to strive toward standardize the parameterization
needed for the local/remote decision so that it can be passed along in
a reservation protocol or if nothing else standardized across host's
APIs if the application must provide hints (aka contribute some of the
parameters).

Curtis