Re: Parler

[mark seery]

I assume multiple networks/ ISPs that have acceptable use policies that call 
out criminality and incitement to violence, for example:

https://www.xfinity.com/support/articles/comcast-acceptable-use-policy

Have these AUPs been invoked previously for these reasons, or would that be new 
territory?

Sent from Mobile Device

> On Jan 10, 2021, at 2:52 PM, K. Scott Helms  wrote:
> 
> 
> Right, it's not a list for content hosting.
> 
> Scott Helms
> 
>> On Sun, Jan 10, 2021, 5:42 PM  wrote:
>> No, this is a list for Network Operators.
>> 
>> Sent from my iPhone
>> 
 On Jan 10, 2021, at 5:32 PM, K. Scott Helms  wrote:
 
>>> 
>>> This is a list for pushing bits.  The fact that many/most of us have other 
>>> businesses doesn't make this an appropriate forum for SIP issues (to use my 
>>> own work as an example).
>>> 
 On Sun, Jan 10, 2021, 4:52 PM  wrote:
 This is a list for Network Operators, AWS certainly operates networks.
 
 Sent from my iPhone
 
>> On Jan 10, 2021, at 4:27 PM, K. Scott Helms  
>> wrote:
>> 
> 
> No,
> 
> It really does not.  Section 230 only applies to publishers, and not to 
> network providers.  If this were a cloud hosting provider list then you'd 
> be correct, but as a network provider's list it does not belong here.
> 
> 
> Scott Helms
> 
> 
> 
>> On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD Cannon  
>> wrote:
>> As network operations and compute/cloud/hosting operations continue to 
>> coalesce, I very much disagree with you.  Section 230 is absolutely 
>> relevant, this discussion is timely and relevant, and it directly 
>> affects me as both a telecom and cloud compute/services provider. 
>> 
>> 
>> —L.B.
>> 
>> Lady Benjamin PD Cannon, ASCE
>> 6x7 Networks & 6x7 Telecom, LLC 
>> CEO 
>> b...@6by7.net
>> "The only fully end-to-end encrypted global telecommunications company 
>> in the world.”
>> FCC License KJ6FJJ
>> 
>> 
>> 
>> 
>>> On Jan 10, 2021, at 12:13 PM, K. Scott Helms  
>>> wrote:
>>> 
>>> It's not, and frankly it's disappointing to see people pushing an 
>>> agenda here.
>>> 
>>> 
>>> Scott Helms
>>> 
>>> 
 On Sun, Jan 10, 2021 at 9:37 AM  wrote:
 
 NANOG is a group of Operators, discussion does not have to be about 
 networking. I have already explained how this represents a significant 
 issue for Network Operators.
 
 On Jan 10, 2021, at 9:09 AM, Mike Bolitho  
 wrote:
 
 
 It has nothing to do with networking. Their decision was necessarily 
 political. If you can specifically bring up an issue, beyond 
 speculative, on how their new chosen CDN is somehow now causing 
 congestion or routing issues on the public internet, then great. But 
 as of now, that isn't even a thing. It's just best to leave it alone 
 because it will devolve into chaos.
 
 - Mike Bolitho
 
> On Sun, Jan 10, 2021, 6:54 AM  wrote:
> 
> Why? This is extremely relevant to network operators and is not 
> political at all.
> 
> On Jan 10, 2021, at 8:51 AM, Mike Bolitho  
> wrote:
> 
> 
> Can we please not go down this rabbit hole on here? List admins?
> 
> - Mike Bolitho
> 
>> On Sun, Jan 10, 2021, 1:26 AM William Herrin  wrote:
>> 
>> Anybody looking for a new customer opportunity? It seems Parler is in
>> search of a new service provider. Vendors need only provide all the
>> proprietary AWS APIs that Parler depends upon to function.
>> 
>> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>> 
>> Regards,
>> Bill HErrin
>> 

Re: Parler

[mark seery]

As with common carriage and net neutrality, the discrimination has to be 
consistent.

Sent from Mobile Device

> On Jan 10, 2021, at 10:15 AM, Haudy Kazemi via NANOG  wrote:
> 
> 
> Conclusion:
> 
> Companies are not permitted to discriminate amongst who they will have as a 
> customer on the basis of the racial or sexual orientation (or a number of 
> other bases).
> 
> Companies are permitted to discriminate amongst who they will have as a 
> customer using other criteria. E.g. "No shirt, no shoes, no mask, no 
> service." Customers who disturb other customers can also get "fired" or 
> banned by the company if they're deemed not worth the trouble...but the 
> reason for doing so must not be illegal itself.
> 
> Companies who are wary of the law may also be particularly concerned about 
> serving customers who are using (or enabling others to use) the goods and 
> services that company offers in ways that may violate the laws of the 
> jurisdiction the company is under. (In some neighborhoods, Home Depot locks 
> up all the spray paint cans, and limits sales to customers, as part of local 
> anti-graffiti measures.)
> 
> ---
> 
> There are parallels in establishing or ending employment...there are certain 
> reasons that provide a legal basis for hiring or not hiring someone, as well 
> as reasons that provide a legal basis for firing someone.
> 
> 
> 
>> On Sun, Jan 10, 2021, 10:34 Matt Hoppes  
>> wrote:
>> While I don’t like it - at the end of the day a private company can make a 
>> decision to have or not have a customer (unless somehow it’s racial or 
>> sexual orientation related apparently). 
>> 
>> Nothing is stopping Parler from spinning up their own servers. They 
>> willingly chose to use AWS.

