Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
MX records are the norm. There is even a constituency in the email ops community that believes use of A (and ) records should be deprecated. In any event, the kind of anti-abuse techniques that are predicated on having abusers be lazy or sloppy has, at best, short-term benefits, because the bad actors are quite good at adapting. d/ On 2/26/2010 12:11 PM, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. Begin forwarded message: From: Glen via RTietf-act...@ietf.org Date: 25 February 2010 18:16:44 GMT To: m...@sabahattin-gucukoglu.com Subject: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam Reply-To: ietf-act...@ietf.org in-reply-to:30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com references:rt-ticket-24...@rt.ietf.org 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com message-id:rt-3.6.5-24276-1267121804-1766.24364-...@rt.ietf.org rt-ticket: rt.ietf.org #24364 rt-originator: g...@amsl.com Thank you! Regrettably, we got many MANY complaints in the past from IETF community members who objected strongly to the absence of MX records. So although I personally feel as you do, I cannot make the suggested change at this time. Perhaps the spirit of things has changed. You are welcome to bring this up on the IETF list if you want, and to quote this response. Having been beaten down once, I'm not prepared to fight that battle again just yet. :-) Glen On Thu Feb 25 06:08:22 2010, m...@sabahattin-gucukoglu.com wrote: In the spirit of abiding by the rules we strive so hard to write ... :-) mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: SSH is not a bad security protocol. It provides a very high level of protection against high probability risks with little or no impact on the user. There is a narrow window of vulnerability to a man in the middle attack. As a security researcher, I can teach you that the security you observe is not of SSH but of return routability. Return routability over many third party ISPs is not 'verifiable', of course. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT!
Florian Weimer wrote: As DNSCurve protection is like DH, it is subject to MitM attacks, which is no different from simple nonce. I think the expectation is that you learn the server names (and hence their keys) of child zones from parents, under DNSCurve's cryptographic protection. This is slightly different from plain DH. No, it is not expected that gtld servers will become ???.gtld-servers.net, only to cause message size overflow. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT!
Florian Weimer wrote: No, it is not expected that gtld servers will become ???.gtld-servers.net, only to cause message size overflow. Wouldn't compression kick in if they shared keys (assuming that DNSCurve doesn't sift the key from only the first label), making the overhead negligible? There are several ways, such as anycasting, to overcome the problem. However, they will require wide distribution of secret keys. Anyway, my point is that there was no expectation. Another evidence is lack of the concept of root key and other things. If relying on security of root and other zones, which are not really secure, was seriously considered, there should be provisions for more complex mechanisms such as key roll over to make the system a little less insecure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. I checked with some people who run mail for a lot of domains, and they assure me that spambots will try to deliver to the A record even if there is an MX. Where did you get the idea that not having an MX offers protection from spambots? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Hi Sabahattin, At 20:11 25-02-10, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. While we are on this topic, which of the following methods would you recommend for a point of contact: 1. mailto [1] [2] [7] [8] [10] [12] [13] 2. email address without mailto [9] 3. AT [3] 4. at [4] [11] 5. [5] 6. email address as an image [6] Regards, -sm 1. http://www.ietf.org/secretariat.html 2. http://www.icann.org/en/announcements/announcement-18feb10-en.htm 3. http://www.iab.org/about/members.html 4. http://www.itu.int/ITU-T/othergroups/ipv6/ 5. http://www.iana.org/assignments/dns-parameters 6. http://www.rfc-editor.org/ 7. https://www.arin.net/announcements/2010/20100224.html 8. http://www.ripe.net/news/2010-be-heard.html 9. http://www.apnic.net/publications/news/2010/apnic-29-consultation 10. http://lacnic.net/en/anuncios/2010_lacnicxiii-becas.html 11. http://www.afrinic.net/press_release_le_050210.htm 12. http://isoc.org/wp/newsletter/?p=1567 13. http://www.un.int/wcm/content/site/portal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
--On Friday, February 26, 2010 6:49 AM + John Levine jo...@iecc.com wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. That's not a very good idea. I wouldn't count on zombies ignoring the IETF, nor would I count on there not being real MTAs that will hiccup if there's no MX. I've certainly seen filtering setups that view mail from domains without MX records with scepticism, since there would now be no techincal difference between mail from the IETF and mail from a bot-infected wifi printer. I very much agree with this statement. Not having an MX won't do a single bit of good against bots. In fact I'd argue the *opposite* case, that not having an A record does more. They definitely seem to deliver more often to the A rather than the MX. Having worked at and built a number of large hosting operations where the WWW servers (A records) would get *LOTS* of SPAM bot attempts. I'd argue not having an MX will cause far more problems with legitimate mail servers and e-mail activity. If you want to filter the spam, filter the spam like everyone else does. It's not rocket science. Don't set a bad example for the rest of the world. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
On 2010-02-26 20:42 William Allen Simpson said the following: As of Feb 9th, the IESG posted a second status boilerplate. But the tool doesn't yet recognize it Be warned. Specifics, please? * Is this the idnits tool or some other tool? * Which version did you use? * Did you use the downloaded script or the web-service, and if so, with which URL? * Which boilerplate change specifically isn't recognized? I.e., what is your input? * What is the output of the tool, given your input? Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: Once you have established an SSH relationship That's the (lack of) security of SSH by return routability. PERIOD. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard
Hi Donald, as the document shepherd, I need to set the record straight on this, as your statement is simply false. In checking that the WGLC comments had been handled in the following document update, I looked at both the email thread you participated in and the updated document. In this case, the editor very clearly responded to your inputs and made significant changes to the document. You can find an entirely new section (9.7 Connectionless Resets) starting in version 09 of the draft, which specifically responds to your comments with resolutions that were discussed on the mailing list. This section discusses maintenance of the traffic keys across reboots which answers your concern and makes the practice a SHOULD which is stronger even than the MAY that you mention below. I do not understand why you feel like your inputs were ignored, but I hope that you'll agree that this was not the case. From: tcpm-boun...@ietf.org [tcpm-boun...@ietf.org] On Behalf Of Smith, Donald [donald.sm...@qwest.com] Sent: Friday, February 26, 2010 2:45 PM To: 'ietf@ietf.org'; 'IETF-Announce' Cc: 't...@ietf.org' Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (TheTCP Authentication Option) to Proposed Standard I have commented numerous times that with a paragraph that specifically provides vendors to make connection-less resets == attack packets this will not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to explain why to someone that is unwilling to compromise with even a a vendor MAY maintain state to allow connectionless resets to work. (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: tcpm-boun...@ietf.org [mailto:tcpm-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 24, 2010 10:25 AM To: IETF-Announce Cc: t...@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' draft-ietf-tcpm-tcp-auth-opt-10.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 ietf@ietf.org mailing lists by 2010-03-10. 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-tcpm-tcp-auth-o pt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=16685rfc_flag=0 ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
The short response to the information below is that it seems that the secretariat is still running version 2.12.00 of idnits, while the newer version 2.12.01 (released 4 Feb 2010) accepts the new boilerplate correctly. I'm notifying the secretariat so they can update to the newest version. --- The longer response is that diagnosing this required much more time than would have been required if all the requested and available information had been supplied below (instead of flippancy); further comments inline: On 2010-02-27 00:03 William Allen Simpson said the following: Henrik Levkowetz wrote: On 2010-02-26 20:42 William Allen Simpson said the following: As of Feb 9th, the IESG posted a second status boilerplate. But the tool doesn't yet recognize it Be warned. Specifics, please? * Is this the idnits tool or some other tool? * Which version did you use? Whatever the IETF Secretariat is using. Not particularly helpful. The program version is indicated on the first line of its output. It would have been good if you'd provided the full output below, instead of snipping away part of it. * Did you use the downloaded script or the web-service, and if so, with which URL? * Which boilerplate change specifically isn't recognized? I.e., what is your input? http://www.ietf.org/ietf-ftp/1id-guidelines.txt (I doubt the text below is what you actually submitted; but at least it does show the boilerplate you refer to.) I-D Guidelines R. Housley (for the IESG) Vigil Security 9 February 2010 In the modern Internet, the need for stable URLs is more important than providing multiple sites around the world to obtain I-Ds. Also, search engines have replaced the need for a file containing a collection of I-D abstracts. As a result, the second choice is: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. * What is the output of the tool, given your input? As indicated earlier, what you provide here is only part of the output, and you've managed to snip away the part which would have made the actual problem obvious without detective work. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? 1id_guidelines, paragraph 1: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. ... text found in draft: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working ..^ documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current.; ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. 1id_guidelines, paragraph 3: The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html; ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 1id_guidelines, paragraph 4: The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html; Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 05:19, Dean Anderson wrote: I get spam to hosts with MX records. I don't think removing MX records will have any effect on spam. Spambots, aren't fully autonomous agents I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to. I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now). It's not the first time, and this technique is still damned effective. I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated. Now I'm waiting for the TTL to expire the record on caches. I'm convinced that is useful, anyway. Sure, it's a short-term hack (like all spam countermeasures), but it works. And why should we be afraid of standards compliance, in the very organisation that standardises? existing independently, they are programs written by people who want to conduct abuse for some purpose (annoyance, extortion, etc). The ones I'm talking about are distributed by viruses and trojan horses. They run on Windows, of course. They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process. They barf when MX records fail to appear in a query result for MXs of a domain, for the most. Regarding the effect (if there even is one) of skipping domains without MX records, there are only two cases to analyze: Its either an oversight in the program, or its done on purpose. Even supposing their current programs skip domains without MX records by some oversight, the spambot programmers will easily fix that. Supposing the current programs skip domains without MX records on purpose, then do you really want to go along with whatever purpose that might be? I wouldn't. Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have. Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case. On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called ietf.org. and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there. The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to d eath on redundantly-hosted mail servers. And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently. But I do find it noteworthy that the IETF doesn't even follow its own recommendations on email. The level of IETF spew, by which I mean telling other people what to do by issuing standards while not doing it themselves, grows more ever day. This incident is another discredit to the IETF, particularly to the leadership of the IETF or perhaps the IETF secretariat, that I will have to document at IETF watch. I want to say that I would *prefer* that MX records be published for host which *do not* receive mail. This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached. I also want to say that I am in support of the Purist point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently. There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974. I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far. I would be much obliged if the required work were done for clarifying any opposing view to current standards. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Ever heard about not cross-posting and not feeding trolls? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Friday, February 26, 2010 10:57 PM To: Dean Anderson Cc: ietf-hon...@lists.iadl.org; ietf-s...@imc.org; ietf@ietf.org; postmas...@ops.ietf.org Subject: Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org.,Remove MX Records For Less Spam On 26 Feb 2010, at 05:19, Dean Anderson wrote: I get spam to hosts with MX records. I don't think removing MX records will have any effect on spam. Spambots, aren't fully autonomous agents I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to. I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now). It's not the first time, and this technique is still damned effective. I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated. Now I'm waiting for the TTL to expire the record on caches. I'm convinced that is useful, anyway. Sure, it's a short-term hack (like all spam countermeasures), but it works. And why should we be afraid of standards compliance, in the very organisation that standardises? existing independently, they are programs written by people who want to conduct abuse for some purpose (annoyance, extortion, etc). The ones I'm talking about are distributed by viruses and trojan horses. They run on Windows, of course. They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process. They barf when MX records fail to appear in a query result for MXs of a domain, for the most. Regarding the effect (if there even is one) of skipping domains without MX records, there are only two cases to analyze: Its either an oversight in the program, or its done on purpose. Even supposing their current programs skip domains without MX records by some oversight, the spambot programmers will easily fix that. Supposing the current programs skip domains without MX records on purpose, then do you really want to go along with whatever purpose that might be? I wouldn't. Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have. Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case. On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called ietf.org. and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there. The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to d eath on redundantly-hosted mail servers. And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently. But I do find it noteworthy that the IETF doesn't even follow its own recommendations on email. The level of IETF spew, by which I mean telling other people what to do by issuing standards while not doing it themselves, grows more ever day. This incident is another discredit to the IETF, particularly to the leadership of the IETF or perhaps the IETF secretariat, that I will have to document at IETF watch. I want to say that I would *prefer* that MX records be published for host which *do not* receive mail. This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached. I also want to say that I am in support of the Purist point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently. There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974. I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far. I would be much
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 15:42, John Levine wrote: mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. I checked with some people who run mail for a lot of domains, and they assure me that spambots will try to deliver to the A record even if there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. To answer your question, you'd have to try that for yourself. I am now getting mostly phishes and scams, but very few member enhancement, expensive watches, wonder cures or viral mails. A few, of course - but not many. And yes, some of them are originated from PBL-listed addresses. Oh, and an IPv6-enabled foreign language spam or three. Lovely. The spammers have got there first. Brief and superficial inspection shows that the scams and phishes are submitted mostly via webmails and legit relays. I'm not sure why that is, though I have read stories about hijacked Internet cafes. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Glenn Kowack appointed as Transitional RFC Series Editor
Dear Colleagues, I am happy to announce that Glenn Kowack will be the Transitional RFC Series Editor(RSE). Glenn will take up his responsibilities as of March 1. His main responsibility [2] is that of formulating the RSE as defined in RFC5620 in practice while critically reviewing all aspects of the model and its implementation. Specifically, Glenn will be working with the IAB, the RFC Series Advisory Group (RSAG, see RFC5620) as appropriate, the IAOC, and the community to refine the definition of the role and relationships of the RSE. This involves providing: (i) recommendations for changes to the RFC Series model structure, (ii) recommendations for changes to the role and responsibilities of the RFC Series Editor, and (iii) recommendations to effect the acquisition of an RFC Series Editor. In the cause of the next weeks Glenn will be taking over responsibilities from Bob Braden who is acting RSE currently and will remain available as a resource of knowledge and experience. The actual title will pass between March 1 and April 19. During the next few months Glenn will talk to many of us. I hope that Glenn can count on your collaboration and frankness. Glenn will introduce himself shortly. With the appointment of Glenn Kowack as TRSE and the appointment of Nevil Brownlee as Inependent Submissions Editor the four pieces of the RFC Editor model are now in place. The IAB would like to thank the candidates that stepped forward between June and December last year. The IAB also acknowledges the support of the volunteers that served on the the Ad-hoc Advisory Committee (ACEF) and assisted the IAB in their selection. They are: Joel Halpern (who took the responsibility for coordinating), Bob Hinden, Joe Touch, and Jim Schaad, Craig Partridge (who left the committee in October 2009) and Scott Bradner (who recused in December 2009). They worked with IAB members John Klensin, Russ Housley, and me. The ACEF has served its purpose for this appointment cycle and has been dismantled. For the IAB, Olaf Kolkman IAB Chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-nsis-nslp-natfw (NAT/Firewall NSIS Signaling Layer Protocol (NSLP)) to Experimental RFC
The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'NAT/Firewall NSIS Signaling Layer Protocol (NSLP) ' draft-ietf-nsis-nslp-natfw-23.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 2010-03-12. 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-nsis-nslp-natfw-23.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=10988rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5456 on IAX: Inter-Asterisk eXchange Version 2
A new Request for Comments is now available in online RFC libraries. RFC 5456 Title: IAX: Inter-Asterisk eXchange Version 2 Author: M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard Status: Informational Date: February 2010 Mailbox:marks...@digium.com, bri...@saintjoe.edu, ed...@emcsw.com, m...@frankwmiller.net, kshum...@gmail.com Pages: 101 Characters: 226083 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-guy-iax-05.txt URL:http://www.rfc-editor.org/rfc/rfc5456.txt This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an all in one protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is an Independent Submission. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5457 on IANA Considerations for IAX: Inter-Asterisk eXchange Version 2
A new Request for Comments is now available in online RFC libraries. RFC 5457 Title: IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 Author: E. Guy, Ed. Status: Informational Date: February 2010 Mailbox:ed...@emcsw.com Pages: 21 Characters: 50952 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-guy-iaxiana-00.txt URL:http://www.rfc-editor.org/rfc/rfc5457.txt This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is an Independent Submission. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5579 on Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
A new Request for Comments is now available in online RFC libraries. RFC 5579 Title: Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces Author: F. Templin, Ed. Status: Informational Date: February 2010 Mailbox:fltemp...@acm.org Pages: 9 Characters: 18998 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-templin-isatapv4-02.txt URL:http://www.rfc-editor.org/rfc/rfc5579.txt The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is an Independent Submission. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5760 on RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
A new Request for Comments is now available in online RFC libraries. RFC 5760 Title: RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback Author: J. Ott, J. Chesterfield, E. Schooler Status: Standards Track Date: February 2010 Mailbox:j...@acm.org, julianchesterfi...@cantab.net, eve_schoo...@acm.org Pages: 66 Characters: 160368 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-rtcpssm-19.txt URL:http://www.rfc-editor.org/rfc/rfc5760.txt This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5721 on POP3 Support for UTF-8
A new Request for Comments is now available in online RFC libraries. RFC 5721 Title: POP3 Support for UTF-8 Author: R. Gellens, C. Newman Status: Experimental Date: February 2010 Mailbox:rg+i...@qualcomm.com, chris.new...@sun.com Pages: 13 Characters: 26250 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-eai-pop-09.txt URL:http://www.rfc-editor.org/rfc/rfc5721.txt This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community. This document is a product of the Email Address Internationalization Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5725 on Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
A new Request for Comments is now available in online RFC libraries. RFC 5725 Title: Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Author: A. Begen, D. Hsu, M. Lague Status: Standards Track Date: February 2010 Mailbox:abe...@cisco.com, do...@cisco.com, mla...@cisco.com Pages: 9 Characters: 18794 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-post-repair-rtcp-xr-07.txt URL:http://www.rfc-editor.org/rfc/rfc5725.txt This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5779 on Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server
A new Request for Comments is now available in online RFC libraries. RFC 5779 Title: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Author: J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer Status: Standards Track Date: February 2010 Mailbox:jouni.nos...@gmail.com, julien.bourne...@orange-ftgroup.com, kchowdh...@cisco.com, ahmad.muha...@ericsson.com, me...@umic.rwth-aachen.de Pages: 20 Characters: 44709 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dime-pmip6-04.txt URL:http://www.rfc-editor.org/rfc/rfc5779.txt This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5790 on Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
A new Request for Comments is now available in online RFC libraries. RFC 5790 Title: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols Author: H. Liu, W. Cao, H. Asaeda Status: Standards Track Date: February 2010 Mailbox:liuhui47...@huawei.com, caowa...@huawei.com, asa...@wide.ad.jp Pages: 17 Characters: 39394 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mboned-lightweight-igmpv3-mldv2-06.txt URL:http://www.rfc-editor.org/rfc/rfc5790.txt This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS TRACK] This document is a product of the MBONE Deployment Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
