The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Pursuant to Section 3.6.5 of the RRA, Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion;

ScienceLogic: Can you share any of the strategies/advice that you give to companies embarking on their BSM journeys?

Doug McClure: Well, first they’ve got to have a BSM strategy. Nearly all the clients I talk to or hear about wanting to do BSM do not have a BSM strategy. I talk a lot about this on my blog and with clients and it is relevant whether you’re going to think about “BSM Lite” or “BSM Heavy” approaches.

Once we have a BSM strategy, we need to establish a BSM roadmap that guides us in how we’ll implement the BSM strategy in a more tactical manner, focusing on short term iterative quick wins and 30-60-90 day projects. For more of my thoughts on BSM strategy and roadmapping, see the following blog posts.

• Elements of Business Service Management Part 3: Getting Business Service Management on the Radar Screen

• Elements of Business Service Management Part 4: What’s your Business Service Management Strategy?

As I’ve alluded to previously, a client first must define and understand what “BSM Lite” may mean to them. Don’t take what the analysts or the vendors pitch for what you should do to achieve BSM or what value you should get from it.

For any type of BSM to be successful, each client must define what BSM means to them and state what they expect to get from BSM. They must make it personal, make it a part of their company culture and elevate it to be as an important initiative as compliance, risk management, SOA, ITIL, or other initiatives may be within the company.

Please don’t get scared off from this strategy thing. Please don’t blow this off as something that the secret enterprise architecture council should be doing. If you’re unable to get an audience in these areas within your company, start within your own sphere of influence.

Your strategy could be as simple as enabling the local operations center to more efficiently classify, triage and resolve problems based on a simple business service or application contextual understanding. Focus on how this changes the game within your environment. Come up with your own metrics and measures to assess the value this has to this organizational use. Trust me, you’ll need to justify your investment some time in the future.

Another trait of successful BSM implementations is that of the formal monitoring and management tools group has established some sort of database or knowledge repository that enables them to “manage the business of IT management and monitoring” if you will. In my opinion, the vendor community has let their clients down significantly in this area. The CMDB may be the correct answer, but most companies just don’t value monitoring enough to demand that this be included in their formal CMDB initiatives.

In my last job, we developed an application that I referred to as the “Service Management Database” or “SMDB”. Others may call it something else, but in essence, it was the database that captured what was monitored, how it was monitored, who owned it, what business services and applications it supported, the impact an outage or event from it had on the business services or applications, etc.

One key component of this “SMDB” was establishing the relationships of real and synthetic user and transaction monitoring steps to associated servers and applications. This is a significant gap area in many tools and vendor CMDBs.

Clients who have instituted something formal such as this generally have a very good handle on management and monitoring within their environment. Far too many clients do not have adequate monitoring (read visibility) in place to begin their BSM journey.

I’d strongly recommend a good hard look at how well the client’s monitoring and management practices are implemented and managed. Simply put, if they don’t have adequate visibility into how well those business services and applications are performing, you can’t expect to manage what you can’t “see” that may be impacting the business, clients, revenue, etc.

Just ask yourself this – can you explicitly state what monitoring is in place for a given business service or application? Can you quantify the impact of a simple event to a business service or application? Can you explain why something is red, yellow, purple or green and what causes it to change from one color to another? If you can’t, your BSM journey will be challenging.

Those with formal CMDB initiatives have their hands full with high risk, long time to value projects to just get a handle with traditional configuration management models. Taking these low level configuration items (CI’s) and establishing application and service dependencies comes after a lot of work getting through the organizational challenges of getting systems access to populate the CMDB.

I strongly recommend that the formal monitoring and management tools group create an authoritative database that enables them to establish end-to-end visibility into the service and application delivery chain and the impacts it has on the business, customer, etc. This ultimately becomes part of a more realistic federated CMDB within the business.

ScienceLogic: Can you provide an example of a successful implementation of BSM? Were there specific factors that especially contributed to its success?

