<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/3/2017 12:47 πμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Dimitris,
<div><br>
</div>
<div>Unfortunately, it doesn't sound like we're on the same
page. While I appreciate the effort you and Ben and others
have worked on this, I think this proposal creates new
security vulnerabilities in both ambiguity and loopholes.</div>
</div>
</blockquote>
<br>
Nobody can claim that we didn't try to get on the same page :) I
also (and surely other members) appreciate your efforts to make sure
the policies and standards are secure and unambiguous and your
opinion is always important and respected.<br>
<br>
<blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>My request would be that you consider withdrawing the
ballot or that members who support this change to No, so that
it can be worked on in the policy group to resolve these
issues. I would suggest that given the issues are, in part I
suspect, due to misunderstandings about the concerns/threats,
it might be best to table this until after the F2F.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
I can't imagine that Mozilla, Entrust, Globalsign, Digicert (that
already voted "Yes") didn't read through the ballot and didn't
consider these misunderstandings. As I've heard people say in this
Forum, perfect is the enemy of good. In my previous replies, I tried
to engage more members who feel that the current language of the
ballot creates more ambiguities than it fixes. Judging from the
silence from other members, I believe that the benefits outweigh the
downsides creating an "acceptable" ballot, which could very well be
improved very soon. In fact, it would be great if you could offer
some edits to the ballot to make it even clearer. The intentions of
the changes introduced by the WG have been clear and the main
concern you raised (audits for all Subordinate CAs) are covered by a
BRs part which remains untouched (the first paragraph of Section
8.1). If we could proceed with an updated ballot (with fewer changes
so we can address the specific concerns you still believe to exist)
right after the F2F, there is no risk.<br>
<br>
Even though HARICA proposed the ballot, it was a WG effort so I
cannot take full responsibility of withdrawing the ballot or
suggesting members to vote "No" without any feedback from other
endorsers or other members who I would like to reply to this, and
offer their opinion, especially if they feel that the ballot must be
withdrawn. As this is a public discussion, every voting member can
judge on their own for what's best, after reading this thread.<br>
<br>
You also referred to Peter's email
(<a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/policyreview/2016-November/000358.html">https://cabforum.org/pipermail/policyreview/2016-November/000358.html</a>).
Peter participated in some WG meetings after this e-mail and we
discussed this and so many other variations. They all had some pros
and cons, so we ended up with the proposed language on this ballot.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<br>
<blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>For example, your response regarding audits is demonstrably
incorrect - and though I believe it emerges from a
misunderstanding of effect, even though we share the common
goal - and that alone is reason for serious concern.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 28, 2017 at 2:09 AM,
Dimitris Zacharopoulos <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:jimmy@it.auth.gr"
target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_302437843593208024moz-cite-prefix">On
27/2/2017 9:21 μμ, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 27, 2017 at
10:52 AM, Dimitris Zacharopoulos <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
</blockquote>
<div><br>
</div>
<div>I think this is a potentially
problematic definition, in that it
relates to the scope of the
operations of the audit, as well
as matters below that I highlight.
I'm hoping the proposers and
drafters can clarify (or link to
previous discussions) as to the
reason in which "or its Affiliate"
was introduced into these
definitions, or to highlight where
it was already a natural and
existing part of these
definitions.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Peter already provided some clarity for this.
The "Affiliate" language was not introduced by
this ballot. It was already mentioned in
several sections of the BRs (6.1.1.1 "CA Key
Pair Generation", 6.1.2 "Private Key Delivery
to Subscriber", 6.2.6 "Private Key Transfer
into or from a Cryptographic Module", 7.1.2.2
"Subordinate CA Certificate" and 7.1.6.3
"Subordinate CA Certificates").<br>
</div>
</blockquote>
<div><br>
</div>
<div>Unfortunately, I think the concern still
remains that this is a subtle introduction that
goes from being scoped to specific sections (as
you've noted) to now being a foundational
concept, which unfortunately 'weakens' the BRs,
I believe.</div>
<div><br>
</div>
<div>I totally understand and appreciate the
intent to align here, especially for the cases
Peter noted, but I want to especially make sure
to highlight the issue that "or the Affiliate"
can be problematic from a set of scope of
audits.</div>
<div><br>
</div>
<div>Basically, what's being asked for on this
ballot is a trade-off from being logically
bugged (and I agree, this is an issue we should
fix) to something that is procedurally weaker,
and I'm trying to figure out what the plan is to
align. From both you and Peter's response, it
sounds like you don't believe further changes
are needed, and this is concerning.</div>
</div>
</div>
</div>
</blockquote>
<br>
As far as this ballot is concerned, which is only to
clarify the use of the term "CA", it does not "weaken" the
BRs in any way. The use of the term "Affiliate" and policy
around it, is already there. I personally (and maybe
others) feel that the "Affiliate" issue needs to be
further discussed and even be removed as a way of
providing better conditions but this is something outside
the scope of this ballot.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> Peter's answer should
cover this. Your follow-up questions challenge
the fact that the current BRs treat Root
Operator's "Affiliates" in a different way
than the non-Affiliates but this is a policy
matter and should be discussed separately. In
any case, I don't think it changes the fact
that all Subordinate CAs (whether internally
or externally operated) need to be audited. In
the case of Internally Operated Subordinate
CAs, the audit might be covered in the Root
Operator audit, and this information should be
included in the audit scope.<br>
</div>
</blockquote>
<div><br>
</div>
<div>That's the intent - but my question is, where
is it specified? I may have missed that, and
that was the point of raising these concerns: if
I'm misreading, and it's already addressed,
fantastic. But I don't believe it is, hence the
concern :)</div>
</div>
</div>
</div>
</blockquote>
<br>
8.1: "Certificates that are capable of being used to issue
new certificates MUST either be Technically Constrained in
line with section 7.1.5 and audited in line with section
8.7 only, or Unconstrained and fully audited in line with
all remaining requirements from this section". IMO, from
this reading, it is clear that all Subordinate CAs MUST be
fully audited or self-audited (per 8.7) if they use
Technically Constrained Subordinate CA Certificates. There
is no distinction about whether the Subordinate CA is
"Internal" or "External".<br>
<br>
"Affiliates" in the current BRs have different policy in
the following:<br>
<ul>
<li>The key generation ceremony SHOULD (instead of MUST)
be witnessed by an external auditor (6.1.1.1)<br>
</li>
<li>The Policy Identifier MAY (instead of MUST) be
present in the Subordinate CA Certificate and the
"anyPolicy" identifier MAY (instead of MUST NOT) be
used. (7.1.6.3).<br>
</li>
</ul>
I believe that's all there is to it.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> After several
discussions within the WG, it was agreed that
the most accurate technical language is that
"Private Keys sign Certificates".
Certificates, don't sign Certificates. </div>
</blockquote>
<div><br>
</div>
<div>I understand the "why". I'm more specifically
asking three questions:</div>
<div>1) Is my interpretation correct?</div>
<div>2) Is this desired?</div>
<div>3) Is there a plan to fix it?</div>
<div><br>
</div>
<div>From the rest of this section, I can
interpret your response as "1) Yes 2) No, not
necessarily 3) Not really, but we could come up
with one". I'm not sure if that really provides
the level of assurance when considering whether
to vote on this ballot, even though I agree and
understand the why, and am relieved it isn't
intended.</div>
</div>
</div>
</div>
</blockquote>
<br>
Your interpretation for 1) is correct regarding the
specific OCSP responder question.<br>
<br>
For 2), the WG's desire was to use technically correct
language in the entire BRs to describe the "signing"
process. You had a very specific concern about the OCSP
responder where RFC 6960 allows either the name of the
responder of a hash of the responder's public key as the
ResponderID so even that is taken care of. However, if
this concern remains, we will move to fixing it.<br>
<br>
For 3), if this concern remains, we will fix it. I would
like to ask if more members have the same concern, to
please speak up.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">So, according to your
example, if the ResponderID was the hash of
the Subordinate CA Certificate's public key,
it would not be prohibited even though that
key would be included in two or more
Subordinate CA Certificates. Perhaps the
multiple CA Certificates with the same
key-pair scenario is not entirely addressed.
We could update the BRs to specifically
include language for the ResponderID
information, if you think people would be
puzzled about what information should be
included in that field.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Whether we address this by specifying
language fro the ResponderID (which seems overly
specific) or by addressing the general concern,
I'd like to see a concrete proposal to address
this, ideally before voting concludes.</div>
</div>
</div>
</div>
</blockquote>
<br>
So far, the WG thought that the phrase "signed by the
Private Key associated with a Root CA Certificate or a
Subordinate CA Certificate" was technically correct and
enough to clearly demonstrate a link between a Private Key
and a Specific CA Certificate. If the corresponding public
key to that private key is included in another Subordinate
CA Certificate, it only adds policy requirements around
that private key.<br>
<br>
Put differently, if a Private Key is associated with
Certificate "SubCA1" which is operated by "SubCA1 org" and
for some reason the same private key is associated with
Certificate "SubCA2" which is operated by "SubCA2 org", we
need to determine what obligations exist for the handling
of that Private Key for its entire lifecycle and usage,
which is the superset of SubCA1 and SubCA2. If the
requirements surrounding SubCA1 and SubCA1 org are
"requirements A" and the requirements surrounding SubCA2
and SubCA2 org are "requirements B", then the Private Key
must meet requirements A+B.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
In Section 4.9.10 (On-line
revocation checking requirements)<br>
<br>
</blockquote>
<div><br>
</div>
<div>Was this intentional?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This specific change was addressed during the
discussion phase (<a moz-do-not-send="true"
class="m_302437843593208024gmail-m_-4091516754384310756moz-txt-link-freetext"
href="https://www.mail-archive.com/public@cabforum.org/msg02652.html"
target="_blank">https://www.mail-archive.com/<wbr>public@cabforum.org/msg02652.h<wbr>tml</a>).<br>
</div>
</blockquote>
<div><br>
</div>
<div>Did you link to the right thread? I cannot
find a clear answer, but perhaps I'm just
missing it. As it stands, I think this alone is
potentially grounds that we may need to vote
against it, because it's a clear reduction in
assurance.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The link is from a thread started by Ben. Unfortunately, I
couldn't find it in the mail-archive so it is pasted here:<br>
<br>
--- BEGIN QUOTE---<br>
-------- Forwarded Message --------<br>
Subject: [cabfpub] Policy Review Working Group's
Pre-Ballot to Clarify Use of "CA"<br>
Date: Thu, 19 Jan 2017 16:44:46 +0000<br>
From: Ben Wilson via Public <a moz-do-not-send="true"
class="m_302437843593208024moz-txt-link-rfc2396E"
href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
Reply-To: CA/Browser Forum Public Discussion List <a
moz-do-not-send="true"
class="m_302437843593208024moz-txt-link-rfc2396E"
href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
To: CABFPub <a moz-do-not-send="true"
class="m_302437843593208024moz-txt-link-rfc2396E"
href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
CC: Ben Wilson <a moz-do-not-send="true"
class="m_302437843593208024moz-txt-link-rfc2396E"
href="mailto:ben.wilson@digicert.com" target="_blank"><ben.wilson@digicert.com></a><br>
<br>
<br>
All,<br>
<br>
The Policy Review Working Group has completed its review
of the Baseline Requirements for purposes of clarifying
use of the term "CA" and related terminology. Please
review and comment on the following pre-ballot. A
redlined version of the Baseline Requirements is attached
to facilitate your review and comment. <br>
<br>
I did want to highlight one of the proposed changes that
is not related to "CA" terminology. That proposed change
is in Section 4.9.10. The current language is ambiguous,
and it doesn't say what was originally intended when it
was adopted. The current language says, "Effective 1
August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST
NOT respond with a "good" status for such certificates."
<br>
<br>
The proposed change would rephrase this sentence to say
what was originally intended. It would say, "OCSP
responders for Subordinate CA Certificates that are
Technically Constrained in accordance with Section 7.1.5
are exempt from this prohibition on responding with a
"good" to OCSP requests for the status for such
certificates."<br>
<br>
I don't know if anyone is relying on this provision, but
its original intent was to address concerns by users of
legacy CA software / OCSP responder software who
complained that they could not meet this requirement
because their OCSP responders were built to rely only on
CRLs.<br>
<br>
If this proposed change presents a problem for anybody, it
will be removed from this ballot and put into its own
separate ballot.<br>
<br>
<br>
Thanks,<br>
Ben<br>
--- END QUOTE---<br>
<br>
Gerv replied on January 25th that he agrees with the
proposed change on 7.1.5 which basically clears the
language. It doesn't reduce the assurance. The assurance
is already "reduced" in the current BRs. Here is the
current language in 4.9.10:<br>
<br>
"Effective 1 August 2013, OCSP responders for CAs which
are not Technically Constrained in line with Section 7.1.5
MUST NOT respond with a "good" status for such
certificates".<br>
<br>
The new proposed language says exactly the same thing but
in a more clear way. So, again, the ballot does not
propose policy changes (although as we said a couple of
times, the WG was very tempted to propose policy changes
to make things better).<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> A typo indeed. It is
clear in the red-lined version.<br>
</div>
</blockquote>
<div><br>
</div>
<div>For future reference, we should try to figure
out what version is being voted on, when the
e-mailed ballot and Red Line disagree :) This is
a minor issue, but I can easily see more
significant issues creeping in, least of all,
because I have not looked at all at the Red
Lined version, because that's not the balloted
text :)</div>
</div>
</div>
</div>
</blockquote>
<br>
Agreed. I guess once we become more familiar with a github
process, we will use one version over another as
authoritative for ballots (most probably the github
version).<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
In Section 8.7 (Self-Audits)<br>
<br>
<br>
Replace the last paragraph with:<br>
<br>
During the period in which a
Technically Constrained Externally
Operated Subordinate CA issues
Certificates, the Issuing CA SHALL
monitor adherence to the Issuing
CA's Certificate Policy and/or
Certification Practice Statement
and the Externally Operated
Subordinate CA's Certificate
Policy and/or Certification
Practice Statement. On at least a
quarterly basis, against a
randomly selected sample of the
greater of one certificate or at
least three percent of the
Certificates issued by the
Externally Operated Subordinate
CA, during the period commencing
immediately after the previous
audit sample was taken, the CA
SHALL ensure adherence to all
applicable Certificate Policies
and/or Certification Practice
Statements.<br>
</blockquote>
<div><br>
</div>
<div>Much like several other changes
mentioned above, this limits the
scope of the existing text from
"internal or external" to simply
"external". Thus it reduces the
scope of examination for
internally operated subordinate CA
certificates, which may be
operated by an Afilliate under a
distinct CP/CPS. Is that fair to
say?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The rest of the section remains the same. It
doesn't remove the obligation for the CA (this
covers ALL CA organizations, including
affiliates) to perform quarterly self-audits.<br>
<br>
The reasoning for changing the last paragraph
to only "Externally Operated Subordinate CAs",
was that the language dictates that the
"Issuing CA SHALL monitor adherence...". We
thought that it doesn't make sense to have one
organization monitor adherence to it's own
organization. It is already required for the
Root CA Operator to adhere to its own CP
and/or CPS (that must cover all Internally
Operated Subordinate CAs), check against a
randomly selected sample, etc, as specified in
the first paragraph of section 8.7.<br>
</div>
</blockquote>
<div><br>
</div>
<div>So I think the point you're making is
important, and I'm not cleared where it's
technically spelled out or required, and do hope
you can highlight this.</div>
<div><br>
</div>
<div>You're asserting that all Internally Operated
Subordinate CAs are operated by the Root
Operator AND, if I'm understanding correctly,
audited to the same CP/CPS as the Root CA
Certificate - is this correct?</div>
</div>
</div>
</div>
</blockquote>
<br>
No. I am saying that it could be, under some
circumstances. For example, if a Root Operator has an
internal department (under the same Management) that
handle issuances under a specific Subordinate CA
Certificate, then this Internally Operated Subordinate CA
could be covered in the audit of the Root Operator. If
we're talking about two separate legal entities under
different Management, then a separate audit report is
needed according to Section 8.1.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I haven't found text to normatively require
either statement, and that's the concern: even
if it's the same organization as the Root
Operator, the possibility for distinct CP/CPSes
to exist between the Root CA Certificate's
policies and the Internally Operated Subordinate
CA's policies (and/or independent audits)
exists, and as much as possible, I want to
ensure the same consistent duty of care with
respect to policies and practices. I fear this
introduces a loophole for Affiliates to 'skip'
audits and key protection, even if unintended,
so I'm curious if we can find a resolution for
this within the voting period.</div>
</div>
</div>
</div>
</blockquote>
<br>
The requirement for all Subordinate CAs to be audited
comes from the first paragraph of Section 8.1, as stated
above. It leaves no room for interpretations and includes
ALL Subordinate CAs, Internal or External.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
Here are the two definitions introduced:<br>
<br>
<b><span lang="EN-US">Root CA Operator:</span></b><span
lang="EN-US"><span> </span></span><span
lang="EN-US">The top-level Certification
Authority (i.e. an organization) whose CA
Certificate (or associated Public Key) is
distributed by Application Software
Suppliers as a trust anchor<br>
</span><br>
<b><span lang="EN-US">Internally Operated
Subordinate CA:</span></b><span
lang="EN-US"> <span> </span>A Subordinate
CA Operator, operated by a Root CA Operator
or its Affiliate that is in possession or
control of the Private Key associated with
the Subordinate CA Certificate</span> <br>
<br>
The Root CA Operator is already -by
definition- responsible for all actions
related to its Internally Operated Subordinate
CAs and Affiliates.</div>
</blockquote>
<div><br>
</div>
<div>I disagree, and that's the point of concern.
If the Root CA Operator included the definition
of Affiliates - ergo bringing consistency to the
scope of audits and operation - then perhaps
this issue would be resolved (of course, it may
introduce new bugs). But as it stands, an
Internally Operated Sub CA having the "or its
Affiliate" creates a loophole in which all the
policies which apply to a Root CA Operator
_don't_ apply to the Affiliate, because IOSCAs
clearly distinguish Affiliate as "something
other than the Root CA Operator"</div>
<div><br>
</div>
<div>Does this make sense?</div>
</div>
</div>
</div>
</blockquote>
<br>
I believe it is the opposite. To the best of my knowledge
and understanding (and I hope members can correct me if
I'm wrong), IOSCAs are treated as "something as the Root
CA Operator". That's already captured in the BRs today.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> Voting ends on Thursday
March 2 at 22:00 UTC but the remaining issues
will be tracked and addressed in a future
ballot.<br>
</div>
</blockquote>
<div><br>
</div>
<div>My hope is something a bit more concrete than
future ballot before then, because I think some
of these concerns are enough to prevent our
support </div>
</div>
</div>
</div>
</blockquote>
<br>
The voting ends tomorrow and I hope to have addressed some
or all your concerns. Ben and Tim (and even Peter who
attended several of the WG meetings) are welcome to add
any comments to help addressing these concerns even
further. I also encourage other members with the same or
similar concerns who feel they are not properly addressed,
to speak up so we can decide if we must proceed with
amendments. Unfortunately, at the stage we are at, the
ballot cannot be withdrawn so it can either pass or fail.
Overall, the ballot has significant language improvements
-as many have already stated- and it would be nice to have
every member's support. Policy problems that pre-existed
the ballot, still remain but that was left untouched on
purpose, so we could proceed with policy improvements
after we had a consistent language and definitions
throughout the BRs.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>