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

Re: Motions before the WG - Was Re: Software for PKI


Todd,

The WG chairs cannot prevent you or anyone else from submitting an Internet-Draft. Anyone can submit an I-D at anytime. However, IETF procedures *require* that the WG chair approve processing of new specifications as WG documents. That is, if someone submits draft-ietf-pkix-newprotocol-00.txt, the PKIX chairs get a message asking if this really is a working group document before the document is posted and the WG website is updated.

This is a very important feature of the process. An IETF working group cannot support development of an infinite number of specifications. By limiting the number and vetting the topics, we ensure that the WG has sufficient resources to meet the most pressing needs. Progression of our existing documents is our first priority (and that of the Security ADs).

Steve and I don't decide which specifications to approve based on politics. That is hogwash, and I totally resent that accusation. We do our best to make the determination a solid engineering decision. Some of the questions we ask are:

* What does this specification add to the PKIX standards suite? For example, we already have two certificate management protocols. A third, fourth, and fifth will only add confusion.

* Is there a community interested in working on this specification? If the only one who is interested in working on this topic is the editor, it shouldn't be a WG specification.

* Is there a community that wants to use this specification? If another WG has identified a requirement, that is a compelling reason to work on it.

* If there are competing proposals, which proposal is *technically* superior? If you recall the SCVP/OCSP v2 debate, arguments based on marketing concepts (e.g., people already know the name "OCSP") didn't fly. Steve pushed for requirements documents to evaluate the utility of each protocol on a technical basis, and state diagrams to evaluate efficiency.

* Note that commercial considerations are not an issue. You wrote about "the various commercial factions that need their standards advanced." I assume they need the standards to be advanced to sell products and obtain funding. That's marketing, not engineering. I'm sorry, but that isn't the mission of the IETF. We are supposed to be creating standards that support "the evolution of the Internet architecture and the smooth operation of the Internet."

Steve and I do not make these decisions in a vacuum, either. The group has opportunities to weigh in, and authors have several strategies they can use to get a document accepted. If a document clearly addresses an important problem within our scope, it may be accepted immediately. More likely, the editors are asked to demonstrate that the problem is important and that people want to work on the topic.

One tried and true method for getting a document into the WG is to publish an independent I-D and bring it to the attention of the WG list. If a community of interest emerges on the list, then the document is likely to become a WG specification. There are a number of examples of this process succeeding in PKIX.

