Re: RFC 3484 section 6 rule 9 causing more operational problems
All, I fail to submit a revision of my draft by cutoff, and could not post it right now. So I attached a draft to this e-mail. I'm sorry that it does not reflect the discussion of this thread greatly. I hope to have comments. Kindest regards, Network Working Group A. Matsumoto Internet-Draft T. Fujisaki Intended status: Standards Track NTT Expires: September 17, 2009R. Hiromi Intec Netcore K. Kanayama INTEC Systems March 16, 2009 Things To Be Considered for RFC 3484 Revision draft-arifumi-6man-rfc3484-revise-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 17, 2009. Copyright Notice Matsumoto, et al. Expires September 17, 2009 [Page 1] Internet-Draft RFC3484 Revise March 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. Matsumoto, et al. Expires September 17, 2009 [Page 2] Internet-Draft RFC3484 Revise March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Example . . . . . . . . . . . . . . . . . . . . . 4 2. Proposed Changes to RFC 3484 . . . . . . . . . . . . . . . . . 5 2.1. To remove site-local unicast address . . . . . . . . . . . 5 2.2. To change default policy table . . . . . . . . . . . . . . 6 2.3. To change ULA address scope to site-local . . . . . . . . 6 2.4. To add descriptions for source address selection for multicast packet . . . . . . . . . . . . . . . . . . . . . 7 2.5. To make address type dependent control possible . . . . . 7 2.6. To disable or restrict RFC 3484 Section 6 Rule 9 . . . . . 7 2.7. To change private IPv4 address scope . . . . . . . . . . . 8 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . .
Re: Consensus Call for draft-housley-tls-authz
I wonder that movement of FSF and the related subjects of patent threats might be a kind of economical hypnotism. Theorem or formulas of hypnotism might be used.mightn't it? For me, many local IT companies looks like as slaves of the hypnotism, congregation of local pseudo doctors, hysteria of IT trend, I think. What's more, local pseudo IT doctors easily changes their own thoughts according to atmosphere of discussion of IETF, or any other international academic/engineering society, I think. International democratic discussion about network protocols for political processes such as democracy could promote new fundamental conceptal computing, I believe in. Let's consider new conceptual brain-like computer and the network, and new international political process automation standards as sets of communication protocols. Sincerely, Be careful of evil rumor and whispering, Abraham TaddyHatty taddyhatty at acm dot org // In an essay M in Surely, you are joking Mr.Feynman, // he said that I've learned how to be under hypnotism. Kindly regards, Abraham TaddyHatty taddyhatty at acm dot org Lawrence Rosen wrote: [..] Or are some at IETF actually trying to set implementers up for legal action by refusing to evaluate *disclosed* threats? Helping hapless implementers evaluate patent threats sounds like a job for the Internet Legal Task Force. I believe they're two doors down, on the right... cheers, gja ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Abstract on Page 1?
+1. I agree. Regards, Ed Juskevicius -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Julian Reschke Sent: March 7, 2009 3:46 AM To: Scott Lawrence Cc: John C Klensin; ietf@ietf.org Subject: Re: Abstract on Page 1? Scott Lawrence wrote: ... This is a trivial change for the generation tools to make - at worst it will make one generation of diffs slightly more difficult (and I'd be happy to trade one generation of poor diffs for this, so for me just don't worry about fixing the diff tools). ... At this point, no change to the boilerplate is trivial anymore. For xml2rfc, we need to - define how to select the new behavior (date? ipr value? rfc number?); if the behavior is not explicitly selected in the source, we need heuristics when to use the old one and when to use the new one (keep in mind that the tools need to be able to generate historic documents as well) - add new test cases - add documentation So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian ___ 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: jim bound
Jim was a brilliant mind. His legacy and influence in the IPng world and beyond...will never be forgotten. Rest in peace. On Mon, Mar 9, 2009 at 12:30 PM, Templin, Fred L fred.l.temp...@boeing.comwrote: I'll add my voice as another former DEC colleague who was saddened by this news. Jim never shied away from a challenging or contentious job. For example, the work on enterprise networks in RFCs 4852, 4057 could only have been done by someone with Jim's fortitude. I believe we are all better off for having known Jim, and I will miss him. Fred fred.l.temp...@boeing.com -Original Message- From: Paul Vixie [mailto:vi...@isc.org] Sent: Friday, March 06, 2009 11:25 PM To: ietf@ietf.org Subject: jim bound i shared the news with some coworkers from DEC (where jim and i both worked back in the early 1990's). one of them said: Wow, sorry to hear it. Jim treated networking like he was still in 'Nam and beauracracy was Charlie. He always took the hill. another added: I would only add that he never left any behind. jim will be missed, both sorely and otherwise, by me and by many others. ___ 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 -- AJ Jaghori Chief Architect, Author, Professor | Data Network Security ciscowo...@gmail.com Sent via my Android Powered Mobile... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Update for RSAES-OAEP Algorithm Parameters' to Proposed Standard
The IESG has approved the following document: - 'Update for RSAES-OAEP Algorithm Parameters ' draft-ietf-pkix-rfc4055-update-02.txt as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-02.txt Technical Summary The subjectPublicKeyInfo field of an X.509 certificate carries three data items: an algorithm identifier, optional parameters, and a bit string that represents the public key. The parameters are specific to the algorithm and this field usually contains simple values needed to characterize the public key algorithm, e.g., the generator and modulus for Diffie-Hellman. However, X.509 does not constrain the scope of this parameters field. The ANSI X9.62 standards committee elected to use this field to express potentially complex limitations on how the public key in the certificate can be used, e.g., which key derivation functions can be applied to the bit string that results from a Diffie-Hellman key exchange. After considerable debate, the PKIX WG has decided to not express key usage constraints via this field. Instead, the WG decided that this sort of information should be expressed via use of distinct algorithm identifiers. (This decision is consistent with the observation that current products are not deigned to handle such key usage restrictions expressed in the subjectPublicKeyInfo field.) RFC 4055 such allowed restrictions to be placed in this field when used with RSA-OAEP. This document changes RFC 4055 to say that restrictions MUST NOT be present in the certificate's subjectPublicKeyInfo field when used with RSA-OAEP. It also replaces incorrect references to the publicKeyAlgorithm field with references to the subjectPublicKeyInfo field. As a result, this revised version of RFC 4055 will be consistent with the PKIX WG conventions adopted for this field. Working Group Summary This ID was discussed on the mailing list. A poll was taken on the PKIX list to determine whether the proposed change was the way forward and another poll was taken to determine whether the change would adversely affect implementations. The WG was in favor of the change and no implementer said it would adversely affect their products. Further, vendors that implement RFC 4055 support the change. Document Quality This document is a short update of an existing draft and is comparable in quality to its predecessor. Personnel Steve Kent is the document Shepherd. Pasi Eronen is the responsible security area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Netnews Architecture and Protocols' to Proposed Standard
The IESG has approved the following document: - 'Netnews Architecture and Protocols ' draft-ietf-usefor-usepro-14.txt as a Proposed Standard This document is the product of the Usenet Article Standard Update Working Group. The IESG contact persons are Lisa Dusseault and Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-14.txt Technical summary: This document describes the operational procedures involved in running the NetNews service, including the roles of all the components of the service. It establishes terminology and expectations of behaviour for News servers independent of the protocol they use to communicate. This, together with draft-ietf-usefor-usefor, obsoletes RFC 1036. Working group summary: The USEFOR working group has been working on this document in various versions since 1998. This version was split from the -usefor document in 2004. Progress has been slow, and contention has erupted over both major and minor matters. The group is now down to a very small size (~5 people), and it is not believed that working at this longer will improve the document significantly. The WG has consensus that this document is a far better specification than RFC 1036. Protocol quality The specification allows major News implementations to claim conformance as-is. Some innovations done in the course of the WG's work have been incorporated into existing News servers. The editor is himself a News server implementor. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Lemonade Profile' to Proposed Standard
The IESG has approved the following document: - 'The Lemonade Profile ' draft-ietf-lemonade-profile-bis-12.txt as a Proposed Standard This document is the product of the Enhancements to Internet email to Support Diverse Service Environments Working Group. The IESG contact persons are Chris Newman and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-12.txt Technical Summary This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. Working Group Summary There is WG consensus to publish this document. Document Quality This document has been through significant review by mail client and server vendors, often based on issues with implementing the profile, that has resulted in modified base documents and as a result modifications in this profile. In addition, the LEMONADE WG has had a liaison relationship with OMA MEM that has resulted in a vetting of the features to ensure that the profile is operationally useful. The final document is a result of a significant effort to ensure that the mobile email requirements are efficiently realized by Internet Mail. Personnel Glenn Parsons is the document shepherd. Chris Newman has reviewed this document for the IESG. Note to RFC Editor 1) Add Updates: RFC 4469, RFC 4467 to the header 2) Change the second paragraph of the Abstract from: OLD: The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. NEW: The Lemonade profile relies upon several extensions to IMAP, Sieve and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. 3) In section 7, please change the 2nd paragraph: OLD: Note that the explicit usage of [SUBMIT] means that when opening a connection to the submission server, clients MUST do so using port 587 unless explicitly configured to use an alternate port [RFC5068]. If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [SUBMIT] information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction. NEW: When opening a connection to the submission server, clients MUST do so using port 587 unless explicitly configured to use an alternate port [RFC5068]. (Note that this requirement is somewhat stronger than the one specified in [SUBMIT], as [SUBMIT] didn't prescribe the exact procedure to be used by submission clients.) If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [SUBMIT] for information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction. 4) Change the first paragraph of section 8 to read: OLD: Security considerations on Lemonade forward without download are discussed throughout Section 2. Additional security considerations can be found in [RFC3501] and other documents describing other SMTP and IMAP extensions comprising the Lemonade profile. NEW: Security considerations on Lemonade forward without download are discussed throughout Section 2. Additional security considerations can be found in [RFC3501], [SUBMIT], [SIEVE] and other documents ^^^ describing other SMTP, IMAP and Sieve extensions comprising the ^ ^ Lemonade profile. 5) In Section 8.4, change the 1st sentence of the 3rd paragraph to read: OLD: There are two ways to perform forward without download based on where the message assembly takes place. NEW: This section informatively describes two ways to perform forward without download based on where the message assembly takes place. 6) Replace section 12 with: 12. Changes since RFC 4550 When compared to RFC 4550, this document adds the following additional requirements on a Lemonade compliant IMAP server: A) IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH, CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1, NOTIFY, QRESYNC, SASL-IR, SORT,
Document Action: 'Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)' to Informational RFC
The IESG has approved the following document: - 'Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) ' draft-jones-dime-3gpp-eps-command-codes-02.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command-codes-02.txt Technical Summary This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for MME and SGSN related interfaces in the Release 8 architecture. Working Group Summary This document is not a DIME working group document but has received review from DIME WG members Document Quality The document has been reviewed by Hannes Tschofenig, Victor Fajardo and Glen Zorn from the DIME working group. The main work this document is based on has been developed in the 3GPP and has received a fair amount of review. Personnel Hannes Tschofenig is the document shepherd. Dan Romascanu is the responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-farah-adntf-ling-guidelines-04.txt
The IESG has no problem with the publication of 'Linguistic Guidelines for the Use of the Arabic Language in Internet Domains' draft-farah-adntf-ling-guidelines-04.txt as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16964rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farah-adntf-ling-guidelines-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. RFC Editor Note The IESG has not found any conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5429 on Sieve Email Filtering: Reject and Extended Reject Extensions
A new Request for Comments is now available in online RFC libraries. RFC 5429 Title: Sieve Email Filtering: Reject and Extended Reject Extensions Author: A. Stone, Ed. Status: Standards Track Date: March 2009 Mailbox:aa...@serendipity.palo-alto.ca.us Pages: 14 Characters: 28822 Obsoletes: RFC3028 Updates:RFC5228 I-D Tag:draft-ietf-sieve-refuse-reject-09.txt URL:http://www.rfc-editor.org/rfc/rfc5429.txt This memo updates the definition of the Sieve mail filtering language reject extension, originally defined in RFC 3028. A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve reject action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the reject action to allow messages to be refused during the SMTP transaction, and defines the ereject action to require messages to be refused during the SMTP transaction, if possible. The ereject action is intended to replace the reject action wherever possible. The ereject action is similar to reject, but will always favor protocol-level message rejection. [STANDARDS TRACK] This document is a product of the Sieve Mail Filtering Language 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5482 on TCP User Timeout Option
A new Request for Comments is now available in online RFC libraries. RFC 5482 Title: TCP User Timeout Option Author: L. Eggert, F. Gont Status: Standards Track Date: March 2009 Mailbox:lars.egg...@nokia.com, ferna...@gont.com.ar Pages: 14 Characters: 33568 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-tcp-uto-11.txt URL:http://www.rfc-editor.org/rfc/rfc5482.txt The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5501 on Requirements for Multicast Support in Virtual Private LAN Services
A new Request for Comments is now available in online RFC libraries. RFC 5501 Title: Requirements for Multicast Support in Virtual Private LAN Services Author: Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang Status: Informational Date: March 2009 Mailbox:y.kam...@ntt.com, wada.yuich...@lab.ntt.co.jp, yetik_serb...@labs.att.com, thomas.mo...@francetelecom.com, luf...@cisco.com Pages: 31 Characters: 71507 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-l2vpn-vpls-mcast-reqts-07.txt URL:http://www.rfc-editor.org/rfc/rfc5501.txt This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
