Subject: RE: SCEP newest spec

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Jun 2003 12:32:03 -0700

> If IETF is going to get into the mode of simply accepting 
> what somebody else
> has done, even if we regard it as not correct or not 
> applicable or applying
> to a different context or ..., then we're going to get into 
> trouble quickly.

Why differentiate between internal and external?

If there is an argument for not reinventing the wheel then apply it
uniformly. If on the other hand there is an argument for duplication on
occasion then accept that.

		Phill

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 23 Jun 2003 16:29:56 -0400

> occasion then accept that.

Al Arsenault's personal opinion:  Phill's comment is essentially correct.
However, it ignores some facts.

One of the first things that I would hope any working group (IETF or
otherwise) would do is establish some sort of requirements.  That is,
exactly what problems do you think you're trying to solve, and what
constitutes a successful solution?  Then you move on to finding your
solutions.  (I recognize that this is often not what's done - there are too
many times when people run around with solutions, just looking for that
perfect problem.  But that's another thread.)

If IETF has identified a problem, and there is an acceptable solution
developed in a different forum - ANSI, ETSI, OASIS,
Joe's-Standards-and-Storm-Doors, wherever - then certainly IETF should look
at adopting or pointing to that solution.  There is no point in creating a
new, competing technology that will simply harm interoperability and
fragment the Internet.

Sometimes IETF would simply publish the existing solution as an RFC;
sometimes IETF would tailor/profile the solution; sometimes IETF would work
with the other group to jointly "develop" the solution; sometimes IETF would
not publish a document but would simply point to the other solution.

This is often done - to wit, ANSI or IEEE versions of crypto-algorithm
specs; the X.509 certificate spec; the jointly-developed XML DSIG spec; etc.

However, sometimes what is accepted as a solution by another group is deemed
unacceptable by IETF, for one reason or another.  It might be because that
other solution has unacceptable IPR constraints.  It might be because it
doesn't apply to the "Internet context".  It might be because it doesn't
meet the entire set of IETF requirements (see above).  It might be because,
to use the technical term, it creates a partial vacuum.  In that case, then
it's not inappropriate at all for IETF to "ignore" the external solution,
and develop one for the Internet that meets IETF requirements.

In the case that came up earlier in this thread:  the PKIX working group
developed a set of requirements for a DPV/DPD solution.  A number of
proposed solutions were set forth.  One was chosen.  It wasn't XKMS. I can't
find anywhere that XKMS was seriously advanced as a potential DPD/DPV
solution; I certainly can't find the compliance matrix for it.  (Apologies
if I didn't search hard enough; pointers would be appreciated.)

Thus, the IETF - PKIX in particular - is perfectly justified in developing a
solution to meet its requirements, notwithstanding the fact that another
standards group with some level of overlap in membership has chosen to use
another solution to meet ITS identified requirements.

Now, if XKMS had clearly met the DPD/DPV requirements in RFC 3379, and IETF
ignored/rejected it because of a "not invented here" attitude, then Phill's
complaints would be legitimate. Otherwise, they're not.

Hence my comments about X9.68, and WTLS.  Two other "standards" bodies -
ANSI X9F1 and WAP Forum, respectively - thought that they had their own sets
of requirements, and established solutions for them.  Good for them.
There's no reason for IETF to adopt those solutions, UNLESS we believe that
our consituency - which is theoretically "the Internet" - has the same
requirements.  It doesn't.

WRT SCEP: regardless of how they came into being, we already have two
protocols that do the same task.  Unless there's a clear reason why SCEP is
"better", which would justify obsoleting the two solutions we have and
adopting SCEP, Steve Kent's answer is appropriate:  we ain't gonna make the
situation worse by publishing a third way to do the same thing.

                        Al Arsenault

---

From: "todd glassey" <[email-masked]>
Date: Mon, 23 Jun 2003 14:32:57 -0700

Phillip - the issues is whether the IETF is an Open and Fair "Standards
Body" or not. All of the paperwork says that it is, but when you ask people
how they implement fairness, or Openness,  they retort about
no-constituency, no votes, and no records of what anyone did or how it was
done. And then it seems that they vote on it with the rest of the IESG in a
secret session that makes a session of the FISA Judges look like a public
meeting

As to the IETF picking one "standard" over another, as it's own standard -
that also is blatantly unfair since anyone with enough money can clearly buy
a working group, and they can do that by just sticking enough bodies into
the mailing list such that they have a voting control during the straw
polls.

What needs to happen is that the IETF needs to be reduced to a mechanical
set of standards processes such that the real value here is the vetting of a
standard instead of the clandestine creation of a conspiracy to do damage to
all the other players besides the ones that control the WG's or the WG
Chairs.

Todd Glassey

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>; "Hallam-Baker, Phillip"
<[email-masked]>; "'Stephen Kent'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 23, 2003 12:32 PM
Subject: RE: SCEP newest spec