Even if the document does not become accepted as a WG document, the author can progress the document. It can still become an RFC without any WG affiliation. There are a number of examples of this as well. (I think RFC 2313/PKCS #1 is one, but you can't hold me to that. I wasn't there.)

You suggest that the role of the chairs is "facilitator" and "keeper of focus", yet you demand that any document that meets the "formatting requirements" of an I-D has to be accepted as a WG specification. That makes no sense! Vetting proposed I-Ds is the one of the most important aspects of keeping that focus. (Another is establishing requirements specifications for complex or controversial protocols, like DPD/DPV.)

If anything, Steve and I have been *too liberal* with approving documents. The PKIX WG currently has twenty one I-Ds. How many documents do you really think the WG can support?

You also say that we must be held accountable for "the disarray and infighting between the various commercial factions". I guess that's true in part. We are trying to require that documents progress based on technical qualifications, and not progress multiple specifications that meet the same requirement. I suspect that does cause commercial factions with competing specifications to fight. However, if we approved every draft and sent them on the ADs, there would be a great deal more confusion and disarray!

Well Todd, I don't know what to tell you. I'm not convinced by your arguments. On the other hand, you didn't find my first rebuttal convincing, and I expect this one won't satisfy you either.

Tim


At 01:42 PM 11/16/01 -0800, todd glassey wrote:

Tim, I rewrote this acouple of times before sending it. Here goes the last
version -

----

Tim, in a nut shell you have codified everything that is broken here in the
PKIX WG. The ability to veto anything is something that you and Steve both
use way too often and it needs to be removed immediately. Further based in
your commentary below the WG Chairs roles need to be formally defined and
added to the Charter proper.

Bluntly, you need to be accountable for what PKIX is and has grown to under
your leadership, especially the disarray and in-fighting between the various
commercial factions that need their standards advanced.

As to your rebuttal below - I believe that you are wrong across most all of
your points. And in fact I would put forward that you as a WG Chair shoud
not be able to make political decisions for the Group without consulting the
membership base.

Your role is actually as a facilitator and a keeper of focus. But you dont
get to decided what the focus is on, just that there is focus and work
continues to flow. The one constraint you get to exercise is a veto if the
subject matter or focus is not in the PKI Vein - Nothing more nothing less.

And to this focus we were talking about in the last paragraph, the subject
of the focus is up to the membership of this WG as a whole or to its sub
groups where qualitfyable pockets of interest exist. That means that this WG
MUST promote **all** proposals and protocols submitted to it whether it
favors them or not. If they meet the filing format requirements, it is
unreasonable that You or Steve should have anything to say as to whether
they are promulgated from Draft to RFC and then from RFC to Standard.

In fact there is a serious issue here as many of the standards the PKIX
group works on having real value so this veto power as you have used it
could in some instance potentially constitute restraint of trade and that's
a serious problem.

To fix these problems we need the amendment to the Charter as well as a
formal description amendment to the Working Group Chair's definition.

We also need the ability to talk to people about what our protocol modules,
methods, and schemas do in theoretical and real-world senses. If we cant do
that how can anyone build something that is reliant upon one of these
models. It would be like trying to nail Jello to the wall. So we need
Requirements Documents and Use Models where applicable.

Todd
----- Original Message -----
From: "Tim Polk" <tim.polk@xxxxxxxx>
To: "todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>; <ietf-pkix@xxxxxxx>
Cc: "Stephen Kent" <kent@xxxxxxxxxxx>
Sent: Thursday, November 15, 2001 2:43 PM
Subject: Re: Motions before the WG - Was Re: Software for PKI


>
> Todd,
>
> I'd like to respond in two parts - first on requirements documents and
> second on the charter.
>
>                                          Requirements
>
> I do agree that requirements specifications are generally a good thing.  I
> believe that DPD/DPV is an excellent example of where a requirements
> specification makes the difference between technical specifications that
> cycle at draft and specifications that achieve RFC status.
>
> However, we are not entirely in agreement about the the scope of a PKIX
> requirements document.  I may have mis-spoke when we were on the phone,
but
> the requirements document does not "constrain how this protocol interacts
> with others".  PKIX is a service provider, not an application.  Protocol
> designers and application developers are free to use our specifications to
> meet their security requirements.  I agree that it is imperative that they
> understand "what it actually provides from a technological perspective".
>
> This information permits the protocol or application developer to build a
> "use model" that makes sense in their environment.  The appropriate use
> depends on due diligence for an industry or sector, legal requirements,
and
> the threats and risks associated with a particular application of the
> technology.  As a result, there is no way that PKIX can describe
> appropriate "use models".
>
> However, not all specifications need a requirements document.  The PKIX
> algorithms specification is a perfect example: the scope and utility of
the
> specification are straightforward.  There is no utility in a requirements
> document for that specification.  (The PKIX LDAP schema is another such
> example.)  A blanket requirement for requirements drafts will only slow
> down progress, and *we can't afford to go any slower*.
>
>                                      Charter
>
> I do not believe the charter modifications are appropriate or
> required.  Steve and I recognize the utility of requirements documents,
and
> the scope where they are useful.  The IETF has a flexible process that
> allows the chairs to make decisions on a case-by-case basis.  When it is
> appropriate, we can insist on a requirements document as a prerequisite
for
> progression of current documents or submission of new WG documents.  When
> requirements documents are not needed,  we can streamline the process.
>
> The IETF is not a "formal standards body" with motions, votes, and
detailed
> processes.  That is a feature, in my opinion.  I believe that flexibility
> is critical, and oppose any changes to the charter that reduce that
> flexibility.
>
> Thanks,
>
> Tim Polk
>
> At 08:24 AM 11/14/01 -0800, you wrote:
>
> >Stephen -
> >
> >Maybe this is partially my fault - Tim and I spoke for about a half hour
> >this AM and I perhaps it me that is remiss.
> >
> >Perhaps what I should have been using is the phrase "Requirements
> >Specification" rather than that of "Use Models" as I have been.  Tim
informs
> >me in official "IETF-speak" that the "Requirements Specifications"
constrain
> >how this protocol interacts with others and what it actually provides
from a
> >technological perspective, and honestly that is all I have ever wanted to
> >make mandatory. I agree that it is the responsibility of other standards
> >orgs to produce end-user use models, i.e. ones in the real world, but
that
> >they cannot do that in most all instances with PKI without that
Requirements
> >Definition.
> >
> >To that end I would propose that all current in process and future works
> >including all RFC's and Drafts in play require this addition before being
> >advanced from where they are as of Today. To that end, I would call for
some
> >discussion and a vote on this matter. Take this as a formal motion before
> >the floor then.
> >
> >I move to change the Description Section of the WG Charter by:
> >
> >     1)    Better describing the functionality of the PKI WG and moving
the
> >bulk of the first paragraph (everything after the first sentence) into a
> >separate paragraph called "Accomplishments to date:"
> >
> >     2)    Supply a better description of PKI technologies as the
building
> >blocks of trust (we as a group will have to work on this)
> >
> >     3)    Supply a process statement within the group about how
technologies
> >are submitted and the operating proviso under which they will be
evaluated.
> >
> >     4)    Supply a Requirements Section statement as part of #3 above.
> >
> >     5)    Supply an administrative description of the Groups Processes
and
> >Management as well as how it works (or doesn't) with other Standards Orgs
> >since this is becoming more and more important to PKIX.
> >
> >Todd Glassey
> >
> >
> >----- Original Message -----
> >From: "Stephen Kent" <kent@xxxxxxx>
> >To: <ietf-pkix@xxxxxxx>
> >Sent: Tuesday, November 13, 2001 10:58 AM
> >Subject: Re: Software for PKI
> >
> >
> > >
> > > Folks,
> > >
> > > IETF working groups produce standards that vendors and users may or
> > > may not choose to employ. Ultimately, irrespective of whether we
> > > produce use cases or business cases for the work we do, the
> > > marketplace will decide if the standards are beneficial and relevant.
> > > Thus the value of the added documentation burden that Todd suggested
> > > is not clear. (The inclusion of rationale in standards is often a
> > > good idea, if it does not make the document too long or too hard to
> > > read. The PKIX Roadmap document is intended to capture much of the
> > > rationale and arguments associated with the development of PKIX
> > > standards. This is more than most WGs do in this respect.)
> > >
> > > The IETF imposes certain requirements for advancement of documents in
> > > the standards process and it is not obvious that the PKIX WG is
> > > unique in a fashion that requires or motivates deviation from the
> > > procedures by which the rest of the IETF operates, in this regard.
> > >
> > > We make decisions about the potential utility of a proposed work item
> > > when we adopt the item for the WG, e.g., add it to the charter. This
> > > decision ultimately rests with the WG chairs, who decide based on WG
> > > list discussions and based on their experience. I am aware of no
> > > precedent in the IETF that requires the sort of documentation Todd
> > > has suggested as a normal part of developing IETF standards, and thus
> > > I do not envision adopting this proposal as part of the charter for
> > > PKIX. I submitted the revised PKIX charter to the Security Areas
> > > directors several weeks ago and when they approve it, it will be
> > > posted to the IETF web site.
> > >
> > > The discussion that has taken place under the subject heading has
> > > been very wide ranging. Much of the discussion centered on "what's
> > > wrong with PKI." This discussion often failed to make the critical
> > > distinction between problems associated with implementations of PKI
> > > technology, problems with specific PKI models, and problems with PKI
> > > standards. This WG is not responsible for broken implementations. We
> > > are not responsible for marketing hype claiming that PKI is a
> > > panacea. We are not responsible for the ways in which people may
> > > choose to use PKI technology, which may be a bad fit for their
> > > businesses. We are responsible for creating standards that are
> > > technically accurate, comprehensible, and which we believe address
> > > some non-trivial range of problems associated with reasonable uses of
> > > PKI technology in the Internet. This is a sufficiently difficult task
> > > that we are probably well advised to focus on it.
> > >
> > > Steve
>