From e4b9e14ae14ef1e38e9e57f207dd42eed4c1ef6e Mon Sep 17 00:00:00 2001
From: Alexandre Dulaunoy <a@foo.be>
Date: Fri, 27 Dec 2013 09:46:30 +0100
Subject: [PATCH] Draft draft-bortzmeyer-dnsop-dns-privacy reference added

As bibxml3 is missing the draft, it's still a comment.
---
 i-d/pdns-qof.xml | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/i-d/pdns-qof.xml b/i-d/pdns-qof.xml
index 77a7da0..4f7cf71 100644
--- a/i-d/pdns-qof.xml
+++ b/i-d/pdns-qof.xml
@@ -20,6 +20,9 @@
 <!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
 
 <!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
+
+<!-- <!ENTITY I-D.draft-bortzmeyer-dnsop-dns-privacy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bortzmeyer-dnsop-dns-privacy"> TO ENABLE when bibxml3 is back to normal -->
+
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <!-- used by XSLT processors -->
@@ -209,7 +212,7 @@ CR              = %x0D
 			 decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>.
 
 			 The resource record type can be any values as described by IANA in the DNS parameters document in the section 'DNS Label types' (http://www.iana.org/assignments/dns-parameters).
-			 Currently known and supported textual descriptions of rrtypes are: A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6. 
+			 Currently known and supported textual descriptions of rrtypes are: A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6.
 			 A client MUST be able to understand these textual rtype values. In addition, a client MUST be able to handle a decimal value (as mentioned above) as answer.
 			</t>
 			</section>
@@ -272,8 +275,7 @@ CR              = %x0D
 	<section anchor="Privacy" title="Privacy Considerations">
 		<t>Passive DNS Servers collect DNS answers from multiple collecting points ("sensors") which are located on the Internet-facing side of DNS recursors. In this process, they intentionally omit the source IP, source port, destination IP and destination port. Furthermore, since multiple sensors feed into a passive DNS server, the resulting data gets mixed together, reducing the likelihood that Passive DNS Servers are able to find out much about the actual person querying the DNS records nor who actually sent the query. In this sense, passive DNS Servers are similar to keeping an archive of all previous phone books - if public DNS records can be compared to phone numbers - as they often are.
 
-		Nevertheless, the authors encourage Passive DNS implementors to take special care of privacy issues. <!-- FIXME: add reference / link --> draft-bortzmeyer-dnsop-dns-privacy-01.txt is an excellent starting point for this.
-		
+		Nevertheless, the authors encourage Passive DNS implementors to take special care of privacy issues. [draft-bortzmeyer-dnsop-dns-privacy] is an excellent starting point for this.
 		Finally, the overall recommendations in <xref target="RFC6973">RFC6973</xref> should be taken into consideration when designing any application which uses Passive DNS data.</t>
 	</section>
     <section anchor="Security" title="Security Considerations">
@@ -384,6 +386,7 @@ CR              = %x0D
 
       &I-D.narten-iana-considerations-rfc2434bis;
 
+      <!-- &I-D.draft-bortzmeyer-dnsop-dns-privacy; -->
     </references>
 
   </back>