Pro SPAM WG: How security could benefit from high volume spam
A WG? Karin and me are interested. JFC (Jefsey) Morfin wrote: At 23:10 14/12/2005, Hadmut Danisch wrote: On Wed, Dec 14, 2005 at 04:46:42PM +0100, Frank Ellermann wrote: The best way to hide a signal is noise, is that's your idea ? Makes sense from my POV. Not necessarily the _best_ way, but one that works under many circumstances. Some questions are: How do we deal with the total surveillance? Do anti-spam measures make surveillance easier? No, I dont want to bash the one and only root again, but never did I receive any SPAM an my [EMAIL PROTECTED] address. This too could improve our position. Which root does the guy use - or has he simply freaked his /etc/hosts? Hadmut, I agree with your idea and I switched my spam filter off from all my GMX mail accounts. They are worthless anyhow, because I permanently have to read the spam folder to find lost emails. I still have to fight sorbs, because they dont even accept my own emails from my host echnaton.serveftp.com wich has a dynamic ip. Hadmut, not much success with your suggestion! Too much European centric at the moment. Your proposition is of real interest as part of a picture to study the noise as a general protection (conflicting information, spam, revamping web sites 1000 times a day, meta-spam, tags, EUCD, civilrights protection, bandwidth cost, site legal registration, multiligualism, debate orientation, etc.). The French law related debate make it very interesting, and important, however too complex for current users at this time. This fits the interests I have in the emergence of an over the ISO layers Internet through a grassroots process. How to use the Internet? But the IAB discuss list leads to nothing. The French law made me move the sources from IASON http://iason.site.voila.fr/ http://www.kokoom.com/iason/ to sourceforge. I dont want to fight the music industry with a law I dont even understand. IASON has nothing to do with music but it has to do with copyright. Why not to try to shape a WG Charter on this? I do not believe the IESG is able to follow. But when I see all the ICANN, IETF, Unicode, etc. meetings, publications, etc. etc. about internationalization, partly to oppose my long enough opposition which permitted me to reach Tunis. One could expect that Brussels could be interested at the end of the day. And if the IESG does not follow, we will have made our duty, before going elsewhere? I do not think that the balkanization they impose on us is a good thing. jfc Karin and me helped building two balkan DNS roots. Why not do something serious now :) Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.peter-dambier.de http://peter-dambier.site.voila.fr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
The IESG wrote: draft-ietf-lemonade-profile-06.txt as a Proposed Standard In 3.3 it says [RFC2927], shouldn't that be RFC 1870, or maybe http://tools.ietf.org/id/draft-shveidel-mediasize-05 ? That's apparently not yet mentioned in the references. Nits: Some [2476] are placeholders for 2476bis, how about using [SUBMIT] ? There's an oddity with page 10 in the ToC. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
Frank Ellermann wrote: The IESG wrote: draft-ietf-lemonade-profile-06.txt as a Proposed Standard In 3.3 it says [RFC2927], shouldn't that be RFC 1870, Oops. Yes, you are right. I will fix that. or maybe http://tools.ietf.org/id/draft-shveidel-mediasize-05 ? The draft was withdrawn, as far as I remember. That's apparently not yet mentioned in the references. Nits: Some [2476] are placeholders for 2476bis, how about using [SUBMIT] ? There's an oddity with page 10 in the ToC. Good idea. I've changed this. Regards, Alexey ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
Alexey Melnikov wrote: I've changed this. Thanks. I tried to find out what lemonade stands for, back to an obscure IETF 55 PDF on an obscure lemonade WG page, and finally came to the conclusion that it's just a name and no acronym... I hope that's correct ;-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pro SPAM WG: How security could benefit from high volume spam
Peter, the first step in creating a WG (RFC 2418/BCP 25) is to discuss it with an AD. The problem is that one can consider different approaches: 1. chaffing as a Security Area issue. But there are much more environment as it is the remote global user protection (and not only his machine). 2. transmitting in the noise. This seems to be then an Application Area issue. 3. the way an individual persons may use the Internet. This is usage architecture. Then in Operations and Management Area. 4. this may lead to a battery of practical ways to extend and organise the internet and to new protocols, hence in the Internet Area. 5. there is an obvious need to authoritatively document Govs and Law makers and to negociate with them. The IETF is not suitable for that. The IAB can document, but not negociate. The place for negociations is the IGF, but not here yet and no interface with the IETF either. As you point it out, every sector of the Internet technology is concerned and the concepts of the internet and of its economy may be totally changed. I saw your site and I understand your concerns about the French DADVSI law. But understand that DMCA is a lenient version of the treaty. EUCD is a step further (how is its German version?). DADVSI is an absurd step further. But next will be DMCA II, based on the DADVSI success. So, transmitting in the noise may become the usual way the Internet functions, with a necessary opposition from Governments and an economical big difficuly. Areas of the Internet will be cut-off. We will get a noise divide. I suggest that everyone can comment on this WG-user protection strategies project, so we may have more elements to document our question to the IESG to know which area to chose. jfc At 11:31 16/12/2005, Peter Dambier wrote: A WG? Karin and me are interested. JFC (Jefsey) Morfin wrote: At 23:10 14/12/2005, Hadmut Danisch wrote: On Wed, Dec 14, 2005 at 04:46:42PM +0100, Frank Ellermann wrote: The best way to hide a signal is noise, is that's your idea ? Makes sense from my POV. Not necessarily the _best_ way, but one that works under many circumstances. Some questions are: How do we deal with the total surveillance? Do anti-spam measures make surveillance easier? No, I dont want to bash the one and only root again, but never did I receive any SPAM an my [EMAIL PROTECTED] address. This too could improve our position. Which root does the guy use - or has he simply freaked his /etc/hosts? Hadmut, I agree with your idea and I switched my spam filter off from all my GMX mail accounts. They are worthless anyhow, because I permanently have to read the spam folder to find lost emails. I still have to fight sorbs, because they dont even accept my own emails from my host echnaton.serveftp.com wich has a dynamic ip. Hadmut, not much success with your suggestion! Too much European centric at the moment. Your proposition is of real interest as part of a picture to study the noise as a general protection (conflicting information, spam, revamping web sites 1000 times a day, meta-spam, tags, EUCD, civilrights protection, bandwidth cost, site legal registration, multiligualism, debate orientation, etc.). The French law related debate make it very interesting, and important, however too complex for current users at this time. This fits the interests I have in the emergence of an over the ISO layers Internet through a grassroots process. How to use the Internet? But the IAB discuss list leads to nothing. The French law made me move the sources from IASON http://iason.site.voila.fr/ http://www.kokoom.com/iason/ to sourceforge. I dont want to fight the music industry with a law I dont even understand. IASON has nothing to do with music but it has to do with copyright. Why not to try to shape a WG Charter on this? I do not believe the IESG is able to follow. But when I see all the ICANN, IETF, Unicode, etc. meetings, publications, etc. etc. about internationalization, partly to oppose my long enough opposition which permitted me to reach Tunis. One could expect that Brussels could be interested at the end of the day. And if the IESG does not follow, we will have made our duty, before going elsewhere? I do not think that the balkanization they impose on us is a good thing. jfc Karin and me helped building two balkan DNS roots. Why not do something serious now :) Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.peter-dambier.de http://peter-dambier.site.voila.fr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
On 12/16/05, Frank Ellermann [EMAIL PROTECTED] wrote: Thanks. I tried to find out what lemonade stands for, back to an obscure IETF 55 PDF on an obscure lemonade WG page, and finally came to the conclusion that it's just a name and no acronym... I hope that's correct ;-) Sorry, that's my fault. It originally stood for License to Enhance Messaging Oriented Network Access for Diverse Endpoints, and I couldn't figure out what that meant the WG would do. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
For some reason the multicast term GLOP comes to mind... Marshall On Dec 16, 2005, at 11:23 AM, Bill Fenner wrote: On 12/16/05, Frank Ellermann [EMAIL PROTECTED] wrote: Thanks. I tried to find out what lemonade stands for, back to an obscure IETF 55 PDF on an obscure lemonade WG page, and finally came to the conclusion that it's just a name and no acronym... I hope that's correct ;-) Sorry, that's my fault. It originally stood for License to Enhance Messaging Oriented Network Access for Diverse Endpoints, and I couldn't figure out what that meant the WG would do. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA NeuStar SOW Update
Hi Ray, A couple of comments, may be was already the way it was written in my previous review of the document, but didn't noticed it at that time. I noticed that we fix the provision of the catering breaks (including cookies). I'm not sure if I'm reading it in the correct way, but my view is that even if this is part of the work, but only if required. I mean, may be instead of cookies, something else is needed, or we decide that we want to change the way we do the catering at the breaks today, etc. A small rewording will make it, I guess. Is NSS responsible for the badges and printed agendas ? (I read the current text as is required, but not sure about who provides it or who pays for the cost). Regarding the VoIP, I think is a must, not to be investigated. I will agree that it can take a couple of months to setup, but not more. If required, I can help on making it possible. We setup it just a couple of months ago in our office and the cost to get it working is really low. I radically disagree with the investigation of implementing IPv6 for other infrastructure and clerical services. Today this is no longer experimental, there is no longer big associated costs, and myself has volunteered several times (also other people I believe), to make it happen. We could accept may be 2-3 months delay *maximum* for that (at least for name service, web site, ftp, routing, monitoring/security, mirrors cooperation, mail and other archives, XMPP and any other http/s-based services), but no way to sign the contract without this clear. Otherwise IETF should stop working in IPv6 and tell the world, sorry we have failed (which in my opinion is not the case, but not getting our own services in IPv6 tend to seem like that !). Regards, Jordi De: Ray Pelletier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 14 Dec 2005 19:12:58 -0500 Para: ietf@ietf.org ietf@ietf.org Asunto: IASA NeuStar SOW Update Thank you for your input to the Statement of Work under negotiation between IASA and NeuStar. It resulted in several modifications and clarification with other bits covered by language in other parts of the Services Agreement. If you are interested, the revised SOW can be found at: http://koi.uoregon.edu/~iaoc/docs/IASA-NSS-ExA-SOW-12-14-05.pdf Regards, Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
Bill Fenner wrote: License to Enhance Messaging Oriented Network Access for Diverse Endpoints g I had the ..M...DE, but was lost with the LE.ONA.. The MSA implementors trying to figure out how arbitrary sequences of BURL and BDAT result in something that might pass as a binary MIME message/rfc822 won't mind. But they'll need some strong coffee, not only lemonade. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Pro SPAM WG: How security could benefit from high volume spam
You'll need to work very hard to get the WG action items completed by April 1, 2006. -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Peter Dambier -- Sent: Friday, December 16, 2005 5:32 AM -- To: JFC (Jefsey) Morfin -- Cc: ietf@ietf.org; Hadmut Danisch -- Subject: Pro SPAM WG: How security could benefit from high -- volume spam -- -- A WG? -- -- Karin and me are interested. -- -- JFC (Jefsey) Morfin wrote: -- At 23:10 14/12/2005, Hadmut Danisch wrote: -- -- On Wed, Dec 14, 2005 at 04:46:42PM +0100, Frank Ellermann wrote: -- -- The best way to hide a signal is noise, is that's your idea ? -- Makes sense from my POV. -- -- -- Not necessarily the _best_ way, but one that works under many -- circumstances. -- Some questions are: -- How do we deal with the total surveillance? -- Do anti-spam measures make surveillance easier? -- -- No, I dont want to bash the one and only root again, but never did I -- receive any SPAM an my [EMAIL PROTECTED] address. -- -- This too could improve our position. Which root does the -- guy use - or -- has he simply freaked his /etc/hosts? -- -- Hadmut, I agree with your idea and I switched my spam -- filter off from all -- my GMX mail accounts. They are worthless anyhow, because I -- permanently -- have to read the spam folder to find lost emails. I still -- have to fight -- sorbs, because they dont even accept my own emails from my host -- echnaton.serveftp.com wich has a dynamic ip. -- -- -- -- Hadmut, -- not much success with your suggestion! Too much European -- centric at the -- moment. Your proposition is of real interest as part of a -- picture to -- study the noise as a general protection (conflicting -- information, spam, -- revamping web sites 1000 times a day, meta-spam, tags, -- EUCD, civilrights -- protection, bandwidth cost, site legal registration, -- multiligualism, -- debate orientation, etc.). The French law related debate -- make it very -- interesting, and important, however too complex for -- current users at -- this time. This fits the interests I have in the -- emergence of an over -- the ISO layers Internet through a grassroots process. -- How to use the -- Internet? But the IAB discuss list leads to nothing. -- -- The French law made me move the sources from IASON -- -- http://iason.site.voila.fr/ -- http://www.kokoom.com/iason/ -- -- to sourceforge. I dont want to fight the music industry -- with a law I dont -- even understand. IASON has nothing to do with music but it -- has to do with -- copyright. -- -- -- Why not to try to shape a WG Charter on this? I do not -- believe the IESG -- is able to follow. But when I see all the ICANN, IETF, -- Unicode, etc. -- meetings, publications, etc. etc. about -- internationalization, partly -- to oppose my long enough opposition which permitted me to -- reach Tunis. -- One could expect that Brussels could be interested at the -- end of the -- day. And if the IESG does not follow, we will have made -- our duty, before -- going elsewhere? I do not think that the balkanization -- they impose on us -- is a good thing. -- -- jfc -- -- -- Karin and me helped building two balkan DNS roots. Why not -- do something -- serious now :) -- -- Cheers -- Peter and Karin -- -- -- -- -- Peter and Karin Dambier -- The Public-Root Consortium -- Graeffstrasse 14 -- D-64646 Heppenheim -- +49(6252)671-788 (Telekom) -- +49(179)108-3978 (O2 Genion) -- mail: [EMAIL PROTECTED] -- mail: [EMAIL PROTECTED] -- http://iason.site.voila.fr -- http://www.peter-dambier.de -- http://peter-dambier.site.voila.fr -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Enough RE: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Hallam-Baker, Do we have to go through this yet again? The Hallam-Baker, entire premise of spam filtering is that the Hallam-Baker, recipient is not prepared to deliver mail to a Hallam-Baker, user's mail box unless the sender convinces the Hallam-Baker, recipient of their bona fides. Hallam-Baker, In this context whining on about the wishes of the Hallam-Baker, sender is pointless. The entire point is that the Hallam-Baker, sender has no rights in this matter. The spammy Hallam-Baker, sender does not have the right to choose the spam Hallam-Baker, elimination tools used by the recipient. Phil, I explained this to someone in private mail recently, but perhaps if it is coming up again here, I need to say it in public. This is not about rights. This is about what makes the Internet work. If we standardize a technology, we are saying that technology solves some problem. and that its usage has well understood and accepted consequences. So it is entirely appropriate to consider the effects on senderds of spam filtering technology. Does the technology have an unacceptably high false positive rate? Does the technology adversly effect business models or classes of users in ways we find unacceptable? Does the technology impose and unreasonable load on senders? The receiver can do whatever they like. The sender has no rights. However, people expect us to publish standards that make sense and produce a working Internet when used. So we're going to consider these issues when we evaluate standards. They like everything else we do will be a matter of rough consensus. If you want to ignore the implications of your work on the broader Internet and on both senders and recipients, then perhaps the IETF is the wrong place for you to do your work. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4243 on Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
A new Request for Comments is now available in online RFC libraries. RFC 4243 Title: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option Author(s): M. Stapp, R. Johnson, T. Palaniappan Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 7 Characters: 14342 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-dhc-vendor-suboption-00.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4243.txt This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4243.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4262 on X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
A new Request for Comments is now available in online RFC libraries. RFC 4262 Title: X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities Author(s): S. Santesson Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 5 Characters: 9801 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-smime-certcapa-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4262.txt This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4262.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Correction: RFC 4119 on A Presence-based GEOPRIV Location Object Format
A new Request for Comments is now available in online RFC libraries. RFC 4119 Title: A Presence-based GEOPRIV Location Object Format Author(s): J. Peterson Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 24 Characters: 53522 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-geopriv-pidf-lo-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. This document is a product of the Geographic Location/Privacy Working Group of the IETF. This is now a Proposed Standard Protocol. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4119.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
