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.
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], or if these questions come from Members, they
can post questions directly to the WG public mailing list.
Indeed, I'd be quite worried if someone was specifically using the
Redline PDF for reviewing changes (in the full document), without also
looking at any supporting discussion and included redlines, to also
make sure they have an at-a-glance understanding of what's changing.
Of course, I'm not a CA, so it's much better to hear, in a CAs own
words, the processes they employee, so they can describe why one
document saves more time.
Selfishly, my priority is not in saving time for CAs, if saving time
risks correctness. I'd much rather ensure CAs do the right thing, and
consistently implement it, even if it means they have to take more
time to be careful and thorough. This is no different from me wanting
to make sure my surgeon was certain my spleen needed to be removed,
before scheduling the surgery, rather than just have them open me up
and see what looks interesting or relevant.
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.
Once I have the review period redline ready, it usually takes
between 30 minutes to 1 hour to create the final documents,
upload them to the wiki (the word versions), produce the
final PDF versions and upload them to the public web site.
Wow! I wouldn't have expected this to be more than 5 minutes, so
that's a really surprising amount of time! Do you know where the
bulk of the time is, so we can prioritize? That said, it sounds
like your response here aggregated 2-5 - is that roughly right?
Yes, because to produce a Final Guideline and a redlined version
in a non-GitHub version is quite painful. In the GitHub version,
things are faster but again I need to create the redline manually,
compare the two .docx versions produced by GitHub (before and
after the merge to Main), check everything like track changes
mode, make sure the ToC is not tracked and other minor details.
I'm not really sure I understand this process. It might be useful to
have a demonstration on an Infrastructure WG call, to best see the
challenge. Beyond helping the (presumptive, given single candidate)
future chair, it might also help figure out opportunities for
improvement here :)
We did try to capture the steps in
https://docs.google.com/spreadsheets/d/1gTHJfPoGgv-1oXCtGxqxg887iSyCnPF0bSYfrc4JD30/edit#gid=0
but this probably needs to be updated with more details regarding the
preparation of redlines and final guidelines.
Even going through this page every time to make sure nothing is missed,
takes time :-) I'd be happy to discuss this process further at an
Infrastructure Subcommittee call.
Then, create a PDF without the formatting comments (otherwise the
PDF contains formatting changes in the redline which doesn't look
good). Then make the changes to the web sites, wiki, etc. I wish I
could make that in 5 minutes :-)
This would probably require having our entire public website on
GitHub and automate the process. That would be really something!
Certainly, a number of other SDOs have managed this in a variety of
forms! So it's not at all inconceivable, and that's why I'm trying to
understand the process, so we can of course make it easier and
simpler; for you, and for whomever the future Chair(s) may be. The
more time we spend on process, understandably, the less time we spend
on progress, and so the more that can be shared about the work
involved, the better we can improve things.
I am aware of some and although it's not inconceivable, it's certainly
very difficult to accomplish considering that we have repeatedly
discussed doing a review of our existing public web site, remove
obsolete information and update what needs to be updated. I hope the
next chair(s) will have the energy to drive this process and update the
public web site.
Would your concerns be addressed if we had a
separate/distinct IPR review for each ballot and once each
IPR review is cleared with no essential claims filed, produce
an aggregate document, or you still prefer separate Final
documents with distinct versioning to be created? What do
others think?
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.
During my entire time as Chair of the Forum and the SCWG I have
tried to perform my duties following the Bylaws to the best of my
knowledge and understanding. Just in case I had misunderstood
these requirements, I shared this process with the Vice Chairs who
are native English speakers. We all agreed that aggregating the
final Guidelines was allowed and not in conflict with our Bylaws.
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 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.
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.
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.
_______________________________________________
Public mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/public
