[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue with the requirements document: PKIX-centric terminology
At 3:24 PM -0400 8/16/07, Turner, Sean P. wrote:
...
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 IETF does establish liaisons with other SDOs, prior to doing
work. We have such relationships with ITU, IEEE, and, I think, the
W3C, for example. I don't think we have one with TCG. I couldn't tell
from the text above if you were aware of these relationships.
One problem is that, absent such a relationship, it can be hard to
determine if someone really represents another group, although there
are exceptions. For example, PKIX has worked with "representatives"
from ETSI, where I believe no formal IETF liaison exists. However,
if the individual chairs a relevant ETSI group, or is the author of
several ETSI documents and wants to coordinate another such document
with PKIX, we have sufficient basis for treating the individual as a
valid representative, informally. I would expect other WGs operate
similarly.
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
"requirement."
no disagreement there.
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.
Extensions are the bane of security protocols. For example, we have
had bad experiences with them in OCSP. We see that X.509 extensions
can either be focused and useful, or committee compromises that add
complexity but are rarely used or supported.
If we create a protocol that is largely a shell, to be broadly
accommodating, and one has to define context-specific extensions for
X.509, OPGP, DNSSEC, etc., then it remains to be seen how useful the
common shell will be.
Steve