<div dir="ltr">Hi all,<div><br></div><div>Long e-mail; sorry. There is a lot of stuff circulating today around this and I've finally had some time to digest.</div><div><br></div><div>As most of you are aware DRIPs are currently due on 13th August 2015. We, like I'm sure many others, have been consulting with the CAC around implementation guidelines and what we "should" do with our DRIPs.</div><div><br></div><div>We have been asking a number of specific questions around services we offer, and early last week they provided some helpful guidance with regards to interpreting the guidelines - and particularly how to interpret both the "relevant services" and implementation steps.</div><div><br></div><div>I've been eager to distribute the information that they have been sharing; but had not had an opportunity to parse the last e-mail I received which actually gave me permission to circulate this material. They have provided a Data Retention Implementation Flow Chart which I have attached. In addition, the CAC generally provides four other documents "Data Retention Overview May 2015" which is available on the AGD website, "Data Retention Guidelines for Service Providers - v1.0 - May 2015" which seems to be only available on request but is "helpful" in general terms, "Data Retention Industry FAQ - v1.0 - May 2015" which outlines some of the types of data required to collect in a general fashion and a template for completing a DRIP which follows a similar form to the standard Interception Plan document that carriers are required to complete. These last four documents should be freely and easily available to C/CSPs who email <a href="mailto:cac@ag.gov.au">cac@ag.gov.au</a>; but I'm not clear on whether we are allowed to generally distribute these.</div><div><br></div><div>I'm copying-pasting-verbosely; so please don't shoot the messenger; but also feel free to discuss on-list. </div><div><br></div><div>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Thanks for the e-mail querying DNS requests in relation to data retention.<br></span><span class=""> <br></span><span class="">More than happy to work through questions as they come up. I’ve also attached a flow chart which we are hoping to distribute more broadly around industry. The flow-chart intends to guide providers about the order of applying the relevant provisions and where elements should be considered separately, rather than together.<br></span><span class=""> <br></span><span class="">For DNS our view is that, where the relevant service in question is an <b>internet access service</b>, the internet access service provider does not have to keep any DNS information because the DNS server is a ‘destination on the internet’ and retaining that information would reveal browsing history. So DNS for ISPs is excluded.<br></span><span class=""> <br></span><span class="">Where the relevant service in question is a <b>DNS server</b> operated by a C/CSP the analysis is different. Rather than relying on 187A(4) exclusions, the better reading is that a DNS server is not a ‘relevant service’ because under 187A(3) it does not ‘carry communications’ or ‘enable communications to be carried’. While DNS is certainly convenient to the operation of other services that do carry or enable carriage, the meaning of ‘relevant service’ is not unlimited. This reading is also consistent with an abundance of extrinsic material explaining that any information that reveals ‘browsing history’ is excluded from obligations.<br></span><span class=""> <br></span><span class="">By way of example in terms of the attached flow-chart, take a CSP that offers an internet access service, a VoIP service and a DNS server. The CSP passes step one of the chart by virtue of being a CSP, and passes step two because of either of the services it offers. It would then pick a service for step three—take the internet access service. In step four it would consider the application of ‘session’ to that relevant service. In this case the session would be the assignment of a private-IP to the customer. It would then apply the data set to that definition of session for step six – i.e. when did the session begin and end, what identifiers were allocated during the session etc. Then, because it is an internet access service, it would apply the exclusion to remove all ‘destination’ information, including DNS and IP addresses etc.<br></span><span class=""> <br></span><span class="">The answer to step seven is ‘yes’ because of the VoIP service is another relevant service that needs to be considered. The process would then repeat. For VoIP, each ‘session’ would be each call scenario rather than each packet. The data set would be applied to each call, and would include source and destination information for those calls as well as timestamps etc. The ‘destination’ exclusion does not apply to a VoIP service, so the destination information would not be carved out. The CSP does not offer any more relevant services because the DNS server or its internal corporate network etc are not ‘relevant’. The CSP could the begin completing its DRIP.<br></span><span class=""> <br></span><span class="">We intend to make both the exclusion of DNS and the operation of the flow-chart clear in the next version of the guidance materials. In the meantime you are more than welcome to distribute to your colleagues.</span></blockquote>