Doug McClure: I’ve touched on the highlights of the most successful BSM implementations throughout my previous answers. Clients that have rallied around an organizational change or transformation focusing every team member’s efforts and energy towards ensuring that the business goals and objectives are being met through the delivery of highly available business services and applications.

Far too often the “change” never happens and it’s the “talking heads” that are preaching to the choir about what should be done. Every person on the front line, in the support teams, at the help desk, etc. must understand how they support or impact the business in business terms. Try putting this simple phrase after job titles “Hi, my name is Doug. I’m a Systems Administrator, Supporting the Business”.

That was a mouthful, but simply put, these clients have an impressively instrumented business and IT environment with the right amount of visibility into each area, joined together with an organization that thinks, operates and responds based on their understanding of the business goals and objectives and how these business services and applications enable business success.

The operational model for an organization fully adopting BSM identifies ways to establish a service management mentality across the entire business service and application delivery and support chain. The delivery, operations and support organizations must be incented to manage the services and applications being delivered with this end-to-end context.

A leading, outside the box “service management organization” may include the traditional IT silos but within a matrixed fashion focused on one or more key business services and applications. The “service management organization” is then incented to work together, as a team, for the end-to-end delivery and support of these services or applications.

It’s no longer one’s job to just be the systems administrator, database administrator or network engineer, their job is now to support specific business services and applications. They provide the subject matter expertise needed to support the services and applications together, as a team, eliminating the finger pointing or “not my problem” attitudes that exist in the majority of IT organizations today.

Overall, the KISS approach is what will enable BSM of any type (lite, heavy) to be the most successful. If it just feels natural, doesn’t take any additional effort, clicks or tasks to do then it’s going to work. BSM should be transparent and not just another buzz word. It’s not a form that gets filled out or a special process to follow in the run book. It’s doing the right thing for the business, no matter what the situation, crisis, buzz word or technology initiative of the day is.

ScienceLogic: How did you get involved in BSM?

Doug McClure: I think the foundations of my service management background and passion were initially established during my service in the US Navy. Today, I relate that experience to what I call BSM for the Military or Mission Services Management (MSM).

We had been taught over and over that extreme attention to the details of the mission at hand (aka “the business”) was the number one priority and that all of our technology, services, and applications existed for those Sailors and Marines on the other end (the “customer”). I can recall countless instances where mission critical communications services (telephony, orderwires, teletypes, command and control systems, etc.) were impacted in one way or another. It was extremely critical that we understood who was impacted and to what degree so that contingency plans could be activated. We weren’t just talking about lost revenue, poor sales or customer experience; we were talking about human lives and the security of the United States.

It is that military bearing, attention to detail and real world experience that drives me with many of my modern day BSM endeavors. That migration from “Mission Services Management” to BSM was honed working for over 10 years working in the Internet Service Provider (ISP) and datacenter, hosting and colocation business.

In those rapid growth businesses during the Internet boom, service differentiation was what “made you millions” or paved your way to bankruptcy. The companies I worked for had an extreme passion and focus on ensuring that their services, applications and Internet access products were of the highest quality, highly reliable and just plain better than the competition.

Again, the IT infrastructure, service quality and customer experience relationship was ingrained in all of our heads. It was all hands on deck when Webmail, Internet access, DNS, or the network experienced problems. We were measured in terms of how many customers experienced a busy signal or dropped connection or if you couldn’t log in fast enough to read your email. Companies like Keynote Systems and LionBridge/Veritest/Inverse tested the quality of our networks, services and applications and publicly ranked us against our competition. We thought in terms of customer experience and impact every minute of the day, 24×7.

It was in my last job managing a traditional enterprise management and monitoring development group for a nationwide ISP where I was able to work with emerging technology to help get a handle on the complexities of these rapidly growing IT environments filled with emerging technologies and products. Applying this early technology to complex service problems in our environment proved to me that the technology, coupled with the right emphasis on how the technology was implemented and an emphasis on the people and processes within the organization could bring BSM to life.

