<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Akamai Prolexic Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 12:34:49 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Guide: Setting up a shadow DNS configuration for a safe Prolexic rollout.</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/guide-setting-up-a-shadow-dns-configuration-for-a-safe-prolexic-rollout-2/</link>
                        <pubDate>Mon, 28 Sep 2026 10:55:48 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I&#039;m new here and trying to learn the ropes of enterprise security.

My company is moving forward with Akamai Prolexic to help protect our web applications. Our IT lead mentioned...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I'm new here and trying to learn the ropes of enterprise security.

My company is moving forward with Akamai Prolexic to help protect our web applications. Our IT lead mentioned we should use a "shadow DNS" setup during the rollout to avoid any risk of downtime. I've been reading about it, but I'm a bit lost on the actual steps.

From what I gather, we point our domain to Prolexic first in a testing environment, while our live traffic still goes to our old infrastructure? Is that the main idea? I'm worried about missing a step and accidentally switching all our customer traffic before we've fully tested everything.

Could someone walk me through a basic, safe process for this? I'd really appreciate knowing what records to change first, how to test that the Prolexic protection is actually working before we go live, and any common mistakes to avoid. Our stack is pretty standard: a couple of web servers behind a load balancer.

Thanks so much for your help! &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>Eval_Newbie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/guide-setting-up-a-shadow-dns-configuration-for-a-safe-prolexic-rollout-2/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who wants a simple &quot;attack stopped&quot; badge for our status page?</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/am-i-the-only-one-who-wants-a-simple-attack-stopped-badge-for-our-status-page-2/</link>
                        <pubDate>Sun, 27 Sep 2026 10:31:12 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the vendor-speak for a minute. We&#039;ve been running Akamai Prolexic for about three years now. It does its job. The DDoS attacks get mitigated, the traffic graphs lo...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the vendor-speak for a minute. We've been running Akamai Prolexic for about three years now. It does its job. The DDoS attacks get mitigated, the traffic graphs look like a mountain range instead of a flatline, and the NOC doesn't wake me up at 3 AM. That's the win.

But for the love of all that is holy, why is it so hard to get a simple, clear, public signal that an attack was stopped? I'm not asking for a detailed forensic report in my status page feed. I want a clean, automated "badge" or incident update that says "DDoS Mitigation Active - Service Operating Normally" that I can pipe into our status page (think Statuspal, Statuspage.io, even a custom component).

Instead, what do I get? A labyrinthine portal with a million graphs, alerts buried in a proprietary event system, and JSON APIs that require a PhD in Akamai-ology to decipher just to confirm a mitigation is happening. My CTO wants public-facing transparency. My NOC wants a clear audit trail. I just want a stupid webhook that fires when Prolexic kicks in, with a pre-approved message.

Here's what I've had to cobble together as a workaround. It's brittle, it's dumb, and it relies on scraping their "Security Events" API for a specific mitigation state. Don't judge me.

```bash
#!/bin/bash
# This is a cron job that runs every 5 minutes. It's ugly.
AKAMAI_API_HOST="https://api.akamai.com"
EVENT_ENDPOINT="/siem/v1/events"
# ... auth setup with edgegrid ...

# Fetch events from last 5 mins, grep for "MITIGATION_START" on our IP range
curl -s $AKAMAI_API_HOST$EVENT_ENDPOINT | jq '.events[] | select(.type=="MITIGATION_START")' &gt; /tmp/current_event

if ; then
  # Trigger a webhook to our status page system with a "minor" incident
  curl -X POST https://api.statuspage.io/v1/pages/$PAGE_ID/incidents 
    -H "Authorization: OAuth $STATUSPAGE_TOKEN" 
    -d "incident=DDoS Mitigation Active" 
    -d "incident=investigating" 
    -d "incident=minor" 
    -d "incident=Prolexic has engaged mitigation for potential DDoS activity. All services are operating normally." 
    -d "incident=operational"
fi
```

This is ridiculous. I have to parse through a firehose of data just to find the one signal I need, and I'm terrified of a false positive.

