minor fixes to xml and Makefile

Makefile

@@ -1,4 +1,4 @@
 security-threats.txt:
 
 %.txt: %.xml
-	XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc $? $@
+	unset DISPLAY; XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc $? $@	

security-threats.xml

@@ -57,7 +57,7 @@
 <?rfc subcompact="no" ?>
 <!-- keep one blank line between list items -->
 <!-- end of list of popular I-D processing instructions -->
-<rfc category="info" docName="draft-ietf-roll-security-threats-01"
+<rfc category="info" docName="draft-ietf-roll-security-threats-02"
      ipr="trust200902">
   <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" hey will automatically be output with "(if approved)" -->
 
@@ -190,7 +190,7 @@
       </address>
     </author>
 
-    <date month="February" year="2013"/>
+    <date month="June" year="2013"/>
 
     <!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date).  With drafts it is normally sufficient to specify just the year. -->
 
@@ -468,9 +468,6 @@ DataBase   A data storage DataBase
             non-repudiation is not an issue because it does not apply to
             routing protocols, which are machine-to-machine protocols.
             Further, with the LLN application domains as described in <xref
-            target="RFC5548">RFC5548</xref><xref
-            target="RFC5673">RFC5548</xref><xref
-            target="RFC5826">RFC5548</xref><xref
             target="RFC5867">RFC5548</xref>, proactive measures are much more
             critical than retrospective protections. Finally, given the
             significant practical limits to on-going routing transaction