<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="pdf:PDFVersion" content="1.3">
<meta name="xmp:CreatorTool" content="(null)">
<meta name="dc:description" content="(null)">
<meta name="pdf:docinfo:title" content="(null)">
<meta name="pdf:hasXFA" content="false">
<meta name="access_permission:modify_annotations" content="true">
<meta name="dc:creator" content="(null)">
<meta name="dcterms:created" content="2011-02-02T00:00:00Z">
<meta name="dcterms:modified" content="2011-02-07T14:41:23Z">
<meta name="dc:format" content="application/pdf; version=1.3">
<meta name="xmpMM:DocumentID" content="uuid:846ec2c0-0083-4a8f-a5c4-821bfd3a4390">
<meta name="pdf:docinfo:creator_tool" content="(null)">
<meta name="access_permission:fill_in_form" content="true">
<meta name="pdf:docinfo:keywords" content="(null)">
<meta name="pdf:docinfo:custom:CreationDate--Text" content="Wednesday, February 02, 2011">
<meta name="pdf:docinfo:modified" content="2011-02-07T14:41:23Z">
<meta name="pdf:hasCollection" content="false">
<meta name="pdf:encrypted" content="false">
<meta name="dc:title" content="(null)">
<meta name="Content-Length" content="40219">
<meta name="pdf:docinfo:subject" content="(null)">
<meta name="pdf:hasMarkedContent" content="false">
<meta name="Content-Type" content="application/pdf">
<meta name="access_permission:can_print_faithful" content="true">
<meta name="xmp:ModifyDate" content="2011-02-07T14:41:23Z">
<meta name="pdf:docinfo:creator" content="(null)">
<meta name="xmp:MetadataDate" content="2011-02-07T14:41:23Z">
<meta name="pdf:producer" content="(null)">
<meta name="dc:subject" content="(null)">
<meta name="access_permission:extract_for_accessibility" content="true">
<meta name="access_permission:assemble_document" content="true">
<meta name="xmpTPg:NPages" content="2">
<meta name="pdf:hasXMP" content="true">
<meta name="access_permission:extract_content" content="true">
<meta name="access_permission:can_print" content="true">
<meta name="X-TIKA:Parsed-By" content="org.apache.tika.parser.DefaultParser">
<meta name="X-TIKA:Parsed-By" content="org.apache.tika.parser.pdf.PDFParser">
<meta name="meta:keyword" content="(null)">
<meta name="access_permission:can_modify" content="true">
<meta name="pdf:docinfo:producer" content="(null)">
<meta name="pdf:docinfo:created" content="2011-02-02T00:00:00Z">
<meta name="CreationDate--Text" content="Wednesday, February 02, 2011">
<title>(null)</title>
</head>
<body><div class="page"><p></p>
<div class="ocr">MUSTANG

GAS COMPRESSION

February 2, 2011

Bureau of Ocean Energy, Management, Regulation and Enforcement

Director Michael R. Bromwich
1849 G Street, N. W. Washington, D.C. 20240

Dear Mr. Bromwich,

Please consider the following concerning the " should " to “must " issue on the Interim Final
Safety Rules. We feel safety is the first concern but our reasoning is stated below.

O The Interim Final Safety Rule’s “should” to “mustTM issue is a critical
one, We (MGC ) are aligned with and support the efforts of Louisiana
DNR Secretary Scott Angelle and the Back to Work Coalition to work
with you on a swiftly adopting a solution.

(1 The change from “should” to “must” for documents incorporated by
reference is unnecessarily burdensome to operators and results in some
cases of increased safety risk and some cases where compliance is
impossible.

Gi The purpose of the Interim Final Rute is to improve drilling safety — and
we believe that the compromise proposed by the Coalition does this — it
sharpens the focus of the rule to drilling safety and the specific areas of
concern that were the cause for the rule.

O We are not aware of any added safety benefit to be gained from revising
the language from “should” to “must” in over 14,000 provisions; and we
are actually aware of several instances where safety would be
compromised or compliance would be impossible. We urge you to
consider the solution put forth by the Back to Work Coalition so that we
can safely return to work in the Gulf.

The drilling safety rule is intended to promote drilling safety
enhancements. However, the rule as now written actually compromises
safety and requires a practice regardless of engineering design or specific
circumstances.
</div>

</div>
<div class="page"><p></p>
<div class="ocr">i

MUSTANG

GAS COMPRESSION

(] The “should” language in the API standards, recommended practices
and specifications is intended to allow operators the discretion to adopt the
appropriate options that best fit their circumstances — so as to not
undermine good engineering judgment, require suboptimal practices or
stifle better Innovation.

O The APT standards setting process is incredibly thorough and involves a
wide range of experts, with dozens often involved in the drafting of any
one standard. The word “should” was not used

arbitrarily. The term “should” allows operators to avoid unsound practices,
as well as apply improved designs, techniques, processes and materials.

O It is our understanding that industry has worked hard to proactively
provide a practical solution; deleting 30 CFR 250.198(a)(3) and modifying
the rule to require operators to verify and document compliance with API
RP 65 Part 2 and API RP 53 and show demonstrative proof as to how they
are considering and applying those documents to their well plans and
operations.

Sincerely

Ronnie Joseph
MGC
</div>

</div>
</body></html>