Re: [Policy] One more try for interest

"Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov> Tue, 25 February 2003 15:33 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03514 for <policy-archive@odin.ietf.org>; Tue, 25 Feb 2003 10:33:24 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFgSg06073 for policy-archive@odin.ietf.org; Tue, 25 Feb 2003 10:42:28 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFa3p04648; Tue, 25 Feb 2003 10:36:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFRlp04287 for <policy@optimus.ietf.org>; Tue, 25 Feb 2003 10:27:47 -0500
Received: from mx-relay1.net.treas.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02949 for <policy@ietf.org>; Tue, 25 Feb 2003 10:18:12 -0500 (EST)
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.net.treas.gov (8.12.3/8.12.3) with SMTP id h1PFM4wj024606; Tue, 25 Feb 2003 10:22:07 -0500 (EST)
Received: from no.name.available by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 25 Feb 2003 15:22:04 UT
Received: from irsbd3.net.treas.gov (localhost [127.0.0.1]) by mailhub-5.net.treas.gov (8.12.3/8.12.3) with ESMTP id h1PFLwT7019786; Tue, 25 Feb 2003 10:21:59 -0500 (EST)
Received: from no.name.available by irsbd3.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.14.15]) with ESMTP; Tue, 25 Feb 2003 10:21:58 -0500
Received: from parnelli.indy.cr.irs.gov (localhost.localdomain [127.0.0.1]) by mears.indy.cr.irs.gov (8.11.6/8.11.6) with ESMTP id h1PFLsH06140; Tue, 25 Feb 2003 10:21:55 -0500
Message-ID: <3E5B8A12.7040804@parnelli.indy.cr.irs.gov>
Date: Tue, 25 Feb 2003 10:21:54 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Organization: Internal Revenue Service
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
CC: policy@ietf.org
Subject: Re: [Policy] One more try for interest
References: <5.1.0.14.0.20030212143410.02121ab0@mail.stevecrocker.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-BeenThere: policy@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Joel, WG,

Joel M. Halpern wrote, On 02/12/2003 02:37 PM:
> Well, a small number of additional people spoke up for my last note.
> 
> Reviewing my records, I do note that 2 months ago we received
> http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ext-schema-00.txt 
> 
> an internet draft starting on the problem of an LDAP mapping of PCIMe.
> 
> I have seen no discussion of this draft on the list.
> 
> If we were to get rechartered to work on an LDAP mapping for PCIMe, is 
> this the right document?


The draft is a draft. If those who advocate Policy as a tool for
implementing QoS want to carry PCIMe forward to a concrete LDAP
implementation, they should do it.

But why recharter *only* to work on an LDAP mapping for PCIMe? Policy
has much more potential for specificity, for refinement, for extension,
for applicability. This WG should be the forum to extend Policy in
whatever direction it evolves.


> Is this document so well put together that Ed and I should just ask the 
> IESG to publish to as a PS?


No. It needs some work, particularly with its LDAP-isms. The ABNF
which describes the information components of PCIMe is incomplete
and should be conformed to the style and format defined in
RFC 2252.


> Has anyone other than the authors even read the document?


Yes.


> 
> Thank you,
> Joel M. Halpern
> 
> PS: Just to be clear, if there is not significant participation we will 
> have no choice but to close the working group.


Don't close it before the PCLS comes out of the IANA oven and attains
RFC status. What's up with that, anyway? What's the status of the PCLS?

If the WG is closed before PCLS becomes an RFC, the WG will have
exited without even offering a hint of a mechanism for implementing
the Model. This would render the work which has already been
accomplished practically useless from an interoperability standpoint.

What's the rush to close the WG? Consider the history of this WG. Its
progress has always been slower than some would have liked. Why kill
it now? What has changed?

Why has apparent interest in this WG withered? I have my own pet
theories.

THEORY 1
The withering of this WG's vitality reflects a natural consequence
of the evolution of the IETF's deliberative and standards setting
processes. I'm not the first to observe that the IETF's activities
have come to be dominated by commercial entities, by commercial
interests. If there is a market opportunity, it seems, there is
potential for an RFC which can serve as a marketing tool. The upside
is that commercial entities can focus financial and human resources
on a problem space in ways that academic, government, and pure research
sectors cannot. By the same token, when a market segment recedes,
withers, or is supplanted by The Next Big Thing, then the commercially
driven support for a technology initiative which has become Yesterday's
Catfood (marketing-wise) withers as well.

Are immediate marketability and near-term market advantage the only
true measures of a technology's necessity?

THEORY 2
When the work of this WG was PCIM and PCLS, the future of Policy
seemed wide open. As defined in PCIM and PCLS, Policy isn't just
for netheads and router jockeys. But when the WG's work narrowed to
PCIMe, when the work of this WG turned to focus more explicitly on
QoS issues, the interested audience narrowed commensurately; an
unfortunate but natural consequence.


Joel, I believe there is adequate justification for continuing this
WG. Policy is bigger than QoS. If the Policy for QoS advocacy has
faded or is temporarily dormant, so be it. But Policy has more to
offer, and I'd like to help prove it.


-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy