<div dir="ltr">this is a prime example of why the policy is bad<div><br></div><div>Twitch and Amazon should have a vote each</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2015 at 15:45, C N <span dir="ltr"><<a href="mailto:nielsenc@gmail.com" target="_blank">nielsenc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not trying to derail the 'Twitch' vote but Twitch is an Amazon Subsidiary yet we run our own network. Based on what I have read from some here, that would disqualify either the 'Twitch AS' or 'Amazon AS' since only one could vote. If that were the case, who chooses who gets to vote?<div><br></div><div>Christian</div><div><br><div><br></div><div>   </div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 12:16 PM, Christian Koch <span dir="ltr"><<a href="mailto:ck@megaport.com" target="_blank">ck@megaport.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">if thats the policy, then peeringdb should be modified for organizations with multiple ASN's so there can primary and sub ASN's<div><br><div><div>just because there is a parent company, does not mean policy is controlled by a single person or group</div><div><br></div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 20 November 2015 at 15:03, Chris Caputo <span dir="ltr"><<a href="mailto:ccaputo@alt.net" target="_blank">ccaputo@alt.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>In the current draft, networks are not members.  Business entities are.<br>
<br>
Some businesses have multiple networks / multiple ASNs.  I hope we can<br>
agree they should only have one vote.<br>
<br>
Do you really want to give conglomerates multiple votes while<br>
non-conglomerates have a single vote?<br>
<span><font color="#888888"><br>
Chris<br>
</font></span><div><div><br>
On Fri, 20 Nov 2015, Christian Koch wrote:<br>
> going to have to agree here.<br>
> this is a silly rule, with no way to validate the independence of the network policy. <br>
><br>
><br>
> On 19 November 2015 at 13:27, Pierfrancesco Caci <<a href="mailto:pf@caci.it" target="_blank">pf@caci.it</a>> wrote:<br>
>       >>>>> "Chris" == Chris Caputo <<a href="mailto:ccaputo@alt.net" target="_blank">ccaputo@alt.net</a>> writes:<br>
><br>
><br>
>           Chris> On Thu, 19 Nov 2015, Pierfrancesco Caci wrote:<br>
>           >> >>>>> "Chris" == Chris Caputo <<a href="mailto:secretary@peeringdb.com" target="_blank">secretary@peeringdb.com</a>> writes:<br>
>           Chris> - 2 organizations have been disallowed from voting due to<br>
>           Chris> coming under the purview of the draft bylaws affiliate<br>
>           Chris> clause (*).  1 was disallowed because of a parent<br>
>           Chris> organization affiliation, and 1 was disallowed because<br>
>           Chris> of a common control affiliation.<br>
>           >><br>
>           >> After this election is over, I suggest that we talk about when a<br>
>           >> controlled organization is independent enough to get their own vote<br>
>           >> besides that of the parent. One of the 2 orgs that have been disallowed<br>
>           >> could well have voted independently of mine, in my opinion.<br>
><br>
>           Chris> Allowing organizations under common control to have multiple votes,<br>
>           Chris> depending on the level of independence reported by the organizations<br>
>           Chris> themselves, would seem to be a challenging equation to balance.<br>
><br>
>           Chris> If A is a parent of B and C, and B and C are able to vote,<br>
>           Chris> then A wields<br>
>           Chris> twice the influence of other voters.<br>
><br>
>           Chris> I don't see how that can be negated.<br>
><br>
>       I'm not sure which cases we're trying to prevent here. B and C run<br>
>       different networks with different peering policies and requirements.<br>
>       I understand that you have no possibility to check the level of<br>
>       independence. Anyway, let's have this vote come to conclusion, and maybe<br>
>       in the meantime I or someone else comes up with a better idea.<br>
><br>
>       Pf<br>
><br>
>       --<br>
>       Pierfrancesco Caci</div></div><br></div></div><span>_______________________________________________<br>
Pdb-gov mailing list<br>
<a href="mailto:Pdb-gov@lists.peeringdb.com" target="_blank">Pdb-gov@lists.peeringdb.com</a><br>
<a href="http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov" rel="noreferrer" target="_blank">http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
Pdb-gov mailing list<br>
<a href="mailto:Pdb-gov@lists.peeringdb.com" target="_blank">Pdb-gov@lists.peeringdb.com</a><br>
<a href="http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov" rel="noreferrer" target="_blank">http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>