You seem to be conflating my role, as Chair, with HARICA and how HARICA
evaluates changes in ballots.
I'd like to start off by clarifying that each Member (HARICA as one of
the voting Members), reviews each ballot independently and votes after
evaluating the changes of each individual ballots. When a ballot passes,
this means that each Member must prepare for the changes to be effective
as soon as the IPR period is over. This has nothing to do with having
2-3 ballots being added in a single new version of the new Guideline,
because the Member has already been aware of the upcoming changes
because of the already voted ballot. This is my personal understanding
of the situation, and I would even say that it's common sense.
As the Chair, to the best of my ability I interpret the Bylaws, and with
the help of the Vice Chairs (who have worked with me as officers for
almost two years) I am ultimately responsible for producing the
necessary documents and all other activities according to the Bylaws.
Aggregating ballots to a single version of a Guideline is not
prohibited, it has been used several times already, yet you found an
opportunity to attack me personally and imply things for HARICA that are
totally irrelevant with this issue.
More answers inline.
On 2020-09-16 6:13 μ.μ., Ryan Sleevi wrote:
On Wed, Sep 16, 2020 at 2:12 AM Dimitris Zacharopoulos (HARICA)
<[email protected] <mailto:[email protected]>> wrote:
On 2020-09-16 2:43 π.μ., Ryan Sleevi wrote:
On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA)
<[email protected] <mailto:[email protected]>> wrote:
On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
Sure, I can do that but in any case I forwarded it the
argument on the list. I also support this argument that
aggregating new versions of the documents saves time.
While you're the only one qualified to measure whether it saves
time, as a browser, this raises a host of questions for
understanding how CAs are staying abreast of changes and
reviewing them. This is actually critical, given that I've seen
multiple CA incidents where CAs have reported that they have
trouble staying abreast of changes, even for ballots they voted
for! So it suggests to me that some of the current ways that CAs
are keeping up to date are flawed, or lend themselves to easy
mistakes.
I hope you realize that this is not related with Forum's
activities. The Forum produces standards/Guidelines. Whether CAs,
Relying Parties adhere to those standards/Guidelines and update
their processes/products is a different issue.
I hope you realize that questions about the working mode of the Forum
impacting the ability to make reliable use of the Forum's work product
is, of course, essential to the continued value and participation in
the Forum.
If the view of the Chair of the Forum is that the Forum should not
consider how usable its work product is, which is voluntary standards
that can be used by Browsers, then I think it raises deep concerns
about the value of the Forum.
I still can't find the relevance of a CA doing its due diligence to
review the ballots that were voted, with the production of an aggregated
or individual Guideline. Perhaps someone else with better understanding
of the issue could rephrase it so I can see how these two are connected.
Dean, Wayne, can you please assist here?
Naturally, if we had the specific member, we could ask them to
describe their process for staying aware of changes, and why one
document makes that easier. For example, I'd be deeply concerned
if a CA was looking at an aggregated SC28+SC35, since they might
mistake a meaningful normative change as a cleanup or
clarification, or similarly, mistake or overlook an important
clarification because they're distracted by logging changes.
I don't think that's necessary. It seems very reasonable to me
that reviewing one redline document that introduces changes from
two or three ballots, is more convenient and simpler than having
to review two or three redline documents to reach the same result.
If there are questions about a new requirement or an introduced
change, the discussion of the specific ballot that introduced the
change is there for anyone to review and get a better
understanding on the rationale and get clarifications. In some
cases, even that is not enough, and we encourage people to submit
questions to the [email protected]
<mailto:[email protected]>, or if these questions come from
Members, they can post questions directly to the WG public mailing
list.
I am concerned that you're allowing your personal judgement, which
unfortunately is seemingly clouded by confusion of the issues, to
impair your ability to effectively and respectfully Chair, by
selectively picking and choosing which viewpoints are respected.
My "personal judgement" on this topic was after consulting with the Vice
Chairs and having exercised this practice 3-4 times already, publicly
and transparently. So I don't understand where all this is suddenly
coming from. If you had concerns about this practice, you had several
opportunities to express them. Nevertheless, you expressed your concerns
now, so we are discussing, publicly, to see if your concerns are well
founded so we can make progress addressing them.
I realize you believe it's very reasonable, but that appears to be a
lack of familiarity with the issues we, as browsers, are seeing. As a
Forum CA Member, that's concerning for HARICA, but as a Chair, that's
even more inexcusable.
No, that's not the case at all. It wasn't just me that though it's very
reasonable. As I already mentioned, we had a discussion with the vice
Chairs before following this aggregation practice. Right now, you are
the only person that thinks that aggregating the final Guideline is not
reasonable.
Ballots are specifically produced to group their logical related
changes within a single ballot, to make it clear the many related
things that need to change in order to accomplish a particular goal,
as stated in the Ballot. The aggregation approach destroys that
contextually relevant information.
The aggregation approach is only in the final Guideline, not the ballot.
Each ballot is voted independently and each CA Member knows the changes
that are voted on.
Your further suggestion that it's confusion that a CA is actively
aware of, and thus can and should avail themselves of questions, when
that cannot be further from what I stated. It is the lack of awareness
that causes the issue, and this lack of awareness is heightened by the
increasing number of changes that come in aggregation.
This doesn't make much sense to me. The changes will become effective on
the same day, regardless if we publish 1 version of the Guideline or 3.
Awareness-wise, it's the same and I would argue that it's easier for a
CA to send one updated document to their compliance department to check
what becomes effective, than three documents. All the important
information for each change is in the independent ballots that don't
just include the changes but also some rationale and even discussion
that takes place before the vote.
The Chair has no control of when ballots enter the discussion and voting
period. Proposers should be aware of other ballots being in the
discussion period and should know when additional changes will become
effective almost at the same time.
If proposers believe that the volume of changes is a critical point to
adoption from the CAs, then it would make more sense to break down
ballots, like the browser alignment ballot, into smaller ones, with
enough time in between, so that CAs can adapt to fewer changes before
introducing another set of changes.
As a member, HARICA represented that it was overloaded with reviewing
changes, and concerned about the quality of results at the continued
cadence in light of COVID. I would expect that you (HARICA), of all
organizations, should thus be familiar with the risk of many changes
causing important changes to be *overlooked*, rather than misunderstood.
HARICA was overloaded and thus we respectfully requested from the SCWG
and the proposer of a particular ballot, to delay the voting so we can
have more time to review the changes of *the Ballot*. Once the ballot
passed, it means it will eventually become effective. It will become
effective when the next version of the Guideline document is published.
Whether that document contains changes of more than one ballot, is not
an issue, because as a CA HARICA has to adapt and comply with everything
that this document introduces.
Ultimately, I understand that you, individually, have a workmode that
works for you. However, that workmode is demonstrably not working in
industry. As Chair, I'm requesting you do not impose your preferences
on the Forum, particularly when doing so impairs and impacts the
ability for CAs to adhere to these Guidelines, and thus greatly
diminishes the value of the Forum as a producer of such documents.
Wait, are you implying that the aggregation of guidelines has anything
to do with impacting the ability for CAs to adhere to the produced
Guidelines? And you are accusing me of being responsible for that? I
hope this is just another misunderstanding otherwise I would kindly ask
this to be clarified by the Vice Chairs because this sound like an
unfounded accusation.
Again, the relevance of the Forum is how well it serves industry, and
that has to be acknowledged as being how well its voluntary
Guidelines, such as the Baseline Requirements, provide value to
browser members as an alternative to direct vendor auditing, as
practiced in many other ISMS-vendor relationships.
Aggregated guidelines or separate guidelines, the result is the same,
the work product is the same, Browser Members will effectively supervise
the same requirements whether that is in one or three documents being
published on the same day. They will supervise the last version of the
Guideline that will include the changes of the other two, so I honestly
don't understand why we seem to have such a big disconnect.
My priority here is to serve the SCWG and the Forum in a compliant
and productive manner. If the SCWG Members have no objection to
the current practice of aggregating Final Guidelines when we have
timelines that permit this aggregation, I will continue with this
practice.
Our concern is with aggregation, and while we recognize the value it
brings to making the Chair's role easier, our belief is that it
actively harms compliance and comprehension, and thus request you stop.
Ok, then we will stop this practice going forward. That's all you had to
say. I expect Members to raise concerns when they think something is
off. I don't consider me, or Dean, or Wayne to be perfect in
interpreting the Forum's documents although in this particular case we
decided on a practice that was not forbidden (you also agreed to that),
had good reasons to do it, and went ahead with it without objections
from Members.
Despite personally feeling that the final result is ultimately the same,
I will respect your request and stop this practice.
Can you point me to where you believe this practice is forbidden?
Can you mention where I said it was forbidden? I'm not sure how
best to answer your question, and so I think this might require
disentangling what you think I said versus what I said.
Perhaps I misunderstood this particular statement:
* "The IP review necessitates the production of the Final
document, so that sounds like more work, rather than less, and
it seems to run in the same problem of commingling outputs."
I'm glad we are in agreement that this practice is not forbidden
and, of course, not required.
I hope you can recognize the logical fallacy in your statement, which
I hope we can chalk to ignorance rather than malice.
You indeed misunderstood the statement, which is discussing Section
4.1 of the IPR policy.
I used your words. You said "there's nothing in our IP policy I'm aware
of that requires you to send them as a combined review." and I believe
you implied it was not forbidden. I may have expressed it in bad English
so you can address it to anything else other than malice. Even the fact
that you would consider me being "malicious" after my efforts and
contributions to this Forum, makes me sad and disappointed.
I honestly don't mind the extra work of creating more
Guidelines but it seems pointless to create a document that
nobody will ever read because it will be valid for just a few
seconds.
I described, at length, why it was meaningful, from both an IP
perspective and from a document versioning perspective. It
sounded like you agreed with, or at least understood, those
challenges, so I'm not sure I understand what you're trying to
say here.
What I'm trying to say is that creating a document with version
1.2.2 and 5 minutes later another with version 1.2.3, makes 1.2.2
valid for just 5 minutes because everyone will just download and
read 1.2.3 that incorporates the changes introduced in 1.2.2. It
seems meaningless (from a practical standpoint) to create 1.2.2
since it will not be of use by almost anyone.
I've repeatedly described to you how it's used, and you repeatedly
appear to be dismissive of this. At this point, it's unclear to me
whether this is deliberate, but I would encourage you that if
something isn't clear to you, perhaps forming questions rather than
stating absolutes would be useful.
This goes back to the questions you dismissed as outside the remit of
the Forum at the outset, so perhaps by not being so dismissive, we can
find common ground. Understanding the value of 1.2.2 vs 1.2.3
necessitates understanding how CAs are reviewing and integrating
changes, and working to identify what good practices are to ensure
good compliance. What we unambiguously know is that present practices
are failing, and most recently, related to an aggregated version you
produced. I'm sure it's easy to dismiss this as the "problem of the
CA", but the very purpose of incident reports is to help effect
systemic change. One of the systemic issues involves understanding how
the work product is consumed, and that's absolutely in the realm of a
Forum designed to help encourage good practices.
I already responded to that earlier.
Documents with the *same effective date* would create a lot
of confusion to CAs and Relying Parties.
I'm also not really sure I understand this. It appears you're
saying here that CAs ignore the version, and focus on the date,
while in the past, you've specifically objected to changes in
versioning, because you've argued that CAs focus on the version.
Are you saying that having a BRs 1.2.0, 1.2.1, and 1.2.2, and
1.2.3 creates a lot of confusion to CAs and Relying Parties?
Because that's /four/ versions within the 3 day window of the
Bylaws. (14 Oct - 16 Oct).
But if the review periods end Oct 14 - 16, I will prefer to spend
one day working with the final guidelines and post the results. I
probably don't want to spend one day producing 1.2.1, publish the
resulting document to the mailing lists, update the web site, then
do the same the next day for 1.2.2. This means that all these
Guidelines will be sent (and thus become effective) on -say- 16 Oct.
OK, so don't run for Chair then?
Wow! After all the work I did for this Forum, is this what I deserve?
This statement made me even more disappointed and sad. I hope other
Members don't feel the same way about my work at the Forum and how I
exercised my duties as Chair.
From a compliance perspective, all 4 documents (with 4 distinct
versions) would be effective on 16 Oct which might create
challenges and confusion. I would like to avoid that an either
aggregate or ensure we have different effective dates so that at
every single day there is one and only one normative version of
the Guideline in effect. Hope this makes more sense then the
previous attempt.
Thanks. Then it is clear that your argument has limited basis in
demonstrated reality, as you appear to be unaware of it being harmful,
and appear to be shutting down discussion about improving it.
I believe your assumptions that aggregating guidelines lead CAs to be
unable to follow the introduced changes are unfounded, as I explained
earlier. CAs have to adapt to the changes that become effective
regardless if they are included in 1, 2 or 3 versions of the Guideline
being published on the same day. The latest version will include the
changes of the previous documents issued on the same day.
In conclusion, as mentioned, we will stop this practice going forward.
Please let me know if you would like to reset the Review period and
create two separate review notices which will produce two distinct final
guidelines and then figure out how to combine them (since both redlines
will be against the current version).
Dimitris.
_______________________________________________
Public mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/public