Where I felt left out in the cold was with my vendor relationship. While their technology gave me the potential, they didn’t teach me how to work through the organizational and technological problems to successfully implement the BSM strategy. My very first end-to-end BSM pilot was extremely successful and provided visibility into the IT environment and business service impact that have never been available before.

And here I am today, working at a software vendor for the first time. Welcome to the “dark side” as they say. The approach and methodology we followed for BSM has become the basis of the core BSM Methodology that I teach IBMers and our clients around the world today.

My personal mission and drive here at IBM Tivoli is to ensure that BSM is something that the typical monitoring tools administrator can actually implement and that our BSM story is something that any of our clients can be successful with. The sales and marketing slicks must be backed up by something like this whomever you are these days. Clients shouldn’t put up for “marketecture”, me too and gee whiz buzz words.

BSM takes a partnership and commitment to every client’s success, and I want to be involved in those BSM efforts in every industry or market worldwide. We need more thought leaders collaborating together in an open and public forum to change legacy attitudes about BSM and do what we can to enable client’s to be as successful as they can be.

ShareThis

ScienceLogic: What is “BSM Lite” and how is it different from “heavy” BSM?

Doug McClure: I think the concepts that Peter Sevcik from Net Forecast initially outlined in his blog post sum up what “BSM Lite” is all about: a simpler, less expensive, more responsive way of achieving the goals and objectives of Business Service Management (BSM).  He’s contrasted this nicely against what he termed “BSM Heavy” being the larger investments in time and resources to deploy domain specific tools and solutions each providing a view into the business service delivery with some aggregation and consolidation to tie up all of the disparate tool’s information into a concise end-to-end business service management story.

I’m pleased that he leveraged some of my thinking around a better working definition of what BSM really is from the BSM Defined page on my blog. Of course, these definitions are going to vary depending on whom you talk with and how they see the overall BSM Maturity Model.  I’ve created a BSM Maturity Model that aligns with the famous Gartner IT maturity model.  I’d like to think that a “BSM Lite” solution is one attacking the low hanging fruit, enabling one to achieve value quicker, and in a more tactical manner.  The “BSM Heavy” solutions are capable of the same, but span all along the BSM Maturity Model by adding additional point solutions, products and technologies from their broader portfolio. 

ScienceLogic: Does “BSM Lite” just refer to the tools, or can it refer to the process and methodology as well?

Doug McClure: I think that BSM is as much a philosophy as it is technology, process, people and methodology.  If we can get people to think, operate and respond differently than they do today with a focus on the business, customers, quality, revenue, or whatever else is most important to their business goals and objectives, than that is Business Service Management and could be “BSM Lite” if you will. 

Being that I work for IBM Tivoli, one of my personal objectives is to identify ways to use our key BSM enabling products in a more efficient, effective and BSM centric way. This was a huge driver for trying to hold DevCampTivoli focused on “Collaborative Development of End-to-End BSM Solutions”. 

In my opinion, we don’t make things very easy for our clients and the answer can’t be to “buy this product, module or widget” to fill in the gaps.  In my opinion, we must establish a BSM overlay within IBM Tivoli’s development and product management organization that ensures that we have clearly thought about how to enable BSM with the hundreds or products that we sell.  In my opinion, every product release must incorporate the fundamentals of enabling BSM in addition to the core domain specific functionality intended. I hope to keep this spirit alive and get our smartest IBMers and clients thinking about the best way to take a “BSM Heavy” solution and make it “lighter”. I hope to share more about my plans here and guidance for the industry in general soon.

That said, I am always interested in consulting with clients and collaborate with peers in the industry to figure out how to get the focus on the people, process and technology as key components of their BSM strategies.  I am absolutely convinced that without a documented BSM strategy, roadmap and top level sponsorship within the business and IT, the chances of BSM success greatly diminish.

ScienceLogic: Given the complexities involved in implementing a BSM strategy and dealing with the people and processes components of any business, how does “BSM Lite” really work? Should the expectations and outcomes be “lite” as well?

