RE: On optionality

On Nov 27, 2012 9:12 PM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
>
> Reading this thread, I feel that it's important to reinforce a factual
point that Mark made below.  Removal of pre-provisioned keys from the main
specification was *not* discussed at the meeting.  There is no demonstrated
consensus to do so.

As recorded consensus during the face to face, and as proposed on the list,
removing key storage and using existing web storage mechanisms is what was
proposed to and agreed upon, and has been done.

I am aware that pre-provisioned keys are still a matter of discussion. This
is not disputed. We discussed them until the end of our last call, as we
continue to do so for our next call. It is an orthogonal issue as to where
**and how** pre-provisioned keys are to be handled. I am not claiming
consensus has been reached on that. It is still an open issue in the spec
and a point of discussion.

> I believe that it would be a breach of the working group process to do so
without working group consensus.  Changes of that nature are beyond the
discretion afforded an editor, at least as I understand the role.
>
> As an editor (of IETF specs), I'm well aware that the editor's job is to
implement the working group consensus - not to implement my own viewpoint.
 I assume that it must be the same in the W3C.  For the process to work,
that's the way that it must be.
>
>                                 Best wishes,
>                                 -- Mike
>

As Harry is frequently fond of reminding me, the W3C process is markedly
not the same as the IETF. This is spelled out in
http://www.w3.org/2005/10/Process-20051014/

In the same way that consensus is permitted during face to face and
telecons, there is significantly greater flexibility afforded to authors
and editors of specs. You find this very specially documented within the
Editing guidelines in the W3C, and you can see this further described in
the webapps WG for a practical application. For example, both documents
clearly establish and affirm that editors are not required to bring
everything to the list first, which is very different than IETF. In fact,
several groups (including the quite successful WebApps WG) state their
process as "Edit first, review later".

Further, consensus is not required for every change, but rather for every
PubRules progress change. Our next step is LC in Feb 2013, and the process
is described at
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call- or on
the next *formal* publication of a WD (not the weekly editors
updates)

Until such a time as LC/PR/CR, specs remain highly malleable and subject to
constant change as discussion - and proposals - change. Such changes do not
require consensus or voting - and indeed, Editors, as Authors, are expected
to be proposing and expanding text throughout to serve as discussion
points. This remains true even as we publish WDs for the heartbeat
requirements. This is, as you can plainly see, **very** different than the
IETF model. Consensus is measured when advancing the document - CR, PR, REC
- not line by line, edit by edit, feature by feature - and until
advancement, not even issue by issue. The reason it has been as such has
been due to lack of good diffs - solved by Mercurial now.

Regardless of these important facts about editorship, it is clearly evident
these things: there was recorded clear consensus for removing
**KeyStorage** (and any other form of custom **storage**, as affirmed and
voted in the F2F) and there is not clear consensus on where and how
pre-provisioned keys work. For these reasons, it is left as an open ISSUE
to be resolved - with the previous strawman removed - as we review
proposals. Per W3C rules, we **do not** need to reach consensus until
advancing a stage in the process, and that ongoing Editor's drafts are just
that - Editor's drafts.

Because this is such a hot topic, it has been removed until we reach
agreement if, where, and how pre-provisioned keys are addressed. This is
not a unilateral declaration of LC - this is just reflecting "Work in
Progress. TBD."