Subject: BER vs DER - a new path?

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 14 Oct 2004 22:52:39 -0400

We've been arguing about this DER vs BER issue for a while now.  This is 
the main blocking issue preventing PKINIT from making progress.  There are 
several other things to be hammered out, but I doubt that any is likely to 
be as contentions as this has been.

I believed, and still do, that this is fundamentally an issue about 
practical interoperability.  I believed that by getting some of the vendors 
on both sides of the issue together to discuss it in more detail, it would 
be possible to arrive at an answer that the working group could accept.  It 
is now clear to me that that was not the case.

We have made no tangible progress on this issue, and it does not appear to 
me that we are likely to do so soon.  I have discussed the matter with 
Russ, and based on his advice I have three approaches to offer the working 
group.  I am, of course, open to other proposals.

(1) An alternative decision process
    There is a document (draft-hardie-alt-concensus-02.txt) which
    describes an experimental approach that can be used to resolve
    a situation in which a WG believes that a choice MUST be made
    in order to make progress, but cannot come to a concensus.  The
    document describes several possible procedures that could be
    used, along with conditions on when such a method can be used.

    Russ and I believe that if the WG were to take this approach,
    the procedure described in section 4.3 would be appropriate.
    Basically, this involves the random selection of a qualified
    participant, who would then be empowered to select from among
    the choices made available by the working group.

    I expect this approach would require at least one month, and
    quite possibly longer.  It requires a formal working group
    last call, followed by a period of three weeks during which
    participants may volunteer to serve as the decision maker,
    followed by enough time for the IETF executive director to
    select a volunteer through a random process similar to that
    used to select nomcom members.  In addition, a separate I-D
    must be published for each option.

    The delay imposed by this option is long but bounded.

(2) We can ask Russ to make the decision in his capacity as AD.
    He has offered to do so if the working group so requests.

    The delay imposed by this option is probably short.

(3) We can surprise me by arriving at a consensus.

(4) We can continue to argue about this indefinitely.

I can't force the group down any of these paths.
I would like to see comments on which of these approaches participants 
would prefer, hopefully followed by a quick consensus.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Oct 2004 23:19:57 -0400

I support (2), Sam's (3a), Sam's (3b), and (4)

There is a fifth option available where we fork the spec
and let the marketplace determine which version comes out
on top.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Oct 2004 23:10:52 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> (1) An alternative decision process There is a document
    Jeffrey> (draft-hardie-alt-concensus-02.txt) which describes an
    Jeffrey> experimental approach that can be used to resolve a
    Jeffrey> situation in which a WG believes that a choice MUST be
    Jeffrey> made in order to make progress, but cannot come to a
    Jeffrey> concensus.  The document describes several possible
    Jeffrey> procedures that could be used, along with conditions on
    Jeffrey> when such a method can be used.

    Jeffrey>     Russ and I believe that if the WG were to take this
    Jeffrey> approach, the procedure described in section 4.3 would be
    Jeffrey> appropriate.  Basically, this involves the random
    Jeffrey> selection of a qualified participant, who would then be
    Jeffrey> empowered to select from among the choices made available
    Jeffrey> by the working group.

    Jeffrey>     I expect this approach would require at least one
    Jeffrey> month, and quite possibly longer.  It requires a formal
    Jeffrey> working group last call, followed by a period of three
    Jeffrey> weeks during which participants may volunteer to serve as
    Jeffrey> the decision maker, followed by enough time for the IETF
    Jeffrey> executive director to select a volunteer through a random
    Jeffrey> process similar to that used to select nomcom members.
    Jeffrey> In addition, a separate I-D must be published for each
    Jeffrey> option.

Presumably we could cut corners provided no one objected to the
cutting of corners.

I would consider this option OK although not great.  The time is long
and the quality of the decision seems not so good.

    Jeffrey>     The delay imposed by this option is long but bounded.

    Jeffrey> (2) We can ask Russ to make the decision in his capacity
    Jeffrey> as AD.  He has offered to do so if the working group so
    Jeffrey> requests.

    Jeffrey>     The delay imposed by this option is probably short.

I consider this option fine.

    Jeffrey> (3) We can surprise me by arriving at a consensus.

I propose the following options because we might reach a consensus to do them.

A) We ask the S/MIME working group if they would advise us in this
matter.  They likely understand issues involved with low memory
footprint S/MIME implementations.  They also understand issues with
off-the-shelf implementations.  They may be in a better position than
we are to make a tradeoff.

B) I propose consensus by combat using champion selection rules
similar to medieval trial by combat.

    Jeffrey> (4) We can continue to argue about this indefinitely.

I support this option as well.

--Sam

---

From: Brian Tung <[email-masked]>
Date: Thu, 14 Oct 2004 22:11:41 -0700

> and let the marketplace determine which version comes out

Oof.  Over my (by then very likely) dead body.

Brian Tung <[email-masked]>