Doug McClure: Time will tell if “BSM Lite” will work.  I’m seeing emerging companies that are already breaking down some of the barriers to BSM success.  I do not expect that those choosing to begin with a “BSM Lite” approach should expect “lite” outcomes. 

The outcomes are the same regardless of the approach IF you’ve got a documented BSM strategy, roadmap and top level sponsorship in place before you begin. New features, capabilities and technologies will be needed as the needs of the business change and companies mature in BSM and fundamental IT management. This will likely force companies to move in more “BSM Heavy” directions to fill those gaps. 

In my opinion, this is the ideal scenario now as it gives “BSM Lite” vendors opportunities to grow their products and solutions. It also GREATLY improves the chances for success with a “BSM Heavy” solution because the organization would have already had matured enough to approach a “BSM Heavy” solution than if they hadn’t done a “BSM Lite” solution in the past.

ScienceLogic: Is “BSM Lite” more appropriate for a small or midsized organization, or does it apply equally to large companies? Is there an ideal profile for a company that can successfully implement a BSM strategy? Is there a different profile for “BSM Lite”?

Doug McClure: From an economic perspective, the concepts of “BSM Lite” are appropriate for all companies.  Remember, with “BSM Lite” we’re focused on identifying ways to make the goals and objectives of BSM easier to implement and in a more cost effective way.  Any company concerned about their IT cost overhead should care about this, especially when the risks of starting out with a “BSM Heavy” type deployment are much greater and the time to value generally much longer.

The “ideal” profile for any company is one where the BSM initiative begins by establishing top level buy in through creation of a formal BSM strategy for the company. This BSM strategy personalizes how the company defines what BSM is, what value the company expects from it, and how it will use BSM as a competitive differentiator for delivery of its business and IT services, products, etc.

The organizational “profile” I’ve seen most successful is when implementing a BSM strategy originates from within or actively includes a group that many companies have now that serves as a liaison or relationship management role between the various lines of business and IT. Sometimes this group is often seen as the gatekeeper to filter (and hinder) business driven requirements into the IT organization. In the ideal scenario, this group works very closely with the business and IT (usually staffed by business people and not IT people) to understand both the business side and IT side of complex business services and applications. 

Apart from the traditional IT components, what this group can do is help IT really understand the business perspective.  Analysis of the impact on the business in business terms is only possible by collaborating with a group such as this.  True value oriented BSM becomes attainable when we get to this level of IT and business alignment, cooperation, collaboration and communication.

If BSM is an IT only initiative, this will likely result in an IT centric perspective severely lacking in the necessary business perspective.  In these cases where IT doesn’t invest their BSM efforts with the business as an equal partner, the implementation ultimately becomes a “CYA” tool for IT and not achieve the desired value oriented expected.

To some degree “BSM Lite” may have an entirely different profile. If we see the price points, complexity and time to value change significantly we may see these types of deployments originate exclusively within the Line of Business. The possibility may exist where large enterprises operating in a shared IT services or IT outsourcing type model that the Line of Business brings in a “BSM Lite” solution to gain the visibility, checks and balances needed to ensure that the LoB’s needs are being met from the internal/external provider. I’d envision that “BSM Lite” may even be capable of operating within a “SaaS” model or other managed service type offering where the price points are below the signing levels triggering broader IT involvement and review.

To Be Continued…

ShareThis

ISO 27001 is recognized internationally as a structured methodology for information security. Companies that choose to adopt ISO 27001 demonstrate their commitment to high levels of information security, however it does not mandate specific procedures nor define the implementation techniques for gaining certification. Thus, companies being audited for ISO 27001 compliance deal with the same issues that plague companies facing regulatory audits: how to effectively achieve compliance and, following an audit, cost-effectively maintain it.

The Tripwire Enterprise solution provides organizations with powerful configuration control through its configuration assessment and change auditing capabilities. In this white paper, learn how with Tripwire Enterprise, organizations can quickly achieve IT configuration integrity by proactively assessing how their current configurations measure up to specifications as given in ISO 27001. This provides immediate visibility into the state of their systems, and through automating the process, saves time and effort over a manual efforts.

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.