Re: SRv6

[mark seery]

> 
> Sounds like you're making a/the case for MACSec :-).
> 

While I get your point, and it is a good one, no. Once lawyers, finance, and 
other functions get involved, it goes from being just another technology, to a 
pain for suppliers and customers alike. Export laws complicate implementation, 
and vendors can only afford and/or have the operational agility, to do an 
implementation once. Any security tech that is sufficiently interesting, is 
going to be a pain for router vendors to implement and operationalize given the 
government’s attitude to such tech. The lower in the stack it is, the bigger 
the pain. 

That said, vendors are being asked to put MACSec in and I suspect more 
platforms supporting it will become available over time.

Re: SRv6

[mark seery]

> On Sep 17, 2020, at 9:24 AM, Mark Tinka  wrote:
> 
>> For operators already offering FR/ATM services, it was a replacement, using 
>> the same principles of traffic separation over a common infrastructure, 
>> without encryption as part of the service. So from that perspective only, it 
>> was not much of a change for *existing* enterprise customers.
> 
> Indeed. But the difference with Frame Relay and ATM was that telco's never 
> called it a (V)PN. At worst, it was a leased line.

Private line was a common term for leased lines. Leased lines were not 
encrypted by the operator, AFAIK. This terminology morphed to virtual private 
line, Ethernet Private Line, virtual private LAN service (VPLS), etc.

"In telecommunication, a private line is typically a telephone company service 
that uses a dedicated, usually unswitched point-to-point circuit, but it may 
involve private switchingarrangements, or predefined transmission physical or 
virtual paths.”

https://en.wikipedia.org/wiki/Private_line 


https://www.business.att.com/products/dedicated-internet/#/ 


http://etler.com/docs/AT%20Pub/TR54077.pdf 


https://business.comcast.com/enterprise/products-services/data-networking/ethernet-virtual-private-line
 


VPN is a terminology consistent with past practices. It is P in all the ways 
discussed on this thread, and historically consistent (at least from a 
marketing perspective). Whether it is P enough is a reasonable discussion, 
everyone in I(C)T is going to be facing a wave of voter concern about privacy, 
IMO.

> Or someone else who might "capture" the operator, and thus, be able to 
> intercept it.

Good point.

> If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud bags 
> will simply take over (not that they haven't, already).

Torn between two lovers: Growing voter concern about privacy & longheld, and 
arguably increasing, desire to intercept criminal / terrorist communication. 
I’d actually be curious if any operators have received public sector pushback 
when they tried to implement encryption.

> 
> Mark.

Re: SRv6

[mark seery]

> On Sep 17, 2020, at 8:28 AM, Mark Tinka  wrote:
> 
> 
> 
> On 16/Sep/20 23:22, Anoop Ghanwani wrote:
> 
>> It depends on the definition of VPN.  In terms of services like
>> MPLS-based VPNs, it refers to the extension of a Private network 
>> over a shared infrastructure, allowing entities using the shared
>> infrastructure to have their own private address space and routing
>> tables.
> 
> Really, it was just a way to leverage IP networks to make more money.

For operators already offering FR/ATM services, it was a replacement, using the 
same principles of traffic separation over a common infrastructure, without 
encryption as part of the service. So from that perspective only, it was not 
much of a change for *existing* enterprise customers. 

This community is aware of the responsibility of a network is to ensure that 
traffic is forwarded to the (originally?) intended destination to prevent 
confidential information being exposed to a third-party. It is in this respect 
that the term “privacy” is often used. So seems like there is a taxonomy issue 
here. Perhaps traffic separation is a better term than privacy, because while 
traffic is probablistically private with respect to other VPN customers 
(separated with some high level of probability), it is not private with respect 
to the operator (who could intercept it).

> Nothing against that, as long as "buyer be aware" applies.

Sure, transparency is good.

I remember 20 years ago at a London IETF where the issue arose, and a food 
fight arose over who would own and manage encryption keys if traffic was 
encrypted. I don’t recall what the resolution of that debate was.

That said, we live in an era where there is increasing sensitivity to 
protecting consumer (at least) information. This sensitivity exists at multiple 
layers of the “stack”. So it is an interesting question / issue, and certainly 
would not be of any surprise if governments mandated it in the future, as long 
as they could intercept it for law enforcement purposes of course, and until 
they could, they probably would not be encouraging operators to encrypt data in 
any difficult to crack way (a speculation on my part).

Perhaps all the more reason why end-to-end encryption should be part of the 
buyer beware conversation (not arguing against operator encryption in saying 
that - privacy is something everyone in I[C]T has to think about today).

> 
> Mark.