Re: Avoid unknown code sources (was: Re: RFC archival format)
On 9 jul 2009, at 1:56, Douglas Otis wrote: The concern was voiced in opposition to suggestions for using Word input files as a means to generate inputs for I-D or RFC generation utilities. Nobody suggested that. I said that it would be useful to be able to use a standard issue word processor to write drafts. As I explained in a subsequent message, what I meant by that is any word processor that can generate a document with styles. Word is one of those word processors, but certainly not the only one, and you'll never hear me recommend Word for anything. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Patrik,
Problem with LaTeX and TeX is the need for class libraries,
How is that different from needing the latest tcl code for xml2rfc ?
and the lack of agreed upon way of distributing a
LaTeX/TeX file with the class files needed (part from what is standard),
or lack of automatic tools that include needed things from the class files to
the source file.
Still nowhere near the combination of opaque processing instructions needed for
xml2rfc.
Something like \documentclass[std,trust200902]{RFC} at the top of the file
is all that would be needed.
Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Panel at IETF 75 -- Securing the DNS: Towards a more secure Internet
Dear colleagues: Following the success of the Internet Society's IPv6 panel held at the IETF 74 venue, I want to make you aware of panel event to be held during the IETF 75 week in Stockholm, Sweden: Securing the DNS: Towards a more secure Internet 11:45am - 12:45pm (UTC+2), Tuesday 28 July Clarion Sign Hotel, Stockholm, Sweden (opposite the IETF 75 venue) Light lunch provided; registration is free The Domain Name System (DNS) is one of the critical operational elements of the Internet, creating a human environment that allows names to be mapped to host addresses across the Internet. But the DNS was established with no inherent security mechanisms, making it vulnerable to certain malicious activities, such as DNS spoofing, where attackers make false assertions about DNS data in order to misdirect traffic to unwanted sites. Efforts are underway on several fronts, developing better Internet security technologies and practices through open standards development and the collaborative work of developers, operators, and industry. One key effort is DNSSEC (short for DNS Security Extensions) - a set of open standards developed to authenticate DNS data using public key infrastructure to digitally sign DNS records, providing a high level of security to core transactions. It does not solve all online security issues, but it is an important step towards a more secure online experience. Leaders from across the Internet community are actively engaged in work to drive the broad deployment of DNSSEC and other standards for continuous improvements in Internet security. In this session - designed to make these issues accessible to a broader audience - the Internet Society's Leslie Daigle will lead a distinguished panel of some of the world's leading developers, administrators, and operators of Internet infrastructure. What are their experiences? What problems have they overcome? And what do they see as the next steps towards a more robustly secure Internet? All are welcome to participate, but seats are limited, so please register in advance. More information, including free online registration at: http://www.isoc.org/dns For those unable to attend, an live audiocast will be available - check the website above closer to the date for details. Russ Housley IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If we had a DTD that worked in other pieces of software, it could be converted using commonly available software into text formats. What is supplied with xml2rfc works fine with other pieces of software, per Ned's response. Perhaps I should email Ned I've tried pulling the DTD into Dreamweaver several times, with no success. I did email the list once, and the response I received was along the lines of, if you get that working, a lot of people would be happy. I never received a response saying, it works, and this is the way you need to pull the DTD in. Of course, we might be talking about two different things. You can use Dreamweaver as a text editor on the DTD, but you can't do the same thing you do in XMLMind, which is to have the sections set out in the other editing modes. I can use emacs if I'm going to have to memorize all the sections, and how to put them together--no need to use Dreamweaver as a text editor. :-) Russ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpVNh4ACgkQER27sUhU9OQUbgCdHerc1DviaFiw99qXKTlYBTq3 qJAAoMkBTrGxLC4pmLtU6TcBDAs0Nd3H =bJX8 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 08:07, Doug Ewell wrote: As always when this discussion occurs, there are at least three different issues swirling around: 1. ASCII-only vs. UTF-8 2. Plain text vs. higher-level formatting, for text flow and readability 3. Whether it is a good idea to include high-quality pictures in RFCs There are not the same issue, and it would help combatants on both sides not to mix them up. I admire the attempt to separate these issues into orthogonal concerns, but I don't think it can succeed. The common aspect of all these issues is the question of whether our archival format should A) continue to be limited to a string of ASCII characters formatted for printing with a fixed-width font, or B) if it should be expanded to include a document archival format that can preserve font, style and figures. There is a related but separable topic of discussion once option B) is open for debate: what precisely should be the set of primary natural languages used in IETF documents? Should it continue to be English only? I'd very much prefer to see *that* discussion vigorously deferred while our archival format continues to be the largest practical obstacle to multilingualism. I believe there are no reasonable candidates for archival formats that can preserve font, style and figures without also providing for localization. I don't know where the argument don't help authors prepare I-Ds using the tools of their choice, unless they are open-source fits into this picture. Compared to the previous two issues, this one is just not so much important. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF languages, was: something about RFCs
On 9 jul 2009, at 18:15, james woodyatt wrote: B) is open for debate: what precisely should be the set of primary natural languages used in IETF documents? Should it continue to be English only? I'd very much prefer to see *that* discussion vigorously deferred while our archival format continues to be the largest practical obstacle to multilingualism. There are two things that together make it completely impossible to adopt more working languages: 1. We don't have any other languages in common than English 2. We don't have the money for translation/interpretation services Dus als we naast Engels ook andere talen gaan gebruiken betekent dat dat de niet-Engelse documenten maar door een deel van de IETF- participanten gelezen kan worden, wat natuurlijk niet de bedoeling is. Or: So if we start using other languages in addition to English then the non-English documents can only be read by part of the IETF- participants, which of course defeats the purpose. Now I'd be very happy to be able to conduct IETF business in Dutch, but I'd be very much opposed to having to learn a new language to participate in the IETF. It took me long enough to learn English... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF languages, was: something about RFCs
On Jul 9, 2009, at 10:01, Iljitsch van Beijnum wrote: There are two things that together make it completely impossible to adopt more working languages [...] My point wasn't to argue that we should consider working in non- English languages, but simply to explain why it's reasonable to rule that discussion out of scope while we get on with talking about archival formats: there is no reason to believe that expanding our archival formats would further limit our future options for adopting new working languages. (I'm thinking centuries into the future here.) -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Experiment Results: More Meeting Time on Friday
The IESG conducted an experiment during IETF 73 in Minneapolis and IETF 74 in San Francisco to increase face-to-face meeting time by adding two one hour meeting slots on Friday afternoon. While it is recognized that these meeting slots are not preferred by anyone, these meeting slots have been very useful in resolving conflicts between WGs with overlapping participants. The we expect to continue to make use of Friday afternoon meeting slots in the future. The Friday schedule will look something like this: 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II Thanks for all you do for the Internet and the IETF. On behalf of the IESG, Russ Housley IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Datatracker Testing, Duplicate Last Call Announcements
All - There is an ongoing but intermittant problem with the IESG Datatracker corrupting outgoing announcements. My initial attempts to apply patches and wait for the next last calls to go out to see if it worked have failed; I therefore have no choice now but to go to the brute-force method. As a result, this list will see some duplicate last-call announcements over the next few hours, as I repeatedly try to duplicate and resolve this problem directly. I'm sorry it's come to this, I really hoped I could fix the problem without disrupting this list; however, the old code is clearly so bad that I have no choice but to use high explosives. I apologize for the upcoming distruption, and beg your indulgence as I apply a bit more persuasion to the system. Thank you, Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Testing Complete, Normal Operation Resumed
All - Testing of the datatracker has been completed. Normal operations will now be resuming. Message corruption was occurring because of the way the IESG Datatracker was formatting messages. The bugs existed at 9 different locations in the code, which code was of course very old code written years ago, as is well known. A previous attempt to fix one problem for one instance exposed additional problems elsewhere in the code. But, because of the way the IESG Datatracker works (specifically that a message is created in advance and stored for future delivery), subsequent fixes did not appear to work because the broken code had already been executed and already written the broken messages into the database... where they were stored for later delivery. So, at this point, I believe that the code is fixed. However, because of the way the database is organized, I have no accurate way to target broken messages. As a result, there may be more instances of broken messages until we get the entire database hand-searched and corrected which will, needless to say, take time. Thank you for your patience. Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 151 messages in the last 7 days. script run at: Fri Jul 10 00:53:01 EDT 2009 Messages | Bytes| Who +--++--+ 11.92% | 18 | 9.85% |86404 | julian.resc...@gmx.de 7.95% | 12 | 7.89% |69269 | iljit...@muada.com 4.64% |7 | 4.90% |43000 | d...@ewellic.org 4.64% |7 | 4.82% |42339 | stbry...@cisco.com 3.97% |6 | 3.78% |33191 | john-i...@jck.com 3.97% |6 | 3.51% |30783 | yaako...@rad.com 2.65% |4 | 4.33% |38029 | b...@lowekamp.net 3.31% |5 | 3.46% |30402 | tb...@textuality.com 1.99% |3 | 3.03% |26568 | lars.egg...@nokia.com 2.65% |4 | 2.20% |19332 | martin@sap.com 1.99% |3 | 2.67% |23434 | do...@mail-abuse.org 1.99% |3 | 2.35% |20641 | ma...@isc.org 1.99% |3 | 2.24% |19663 | melinda.sh...@gmail.com 1.99% |3 | 1.87% |16420 | j...@apple.com 1.99% |3 | 1.69% |14873 | d.b.nel...@comcast.net 1.99% |3 | 1.67% |14678 | c...@tzi.org 1.99% |3 | 1.66% |14596 | d...@dcrocker.net 1.99% |3 | 1.62% |14223 | ste...@aaa-sec.com 1.32% |2 | 1.73% |15203 | p...@cisco.com 1.32% |2 | 1.56% |13672 | stefan.win...@restena.lu 1.32% |2 | 1.48% |13008 | jmp...@cisco.com 1.32% |2 | 1.40% |12318 | r...@cisco.com 1.32% |2 | 1.40% |12297 | ned+i...@mauve.mrochek.com 1.32% |2 | 1.37% |12024 | t...@att.com 1.32% |2 | 1.35% |11870 | ero...@cisco.com 1.32% |2 | 1.35% |11820 | hous...@vigilsec.com 1.32% |2 | 1.30% |11419 | a...@shinkuro.com 1.32% |2 | 1.23% |10781 | jo...@iecc.com 1.32% |2 | 1.19% |10444 | c...@csperkins.org 1.32% |2 | 1.19% |10440 | j...@joelhalpern.com 1.32% |2 | 1.12% | 9814 | bra...@isi.edu 1.32% |2 | 1.10% | 9683 | paul.hoff...@vpnc.org 1.32% |2 | 0.96% | 8427 | g...@amsl.com 0.66% |1 | 1.09% | 9526 | presn...@qualcomm.com 0.66% |1 | 1.02% | 8973 | hal...@gmail.com 0.66% |1 | 0.83% | 7289 | jason_living...@cable.comcast.com 0.66% |1 | 0.81% | 7113 | nar...@us.ibm.com 0.66% |1 | 0.80% | 6992 | wbee...@cisco.com 0.66% |1 | 0.76% | 6671 | mary.bar...@nortel.com 0.66% |1 | 0.74% | 6479 | d...@cridland.net 0.66% |1 | 0.71% | 6205 | petit...@acm.org 0.66% |1 | 0.70% | 6166 | lber...@labn.net 0.66% |1 | 0.70% | 6153 | alh-i...@tndh.net 0.66% |1 | 0.66% | 5751 | michelle.cot...@icann.org 0.66% |1 | 0.64% | 5594 | antonyjeyase...@gmail.com 0.66% |1 | 0.64% | 5574 | elw...@dial.pipex.com 0.66% |1 | 0.62% | 5417 | magnus.westerl...@ericsson.com 0.66% |1 | 0.61% | 5329 | mcqui...@pobox.com 0.66% |1 | 0.60% | 5222 | dcroc...@bbiw.net 0.66% |1 | 0.57% | 5044 | wjh...@hardakers.net 0.66% |1 | 0.57% | 5019 | hkap...@acmepacket.com 0.66% |1 | 0.57% | 4989 | sh...@isc.org 0.66% |1 | 0.57% | 4983 | t...@americafree.tv 0.66% |1 | 0.55% | 4858 | j...@jlc.net 0.66% |1 | 0.55% | 4841 | bmann...@isi.edu 0.66% |1 | 0.53% | 4665 | m...@isoc.org 0.66% |1 | 0.51% | 4460 | m...@let.de 0.66% |1 | 0.37% | 3239 | i...@ietf.org +--++--+ 100.00% | 151 |100.00% | 877617 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Experiment Results: More Meeting Time on Friday
The IESG conducted an experiment during IETF 73 in Minneapolis and IETF 74 in San Francisco to increase face-to-face meeting time by adding two one hour meeting slots on Friday afternoon. While it is recognized that these meeting slots are not preferred by anyone, these meeting slots have been very useful in resolving conflicts between WGs with overlapping participants. The we expect to continue to make use of Friday afternoon meeting slots in the future. The Friday schedule will look something like this: 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II Thanks for all you do for the Internet and the IETF. On behalf of the IESG, Russ Housley IETF Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
Proposed Standard The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Trust Anchor Format ' draft-ietf-pkix-ta-format-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17759rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-msec-tesla-for-alc-norm (Use of TESLA in
the ALC and NORM Protocols) to Experimental RFC The IESG has received a request from the Multicast Security WG (msec) to consider the following document: - 'Use of TESLA in the ALC and NORM Protocols ' draft-ietf-msec-tesla-for-alc-norm-07.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14828rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and
IKEv2) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'ECP Groups for IKE and IKEv2 ' draft-solinas-rfc4753bis-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-08-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18680rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-simple-interdomain-scaling-analysis
(Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' draft-ietf-simple-interdomain-scaling-analysis-07.txt as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15780rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and IKEv2) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'ECP Groups for IKE and IKEv2 ' draft-solinas-rfc4753bis-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-08-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18680rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and IKEv2) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'ECP Groups for IKE and IKEv2 ' draft-solinas-rfc4753bis-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-08-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18680rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-simple-interdomain-scaling-analysis
(Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' draft-ietf-simple-interdomain-scaling-analysis-07.txt as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15780rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-simple-interdomain-scaling-analysis (Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC
The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' draft-ietf-simple-interdomain-scaling-analysis-07.txt as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15780rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Testing Complete, Normal Operation Resumed
All - Testing of the datatracker has been completed. Normal operations will now be resuming. Message corruption was occurring because of the way the IESG Datatracker was formatting messages. The bugs existed at 9 different locations in the code, which code was of course very old code written years ago, as is well known. A previous attempt to fix one problem for one instance exposed additional problems elsewhere in the code. But, because of the way the IESG Datatracker works (specifically that a message is created in advance and stored for future delivery), subsequent fixes did not appear to work because the broken code had already been executed and already written the broken messages into the database... where they were stored for later delivery. So, at this point, I believe that the code is fixed. However, because of the way the database is organized, I have no accurate way to target broken messages. As a result, there may be more instances of broken messages until we get the entire database hand-searched and corrected which will, needless to say, take time. Thank you for your patience. Glen Barney IT Director AMS (IETF Secretariat) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