Am I the only one who thinks this should be a one-click configuration in the Prolexic portal? A simple toggle: "Public Status Integration" -&gt; "Send update to webhook on mitigation start/stop." It seems so basic. We pay a premium for this service. The technical mitigation is solid, but the operational integration feels like an afterthought. I want to show our users we're protecting them, without writing and maintaining my own shim layer to their API.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>devops_grandad</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/am-i-the-only-one-who-wants-a-simple-attack-stopped-badge-for-our-status-page-2/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: If you&#039;re all-in on AWS, just use Shield and save the hassle.</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/unpopular-opinion-if-youre-all-in-on-aws-just-use-shield-and-save-the-hassle-2/</link>
                        <pubDate>Sat, 26 Sep 2026 22:20:44 +0000</pubDate>
                        <description><![CDATA[I keep seeing everyone recommend Prolexic for DDoS protection. But if your entire stack is already on AWS, doesn&#039;t AWS Shield Advanced cover the same ground?

From an expense management view...]]></description>
                        <content:encoded><![CDATA[I keep seeing everyone recommend Prolexic for DDoS protection. But if your entire stack is already on AWS, doesn't AWS Shield Advanced cover the same ground?

From an expense management view, adding another vendor complicates billing and reporting. You have to manage another integration, another set of alerts, and another cost center. Shield is just part of your AWS bill.

Maybe I'm missing something. For those who switched from Shield to Prolexic on AWS, what was the actual benefit that justified the extra vendor? Was it just about the reporting, or something in the mitigation itself?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>henry_b</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/unpopular-opinion-if-youre-all-in-on-aws-just-use-shield-and-save-the-hassle-2/</guid>
                    </item>
				                    <item>
                        <title>Radware vs Akamai Prolexic for Layer 7 application protection in finance</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/radware-vs-akamai-prolexic-for-layer-7-application-protection-in-finance-3/</link>
                        <pubDate>Sat, 26 Sep 2026 22:05:50 +0000</pubDate>
                        <description><![CDATA[Hey everyone, new to the security side of things. My team (small fintech) is evaluating DDoS solutions, specifically for protecting our customer-facing web app.

We&#039;ve narrowed it down to Ra...]]></description>
                        <content:encoded><![CDATA[Hey everyone, new to the security side of things. My team (small fintech) is evaluating DDoS solutions, specifically for protecting our customer-facing web app.

We've narrowed it down to Radware Cloud WAF and Akamai Prolexic with their Kona rule sets. Budget is a factor, but so is fine-grained control. I'm trying to map features to actual Grafana alerts.

For example, I want to alert on a specific malicious URI pattern that might slip through. With our current setup, a Prometheus rule for high request rate to a suspicious endpoint looks like this:

```yaml
- alert: API_Abuse_Suspected
  expr: rate(http_requests_total{job="webapp", path=~"/api/v1/balance/.*"}) &gt; 100
  for: 2m
```

Can anyone share real experience on how easily you can implement custom L7 rules and get metrics out for these platforms? Especially interested in integration with existing observability stacks. Radware's docs seem to suggest more API control, but Akamai's network scale is compelling.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/radware-vs-akamai-prolexic-for-layer-7-application-protection-in-finance-3/</guid>
                    </item>
				                    <item>
                        <title>Help: Prolexic scrubbing center reroute is failing for our EU region.</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/help-prolexic-scrubbing-center-reroute-is-failing-for-our-eu-region-2/</link>
                        <pubDate>Sat, 26 Sep 2026 13:15:51 +0000</pubDate>
                        <description><![CDATA[Hey everyone. Hitting a wall with our Prolexic setup and hoping someone has seen this before.

We’re trying to reroute EU traffic through the scrubbing center during a simulated DDoS test. T...]]></description>
                        <content:encoded><![CDATA[Hey everyone. Hitting a wall with our Prolexic setup and hoping someone has seen this before.

We’re trying to reroute EU traffic through the scrubbing center during a simulated DDoS test. The configuration is active, but traffic for our Frankfurt region is still hitting the origin directly, bypassing Prolexic entirely. Our other regions (US, Asia) are rerouting correctly. We've double-checked the BGP announcements and geo-rules in the portal. Support is involved, but it's slow going.

Has anyone else dealt with regional reroute failures? Specifically EU? Wondering if it's a known peering or route propagation issue we should push them on. &#x1f60a;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>CRMGuru</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/help-prolexic-scrubbing-center-reroute-is-failing-for-our-eu-region-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else find the custom rule syntax confusing compared to other vendors?</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/anyone-else-find-the-custom-rule-syntax-confusing-compared-to-other-vendors-2/</link>
                        <pubDate>Mon, 24 Aug 2026 12:05:48 +0000</pubDate>
                        <description><![CDATA[Hi everyone,

I&#039;ve been evaluating Akamai Prolexic for DDoS protection against a couple of other vendors (like Cloudflare and Imperva). The overall performance seems solid, but I keep gettin...]]></description>
                        <content:encoded><![CDATA[Hi everyone,

I've been evaluating Akamai Prolexic for DDoS protection against a couple of other vendors (like Cloudflare and Imperva). The overall performance seems solid, but I keep getting tripped up by the custom rule syntax.

It feels more abstract to me, especially when trying to match specific attack patterns. Coming from other platforms where rules are more declarative, I find myself re-reading the documentation constantly. Has anyone else had this experience?

Maybe I'm missing something. How do you all structure your custom rules for things like volumetric attacks or suspicious URI patterns? Any tips for making the syntax click would be great.

Thanks in advance!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>ChrisF</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/anyone-else-find-the-custom-rule-syntax-confusing-compared-to-other-vendors-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone benchmarked Prolexic against AWS Shield Advanced on cost/performance?</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/has-anyone-benchmarked-prolexic-against-aws-shield-advanced-on-cost-performance-2/</link>
                        <pubDate>Sun, 23 Aug 2026 12:51:26 +0000</pubDate>
                        <description><![CDATA[Having recently concluded a vendor evaluation for a large-scale DDoS mitigation solution, I found the public discourse comparing Akamai Prolexic and AWS Shield Advanced to be frustratingly s...]]></description>
                        <content:encoded><![CDATA[Having recently concluded a vendor evaluation for a large-scale DDoS mitigation solution, I found the public discourse comparing Akamai Prolexic and AWS Shield Advanced to be frustratingly superficial. Most analyses focus on binary feature lists or vague "cloud-native" advantages, while neglecting the nuanced, operational, and financial realities of deployment. My own analysis, grounded in a multi-terabit-per-second requirement with strict latency SLAs, revealed significant divergence in their fundamental models, making a simple benchmark misleading without first defining the architectural and threat scope.

The core of the comparison lies in the dichotomy between a dedicated, always-on scrubbing network (Prolexic) and a tightly integrated, but fundamentally reactive, cloud platform service (Shield Advanced). This difference manifests in three critical dimensions that directly impact both cost and performance:

*   **Architectural Cost Drivers:**
    *   **Prolexic** operates on a traditional network-centric pricing model, often involving committed capacity tiers (e.g., 10 Gbps, 100 Gbps commit) with overage fees. Costs scale with the level of protection capacity you reserve, not necessarily the traffic you *normally* receive. This provides predictable, but potentially expensive, overhead for always-on protection.
    *   **Shield Advanced** pricing is anchored to the protected resources (e.g., Elastic IPs, ALBs, CloudFront distributions) plus a data transfer fee for scrubbed traffic. Its cost is inherently coupled with your AWS spend. For a heavily invested AWS environment, the integration can be cost-effective, but the financial impact of a major attack (due to data transfer out from AWS Shield scrubbing centers) can be substantial and difficult to model in advance.

*   **Performance &amp; Operational Realities:**
    *   **Traffic Steering:** Prolexic typically uses BGP anycast or DNS-based redirection, forcing all traffic—clean and malicious—through its scrubbing centers. This introduces a fixed latency penalty (typically sub-10ms, but measurable) for all global users, which must be weighed against the benefit of uniform inspection.
    *   **Shield Advanced** protects resources *in-region* or at the edge (CloudFront). During a detected attack, it activates mitigations within the AWS network fabric. Clean traffic should, in theory, follow optimal paths without being hair-pinned to a central scrubber. This can result in lower latency for clean traffic during an attack, but the mitigation efficacy is deeply tied to the scale and topology of the AWS region under attack.

*   **The Scope of Protection:**
    *   A critical, often overlooked factor is protection of non-web assets. Prolexic's network-layer (L3/L4) protection is agnostic to the protocols running over it, covering everything from gaming servers to custom industrial protocols.
    *   Shield Advanced's advanced protections are most potent for AWS resources like EC2, ELB, and CloudFront. Protecting on-premises data centers or non-AWS cloud deployments requires complex, expensive setups like AWS Global Accelerator, which alters the cost model dramatically.

My conclusion was that benchmarking is only meaningful within a specific architectural context. For a predominantly AWS-native, web-focused application where minimizing latency for clean traffic is paramount and you accept the AWS ecosystem lock-in, Shield Advanced presents a compelling integrated value. For a hybrid or multi-cloud environment requiring guaranteed, always-on capacity for a wide range of protocols and where a predictable latency trade-off is acceptable for comprehensive inspection, Prolexic's dedicated network model justifies its premium.

I am keen to hear from others who have conducted detailed Total Cost of Ownership (TCO) modeling or performance testing under simulated attack conditions. Specifically, has anyone quantified the latency differential for global users during sustained, high-volume attacks? Or developed a framework for modeling the opaque data transfer cost risks associated with Shield Advanced during multi-vector attacks?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>clara_k</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/has-anyone-benchmarked-prolexic-against-aws-shield-advanced-on-cost-performance-2/</guid>
                    </item>
				                    <item>
                        <title>Radware vs Akamai Prolexic for Layer 7 application protection in finance</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/radware-vs-akamai-prolexic-for-layer-7-application-protection-in-finance-2/</link>
                        <pubDate>Sun, 23 Aug 2026 11:25:47 +0000</pubDate>
                        <description><![CDATA[Looked at both for PCI compliance and API gateway shielding. Radware&#039;s Cloud WAF is solid on the behavioral side, good at spotting low-and-slow stuff without killing legitimate traffic. Thei...]]></description>
                        <content:encoded><![CDATA[Looked at both for PCI compliance and API gateway shielding. Radware's Cloud WAF is solid on the behavioral side, good at spotting low-and-slow stuff without killing legitimate traffic. Their bot management is aggressive, which you need.

Prolexic is a fortress. You're paying for the network, not just the software. Their mitigation starts at the edge before traffic even sniffs your data center. For pure, unadulterated volumetric attacks at layer 7, they're untouchable. But it's Akamai—expect enterprise pricing and complexity. Radware feels more surgical. For a finance app with mixed traffic, that might matter more.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>crm_hopper</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/radware-vs-akamai-prolexic-for-layer-7-application-protection-in-finance-2/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: A simple CLI tool to check our current mitigation status.</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/check-out-what-i-made-a-simple-cli-tool-to-check-our-current-mitigation-status-2/</link>
                        <pubDate>Sun, 23 Aug 2026 00:20:58 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been lurking here for a while, trying to wrap my head around our DDoS protection setup with Prolexic. Honestly, it&#039;s been a bit overwhelming &#x1f605;. Our team often need...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been lurking here for a while, trying to wrap my head around our DDoS protection setup with Prolexic. Honestly, it's been a bit overwhelming &#x1f605;. Our team often needs a quick, at-a-glance view of our current mitigation status without diving into the full portal.

So, I built a super simple CLI tool in Python to fetch and display our current Prolexic mitigation status. It's basically a wrapper around their API. I'm sharing it here in case it's useful for anyone else, and also because... well, I'm sure I've probably done something wrong and would love any advice!

Here's what it does:
*   Takes our API credentials (stored securely via environment variables, of course!).
*   Hits the Prolexic `/mitigation` endpoint for our specific customer ID.
*   Parses the JSON and prints out a simple summary: mitigation ID, status (like `active` or `analyzing`), the policy name, and start time.

I ran it for the first time today and immediately got a `401` error. After panicking for a solid ten minutes, I realized my API key had expired. Classic. Got that sorted and now it works!

It's been really handy for our NOC dashboard and for quick checks. I'm thinking of adding features like:
*   Alerting if status flips to `analyzing` or `expired`.
*   Maybe even a simple historical log.

Has anyone else built little tools like this? I'd be curious to know how you handle error scenarios or if there are other API endpoints you find super useful for day-to-day monitoring. The Prolexic API docs are... comprehensive, to say the least, so pointers would be amazing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>data_pipeline_newbie_42_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/check-out-what-i-made-a-simple-cli-tool-to-check-our-current-mitigation-status-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone tried using Prolexic to protect a non-web service (like VoIP)?</title>
                        <link>https://communities.stackinsight.net/community/cyber-akamai-prolexic/has-anyone-tried-using-prolexic-to-protect-a-non-web-service-like-voip-2/</link>
                        <pubDate>Sat, 22 Aug 2026 16:30:58 +0000</pubDate>
                        <description><![CDATA[Hello everyone,

I&#039;ve been researching DDoS mitigation solutions for a critical, non-standard application, and Akamai&#039;s Prolexic platform keeps coming up in my evaluations. However, nearly e...]]></description>
                        <content:encoded><![CDATA[Hello everyone,

I've been researching DDoS mitigation solutions for a critical, non-standard application, and Akamai's Prolexic platform keeps coming up in my evaluations. However, nearly every case study, review, and technical deep-dive I can find focuses exclusively on protecting web applications (HTTP/HTTPS traffic) and associated infrastructure. My specific need is quite different, and I'm hoping someone in the community might have direct experience or insights to share.

We operate a globally distributed Voice over IP (VoIP) service, specifically a SIP-based signaling and media relay platform. Our primary concerns are volumetric attacks aimed at our SIP servers (UDP/TCP on non-standard ports) and, more critically, sophisticated protocol attacks that could exhaust session resources or degrade call quality. The nature of the traffic is stateful, latency-sensitive, and uses a mix of control and media protocols.

My core questions revolve around how Prolexic's protection is applied in such scenarios:

*   **Onboarding &amp; Configuration:** Does the protection for a non-web service still typically involve DNS redirection or BGP announcement? For SIP, we often have clients configured with specific IP addresses or SRV records, so I'm curious about the practical steps and potential disruptions during the cutover.
*   **Protocol Specificity:** How deep does Prolexic's mitigation go into non-HTTP protocols? For instance, can it be tuned to understand legitimate SIP message sequences (INVITE, 200 OK, ACK) to filter out malformed or attack-oriented signaling packets? Or is the protection more focused on the volumetric/network layers (3/4) in these cases?
*   **Latency Implications:** A major concern is the potential added latency from traffic scrubbing. Even an extra 20-30ms can be problematic for real-time voice communications. Has anyone measured the latency impact on real-time UDP streams (like RTP media) when routed through Prolexic?
*   **Any Gotchas:** Are there specific pitfalls when protecting stateful, non-web services? For example, handling of fragmented packets, or maintaining the state of legitimate calls during an attack, which might last for hours.

I've thoroughly reviewed Akamai's official documentation, but it naturally leans towards the most common use cases. I'm very interested in any hands-on experiences—positive or negative—specifically related to protecting services like VoIP, game servers, custom financial protocols, or industrial IoT gateways. Even knowing if Prolexic is generally considered a good fit for this class of problem would be incredibly helpful as we narrow down our vendor list.

Thank you in advance for any details you can provide.

~Heidi]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-akamai-prolexic/">Akamai Prolexic Reviews</category>                        <dc:creator>Heidi R</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-akamai-prolexic/has-anyone-tried-using-prolexic-to-protect-a-non-web-service-like-voip-2/</guid>
                    </item>
							        </channel>
        </rss>
		