Paul,
I have given this a lot of thought both
from do-the-right-thing standards and vendor perspectives and have concluded
that missing Joel-suggested attribute types should be considered for inclusion,
for the following reasons:
1. If they are used in one or more existing
products as Joel found, then these products must have found them necessary. In
particular, file system and registry parameters are necessary (but, alas, not
sufficient) to accommodate arbitrary user-defined policies using ‘commodity’
clients and verifiers. Frankly I would also like to see the running process
table in there as well.
2. The proposed set of attributes clearly leans
both in semantics and terminology towards a specific product’s
requirements as apparent justification for their inclusion. While I have no
problem with this in principle, its corollary is that adding ‘genericized’
attribute types used by other products should be equally justified. My example is
the attributes that drill down on firewall ports – this is rather
endpoint enforcement specific. Applying this rationale, shouldn’t some of
these attribute types also be more appropriately registered in a subsequent specification?
3. While everything certainly can’t
be anticipated, my preference would be to include a few more known types that
will either forestall proliferation of subsequent specifications whose only
purpose is to add numbers to the registry – should there be a WG to host
such drafts – or, more likely, non-interoperable but redundant vendor-specific
code points.
X-Original-To: nea-archive at megatron.ietf.org
Delivered-To: ietfarch-nea-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 98B5C3A6B25;
Fri, 9 Jan 2009 18:43:56 -0800 (PST)
X-Original-To: nea at core3.amsl.com
Delivered-To: nea at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 505013A6930
for ; Fri, 9 Jan 2009 18:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id j657drrlwplQ for ;
Fri, 9 Jan 2009 18:43:47 -0800 (PST)
Received: from SCES1.sc.nevisnetworks.com (unknown [216.27.189.242])
by core3.amsl.com (Postfix) with ESMTP id 886F23A6B25
for ; Fri, 9 Jan 2009 18:43:47 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Jan 2009 18:38:25 -0800
Message-ID: <126EBB1F0092E14B9E595D03263235AA021AE85F at SCES1.sc.nevisnetworks.com>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Nea] Last call for "due diligence" attributes for PA-TNC
basespecification
Thread-Index: AclqujePeSuWDXXcSlea8SxP7FW5ZAH/4kCQ
References:
From: "Joseph Tardo"
To: "Paul Sangster" ,
"NEA"
Cc: Paul Hoffman
Subject: Re: [Nea] Last call for "due diligence" attributes for PA-TNC
basespecification
X-BeenThere: nea at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Endpoint Assessment discussion list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="==============79418839=="
Sender: nea-bounces at ietf.org
Errors-To: nea-bounces at ietf.org
This is a multi-part message in MIME format.
