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

Yakov Rekhter <yakov@cisco.com> Thu, 26 October 1995 17:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18370; 26 Oct 95 13:44 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18365; 26 Oct 95 13:44 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26128; Thu, 26 Oct 1995 13:15:06 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA11850 for rolc-out; Thu, 26 Oct 1995 13:21:30 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id NAA11841 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:21:28 -0400
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26084 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:10:00 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA09024; Thu, 26 Oct 1995 10:16:08 -0700
Message-Id: <199510261716.KAA09024@hubbub.cisco.com>
To: curtis@ans.net
cc: rolc@nexen.com
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Thu, 26 Oct 95 11:11:58 EDT." <199510261512.LAA22688@brookfield.ans.net>
Date: Thu, 26 Oct 95 10:16:03 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

Curtis,

> 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.

While I would agree with what you said here, I am not sure whether this
belongs to the APR document. So, I'd like to get a feedback from other
folks on the list whether they think this should be included in the
document, or whether this issue should be addressed in some other
WG, like rsvp or int-serv.

Yakov.