Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability?

From: yinhan <[email-masked]>
Date: Tue, 24 Oct 2006 10:47:23 +0800

Hi  Mike
 I think it is about the depth of interoperability.
 Vendor-specific attributes should be minor. Additionally,  The NEA Server 
  should not deny the NEA Client because the endpoint can not  provide 
  vendor-specific attribute. If that, the posture validator will only have to interoperate
  well  with the posture collector that can give the vendor-specific  attribute the validator
 requires and and complete the normal function. Therefore, the most attributes should be 
standardized, and the standardized attributes should include the binding of version, 
update time and threads  

> ----- Original Message ----- 
> From: "Mike Fratto" <[email-masked]>
> To: "Yin Han" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, October 19, 2006 9:25 PM
> Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability?
> 
> 
>>>   Therefore, the statment should be added into the charter:"To realize
>>> interoperability, the most attributes are standard in PA-level and PV must
>>> be able to make such assessment that NEA server can permit the NEA cllient
>>> to access the network even though the PC could not provide the
>>> vendor-specific attributes." If we can not reach it, the interoperability
>>> will be impractical.
>> 
>> Yin, I think what your talking about is an implementation and local
>> policy issue, and not a interoperation issue, and therefore not really
>> an issue for standardization.
>> 
>> Whether a foreign computer is allowed to provide it's own posture
>> assessment is a matter of local policy for the trusting company.
>> 
>> That the posture collectors and posture validators can exchange
>> information is a matter of standardization to that point that the
>> formats are standardized for attribute exchange but not necessarily
>> the meaning of those attributes.
>> 
>> RADIUS attribute extensions work in a similar manner and probably
>> provides a decent model to work off of.
>> 
>> mike

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 24 Oct 2006 09:05:18 -0400

I hear what your saying, but what your describing is a local security
policy issue, not whether a client and server can exchange data. It is
an important issue, to be sure, but not really an IETF concern. How a
company chooses to handle exceptions, in this case, an NEA client that
doens't have all the attributes that Validator wants, is defined by
the policy.

RADIUS has a similar issue. The data formats and some attributes are
defined, but the vendor extensions are not. Therefore, supporting
vendor extensions falls on the posture validation vendors in a similar
manner that RADIUS server vendors had to import the vendor specific
dictionaries.

There are two perspectives on interoperation. The first is can a
component from vendor A exchange information with a component from
vendor B, ie, are the data formats and protocols defined and properly
implemneted? That interoperation eases product development. The other
perspective you are describing is does product A support product B,
and for customers of these vendors, that becomes a differentiator in
aking a buying decision.

In theory, vendor A and vendor B should be able to ineroperate quickly.