[cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

Tue Apr 18 21:38:38 UTC 2017

All of the energy being spent on this thread could probably be better spent
in just initiating a new ballot for a revote and getting that started.

For what it's worth, I agree entirely with Geoff that it would be a bad
outcome for the Forum if a revote on a technicality led to a changed
outcome. Apple changing their vote for that reason to make sure the
original vote is respected, if Apple truly doesn't object to the outcome
(as their original abstention would indicate), seems completely reasonable.

But I think it makes the Forum look really bad if they hinge a tiebreaker
vote on an interpretation of "submitted to" that allows for someone to have
their email rejected by a mailing list they're not subscribed to. That's
not a credible interpretation of the Bylaws, and what Ryan is pointing to
is that since the Bylaws are in part meant to guarantee the legal
defensibility of IP protections, you should try to maintain discipline
about process and not reach out to strained interpretations to avoid
inconvenience.

-- Eric

On Tue, Apr 18, 2017 at 4:16 PM, Ryan Sleevi via Public <public at cabforum.org
> wrote:

>
>
> On Tue, Apr 18, 2017 at 3:58 PM, Jeremy Rowley <jeremy.rowley at digicert.com
> > wrote:
>>
>> In your view, the act of submission does not require authorization to
>> post on the Public Mail List, does not require acceptance by the Public
>> Mail List, nor does it require distribution as part of the public mail
>> list. Your view is that "All voting will take place via the Public Mail
>> List" does not correspond with the deadline of "Members shall have exactly
>> seven days for voting" - that is, provided that a vote is (eventually)
>> shared on the Public Mail List, that the requirement is met.
>>
>>
>>
>> [JR] Correct. If the bylaws meant the vote needed to be distributed to
>> the Forum through the public mailing list during the allotted time, the
>> wording would have stated such. Instead, the author chose to use the word
>> submitted despite the previous sentence mandating that all voting occur on
>> the mailing list. Either its poor drafting or the intent was that the
>> submission is sufficient.
>>
>
> The wording does though, within Section 5.2, by stating that:
> "The following materials shall be posted to the Public Mail List or Public
> Web Site:"
>
> and then continuing
> "(c) Messages formally proposing a Forum ballot (including ballots to
> establish, modify, or terminate Working Groups), individual votes, vote and
> quorum counts, and messages announcing ballot outcomes and voting
> breakdowns. "
>
> It would appear you're suggesting that "sent" and "posted" are distinct.
> That is, that Section 5.2 merely states that "Messages formally proposing a
> Forum ballot" must eventually appear on the Public Mail List, but that, by
> logical extension of the context for voting, this only needs to occur at
> some point in the future, and not necessarily in conjunction with the
> disclosure of the Ballot.
>
> This interpretation is based upon Section 2.2(d), which states that "the
> deadline clearly communicated in the ballot and sent via the Public Mail
> List."
>
> Since this is the same method of disclosing votes, is it reasonable to
> conclude that you believe it is a valid interpretation of our Bylaws that
> members may, in a coordinated enterprise, ensure their submissions to the
> public mail list are delayed (for example, using a "send delay" or by
> temporarily blocking communication the public list), coordinate their votes
> with eachother and, upon conclusion of such a Ballot, direct the Chair to
> post to the Public Mail List?
>
> This is the interpretation that naturally results from suggesting that
> "sent via the Public Mail List" and "All voting will take place via the
> Public Mail List" are not required to appear on the Public Mail List within
> the alotted time, and that eventual consistency is sufficient.
>
>
>>
>>
>> Is it consistent, then, that the act of "submitted Exclusion Notices"
>> does not require confirmation of the receipt by the Chair? If the Chair
>> claims not to have received an Exclusion Notice after the 3 business days
>> afforded, is that exclusion valid?
>>
>> [JR] Yes. That is why the bylaws in (g) mandate that the exclusion
>> notices also be sent to the Public Mailing list as a safeguard.
>>
>
> But this is the problem. The interpretation you're seemingly advocating is
> that "sent" merely indicates TO. This is clearly evidenced in Phillip
> Hallam-Baker's proposed definition for "sent". As a consequence of this,
> the Bylaws in (g) do not provide assurances that the actual message will be
> received and/or posted, but will, by the same interpretation and intent
> being argued for here, constitute having met the obligations as "sent" to
> the Public Mailing List.
>
> Put more explicitly, if we accept "sent" merely means adding to the To:
> (or using RCPT TO/DATA, as suggested by PHB), then an organization can
> "submit" an Exclusion Notice to the Chair (without confirming its receipt),
> "send" an Exclusion Notice to the Public Mail List (without ensuring the
> posting), and thus exclude an Essential Claim from the Forum's IPR Policy.
> Further, the Chair can "distribute" the Exclusion Notices (without confirm
> its receipt).
>
> Do you disagree with this conclusion from the interpretation of
> sent/submitted? If so, can you clarify?
>
>
>>
>>
>> I realize this sounds very much like "Bylawyer-ing", but I hope it
>> clarifies the importance of these concerns. If this interpretation of
>> "submit" stands, and Microsoft's vote is accepted, it means that Ballot 183
>> has failed to meaningfully address the concerns related to IP disclosures,
>> in a way that creates a singular and central point of failure or abuse.
>> While we assume good faith in all participants, the risk becomes
>> unacceptable if there is no assurance that exclusions will either
>> meaningfully be disclosed (if done by other parties) or accepted (if done
>> on our part). The key advantage of the Forum, carefully negotiated over
>> years of effort, which is that of the IP protection for such contributions,
>> entirely evaporates.
>>
>> [JR] I’m okay with bylaw-ering. However, I disagree with your assessment
>> on the IP issue. The issue remains with all non-members. There’s nothing
>> that ensures that all IP is disclosed. I also think that the bylaws were
>> likely intentionally worded that way to avoid anyone accidentally assigning
>> their IP due to a failure by the email server. However, that’s speculation.
>> If the drafter intended that disclosures had to be received by the forum to
>> become effective, the drafted would have used a different word than
>> “submit”.
>>
>
> Considering that this very exact scenario was repeatedly discussed in the
> Forum and the calls regarding our process, and the intent was very much
> that the act of "submiting" something is "to post", and that "to post"
> means to ensure it is publicly distributed and archived, the belief at the
> time was that "submit" means the plain reading of it.
>
> I'm curious, how would you propose to clarify it, given that such a
> position argues that "submit" and "send" do not require any receipt or
> confirmation. Do you believe "post" meaningfully addresses this? If not, do
> you have any suggestions on how to reform Section 5.2 to reflect the plain
> understanding that the Forum has had since Ballot 73 and Ballot 98, both of
> which supported the belief that "sent", "send", "submit" and "post" were
> all interchangable methods of expressing that a message shall appear to all
> members subscribed and as publicly archived?
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170418/9bfdd038/attachment-0003.html>