Re: [W3C Web Crypto WG] Security considerations and recommended algorithms bug

On Mon, May 12, 2014 at 2:01 AM, Harry Halpin <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/12/2014 10:56 AM, Ryan Sleevi wrote:
> > On Mon, May 12, 2014 at 1:53 AM, Harry Halpin <hhalpin@w3.org>
> > wrote:
> >
> >>
> >>
> >> On 05/12/2014 03:36 AM, Ryan Sleevi wrote:
> >>> Virginie,
> >>>
> >>> Can you please comment on what you mean by "Blocking Bug"? That
> >>> has a
> >> very
> >>> specific connotation within the W3C process.
> >>
> >> I think this is what Virginie means:
> >>
> >> Note that for each comment we get during Last Call, we have to
> >> "formally address all issues raised by Working Group
> >> participants, other Working Groups, the Membership, and the
> >> public about the Working Draft." [1]
> >>
> >> Note that comments out of scope of the charter don't count. Rich
> >> Salz would count as "the public".
> >>
> >> In particular then, we have to "In the context of this document,
> >> a Working Group has formally addressed an issue when the Chair
> >> can show (archived) evidence of having sent a response to the
> >> party who raised the issue. This response should include the
> >> Working Group's resolution and should ask the party who raised
> >> the issue to reply with an indication of whether the resolution
> >> reverses the initial objection." [2]
> >>
> >> Simply put, usually we need to send an email before May 20th
> >> stating that "Here's what we did (or did not do) and why in
> >> response to your review. Can you live with the response?"
> >>
> >> If the answer is "yes" or no answer, then we move to CR. If we
> >> get a "no", then we have to continue dialogue until a reasonable
> >> solution that both the WG and the reviewer can live with until we
> >> exit CR. The point of Last Call is to get these kind of comments
> >> finished before really focusing on the test-suite.
> >>
> >> I'm sure we can find a reasonable solution!
> >>
> >> cheers, harry
> >>
> >>
> >> [1]
> >> http://www.w3.org/Consortium/Process-20010719/tr.html#last-call
> >> [2]
> >>
> http://www.w3.org/Consortium/Process-20010719/groups.html#formal-address
> >>
> >>
> >>
> >
> >>
> Harry,
> >
> > Thanks for the detailed response. I am familiar with each of those,
> > and that's why I sought Virginie's clarification.
> >
> > In this context, *every* bug is filed is a blocking bug, which is
> > why I do not understand why special attention has been provided.
> >
> > Further, in this context, a response has been provided explaining
> > things.
> >
> > So the question is, what makes this different than bugs such as
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25387 ? Arguably,
> > nothing.
>
> As long as the author responds to your response that they are
> satisfied or they never respond, then we can assume they are
> satisfied. If they respond they are unsatisfied, then we just keep
> iterating with them until a reasonable solution is found. Rich does
> seem unsatisfied, as noted by the "kind" of bug he filed.
>

Harry,

The process you described is with respect to Formal Objections.

Can you please provide a reference for where the W3C sees public comment as
being such? The process you've described is a process that can make it
impossible for a group to progress, by allowing a member of the public to
refuse to accept a solution, so I doubt the process is, indeed, as you
described.

Indeed, the process described at
http://www.w3.org/2005/10/Process-20051014/policies.html#formal-addressdoes
NOT indicate "keep iterating with them until a reasonable solution is
found". Instead, it states "a reviewer cannot block a group's progress"

The only requirement is that for every issue raised, a substantive response
(such as technical reasoning) and acknowledgement of that response is all
that is required.

This seems to be further reflected in
http://www.w3.org/2005/10/Process-20051014/tr.html#doc-reviews



>
> Working Group members can also "formally object" but luckily I don't
> think we have that situation.
>

Likewise, the process document doesn't seem to make it clear that it's
"only" WG members that can Formally Object.


>
> Before we exit Last Call on the 20th, I'll make a document showing the
> status of the bugs and how we have resolved them.
>
>   yours,
>     harry
>
> >
> > Cheers, Ryan
> >
> >
> >>
> >>>
> >>>
> >>> On Fri, May 9, 2014 at 6:12 AM, GALINDO Virginie <
> >>> Virginie.GALINDO@gemalto.com> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> This is just to bring your attention on the fact that we
> >>>> received a “blocking bug” from Rich Salz and Kenny Patterson
> >>>> about the need to
> >> improve
> >>>> our security considerations in *Bug 25607* [1]
> >>>>
> >>>> Ryan is working on it, but views/support from all
> >>>> implementers would be helpful …
> >>>>
> >>>> Regards,
> >>>>
> >>>> Virginie
> >>>>
> >>>>
> >>>>
> >>>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------ This message and any
> >>>> attachments are intended solely for the addressees and may
> >>>> contain confidential information. Any unauthorized use or
> >>>> disclosure, either whole or partial, is prohibited. E-mails
> >>>> are susceptible to alteration. Our company shall not be
> >>>> liable
> >> for
> >>>> the message if altered, changed or falsified. If you are not
> >>>> the
> >> intended
> >>>> recipient of this message, please delete it and notify the
> >>>> sender. Although all reasonable efforts have been made to
> >>>> keep this transmission free from viruses, the sender will not
> >>>> be liable for damages caused by a transmitted virus
> >>>>
> >>>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTcI3yAAoJEPgwUoSfMzqc9TMQALSSK+PoYQXBdFdA0mgxo0pj
> DxiO4n7jq/tJnIW81xVoee83bC0OFDZthpJc7y+EWk4KwDZDy/n7SP76VIElZfO0
> I6XQIAS7XihWdO6RarV/VPddQZfhWpsKErrShqIAFpydgPfxJwXLfK5KPEHjmqeS
> 0IpmIc49Uby4GVzXOhdqV/XRyZLqvxxnaz4cQTBU6p+Q6Q6Keklz4czK49RJqxdm
> 7Nz6SSId2BraJ/n5BliJz3q7RiJv/EDqk7pybiqC8ZjUEtuNUlRx+wgzCNYRoKen
> F0nSWvkRjOxWmw1W7TssLOGHoQIJDvI1Lk4xzpVLqojS9eSxKh1BzmCZzl24gT8p
> v6Orfq2T/9vVyGfv/Tp79RxXKiqEObROcg/LrLtoS97UULMdVHZplaHYgybmxQ14
> 237E3Fa/gBEMzxf1j7MCJm+AAcb/W6ny3qnvvjHbMdaQs4iaynPjjbd2nvBT0ou9
> kYyfzL1T4iCT8tXtMKkGzSM8iOPtW9VZGKvha6elVjzRLuOntTXQ6FmZxQDL5Qyb
> PzCGtTR7Yd607r2AZmg4dtsgPMZ/7WIKu+8AbSPpDV56NhDSyMW6aNLgK1LuXi+d
> IGwdodmGvUKRkqGpM7WABgcQK+1BcodT9QqwHa2PW8wS8xB0UjY0AmJbknEPbWqI
> VhxAqgE8RNq/83y9nByF
> =5lI7
> -----END PGP SIGNATURE-----
>