</div><div><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"></blockquote></div><div><br></div>This matches well with the advice we are giving to our customers now regarding the creation of DRIPs to submit. This bit is "our" (read Real World's) advice to our staff and customers and so if you so feel that you must I'll accept flaming criticism here.<div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote"><b>1. Identify if your business is required to retain data<br></b>If you believe you are not required to retain data, you should start this process by contacting the Communications Access Co-ordinator (<a href="mailto:cac@ag.gov.au" target="_blank">cac@ag.gov.au</a> or <a href="tel:02%206141%202884" value="+61261412884" target="_blank">02 6141 2884</a>), outlining your business and seeking clarification on whether you are covered by this legislation.<br><b>2. Identify the relevant services your business provides<br></b>This sounds obvious, but for a number of our service providers this may pose a challenge, as it has for us. One of the "good" things about an elastic business model is that you can be flexible to meet your customer needs; however the legislation and implementation are not geared towards businesses that operate under this model.<br><i>It is important to note that your data retention obligations will be considered per "service" you provide.</i><i><br></i>For example:<br>Our list of covered products includes:<ul><li style="margin-left:15px">[cut short because you don't all care]</li></ul></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">Our obligations are only considered on the basis of these named services.<br><b>3. Identify your customers<br></b>It's important you identify your customers for each of these services. Meta Data Retention is to be retained per location. The AGD have indicated to us that they intend to view a single corporation as a "customer", so for example if you provide a private WAN service to a business with an internet gateway your retention obligations would likely only apply to the point where the traffic egresses to the internet.<br>You will need to retain details identified in the data retention matrix for each customer for <i>two years after their service is terminated.</i><br><b>4. Identify any excluded services<br></b>Some services, such as Café Free Wifi are explicitly excluded from the legislation.<br><b>5. Identify what data you actually need to collect<br></b>This is where life gets difficult. We have attached the list of data that is contained in the legislation that makes up the "data set". An example would be that you would need to collect and retain customer data for a period of two years. You would need to obtain session start/stop details on an internet access service. You would need to obtain logs on an email service you run for your clients. You would need to retain call logs for any telephony service you provide. You would need to retain any data with regards to diversions or call forwards you may put in place for a customer as a service.<br>Make sure you have a plan for each service. Even if the service is not delivered on your infrastructure (i.e. you are a Virtual Service Provider) you <i>must still have a plan to retain this data</i>. Ultimately, the law holds you, as a service provider, responsible for the retention of this data. For a number of our customers this will mean that you must work with us to meet your retention obligations.<br>We have found this to be the greatest area of concern both internally and within the CSP community. Our general approach has been to try and determine the "spirit" of the legislation with regards to the data retention policy and then consult with the Communications Access Co-ordinator at the Attorney General's Department around the specifics of our plans. As we move through this process we remain happy to discuss this individually with service providers as they consider their obligations.<br><b>6. Identify what data you already are retaining<br></b>For a number of our customers, the majority of data will already be obtained in some form or other. This is a good starting point for your retention obligations. <i>Note that the legislation indicates that it is illegal to actively reduce the data you are retaining where it might be related to your Data Retention obligations.</i><i><br></i><b>7. Identify what data you require a third party provider to collect on your behalf<br></b>Where you are not in a position to collect the data yourself, or rely on a third party provider, such as Real World, to collect this data for you. Once you have done this, make contact with the third party provider outlining what you may require them to collect on your behalf. The provider may then give you some specific advise.<br><b>8. Identify how you intend to store your data<br></b>The Meta Data Retention Legislation requires you to store your data encrypted. This is probably not practical in a lot of situations. Ensure you have a plan for how you will encrypt data, and, for information that can not be encrypted ensure you have a plan on how you will ensure the security of this data.<br><b>9. Submit a Data Retention Implementation Plan (DRIP)<br></b>Real World or the CAC will provide you with a draft template for your DRIP. <br>This is perhaps the most important component of the process. A DRIP allows a provider up to 18 months to become compliant with any data retention obligations they have for services. It is also an important legal document, as it outlines how you are intending to be compliant with the legislation. The CAC will review these documents and advise if they "approve" of both your implementation plan, and your plans for retention.<br>We would recommend that, at a minimum, your DRIP identifies:<ul><li style="margin-left:15px">What data you intend to collect for each of your services</li></ul><ul><li style="margin-left:15px">How you intend to store the data</li></ul><ul><li style="margin-left:15px">What data you currently collect</li></ul><ul><li style="margin-left:15px">How long you store the data you currently collect</li></ul><ul><li style="margin-left:15px">When you intend to start collecting the required data that you do not currently collect</li></ul><ul><li style="margin-left:15px">When you intend to start storing the data for the minimum 2 years once it is collected</li></ul><ul><li style="margin-left:15px">How you intend to encrypt the data, and if it is not encrypted how you intend to store it</li></ul>The Communications Access Co-ordinator will review your DRIP and then provide you notice as to whether or not they find your plan acceptable. In the event that there is ever a dispute with an enforcement agency or ACMA, an approved DRIP would be vital to any defence of your position.</blockquote><div><div>
</div></div><div><br></div></div><div>We can still live in hope of an "extension" to submit our DRIPs, but to be honest I think if we "think" we're going to get one we are actually dreaming. That doesn't mean that we shouldn't ask/lobby/assert our need for this, but I think it's unlikely.<br></div><div><br></div><div>So at the end of this, hopefully it helps some other providers out there. I'm trying a "let's not stick my head in the sand and hope it goes away" approach. And with that said, on a personal note, I'm quite happy to enter into constructive discussions about this; and I know that IA and CA are both also keep to help get through the FUD to a sensible position where people can actually deal with this.</div><div><br></div><div>Thanks,</div><div>Andrew</div><div><br></div></div>