[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue with the requirements document: PKIX-centric terminology

>-----Original Message-----
>From: Stephen Kent [mailto:kent@xxxxxxx] 
>Sent: Thursday, August 16, 2007 3:00 PM
>To: Turner, Sean P.
>Cc: ietf-trust-anchor@xxxxxxxx
>Subject: RE: Issue with the requirements document: 
>PKIX-centric terminology
>>If we don't include their documents as a normative reference 
>does this 
>>still hold true?  We don't expect everybody that might use TAM 
>>deliverables to have publiclly available documents for their 
>>architectures, etc. We do expect and want people to come and 
>>to the work - but the oneous is on them to see that it 
>supports their use cases.
>Certainly someone may make use of TAM even if we never know 
>about their context, protocol constraints, etc.
>The question I was raising is whether we consciously try to 
>accommodate use cases that depend on standards controlled by 
>other organizations (without a liaison relationship) or in 
>areas where there are no standards and where proprietary 
>mechanisms are the rule. 
>A secondary question is, if we do try to accommodate use cases 
>from such contexts, do we give them equal weight relative to 
>use cases that reside within the IETF purview.  For example, 
>if we have X.509, OPGP, and DNSSEC-based use cases, do we pay 
>more attention to them?

I think we should consciously try to accommodate use cases even if they're
based on non-public scenarios - if the folks "representing" those other
organizations/standards want to work on TAM.  Some of this might be growing
pains for the IETF, but maybe a liaison should be formed with groups like
TCG/TPM that want to work on it and that want to use the outcome?

The second question is the interesting one.  Doesn't it come down to if you
want to play with the sand in the IETF sandbox, then the IETF wins the
arguments? I guess I think it does. It would be hard for me to swallow a
decision that threw an IETF "requirement" off the raft for a non-IETF

Then again - if we design a basic protocol with extensions I guess I could
see a scenario where it wouldn't work for everyone, but I can also see lots
of other scenarios where they (who ever didn't win the argument) take some
kind of "hit" (i.e., they don't get it exactly their way) to do the
"standard" TAM.