Re: Last Call: draft-arkko-iesg-crossarea-02.txt (Experiences from Cross-Area Work at the IETF) to Informational RFC
Hi Jari, The IESG has received a request from an individual submitter to consider the following document: - 'Experiences from Cross-Area Work at the IETF' draft-arkko-iesg-crossarea-02.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-06. Exceptionally, comments may be Hi Jari, Thanks for your draft. A couple of points. 1. Cross-area work does present some challenges, however. Apart from the advisor model there are no established practices and the processes and division of responsibility differs from case to case [RFC2026 http://tools.ietf.org/html/rfc2026]. Regarding there are no established practices, I would stress the directorate process. Not really processes in the sense of RFC 2026, but pretty useful for cross area work. For example, for MIB doctors, see http://www.ietf.org/iesg/directorate/mib-doctors.html All MIB documents will be passed by a MIB doctor reviewer before they will be approved by the IESG. The MIB doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include MIB documents should ask the OPS ADs for a MIB review as soon as the document completed WGLC. For example, for the YANG doctors, see http://www.ietf.org/iesg/directorate/yang-doctors.html All YANG documents will be passed by a YANG doctor reviewer before they will be approved by the IESG. The YANG doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include YANG documents should ask the OPS ADs for a review as soon as the document completed WGLC. For example, the performance metrics directorate, see http://www.ietf.org/iesg/directorate/performance-metrics.html Note that this directorate is a relatively new directorate, so the process is still debated Etc... I can tell you that that IPFIX doctors is about to be put in place. As an OPS AD, I'm trying to make sure that the OPS-related directorates have a clear documentation containing: the directorate goal, the process, the benefits, the guidelines, etc... 2. part of the problem here is that IESG does not normally develop a master plan, but rather individual documents and charter proposals are brought to the IESG in a piecemeal fashion, one by one. This makes it hard to see bigger trends and possibilities for colliding work. I'm not sure if the master plan is the primary problem. At the time of the charter creation, discussions regarding the work division between different WGs take place. However, along the time, different WGs take different directions. And there, the master plan might fall apart. So I would say the problem is the lack of revisiting the existing charters/WG new directions on regular basis. Somehow, my comment relates to a sentence I see later in the draft: Periodic review and re-assessment is healthy and encouraged. 3. Jari, you mentioned in one of the emails: The document has been mostly aimed at ADs and WG chairs Out of the 10 recommendations, some don't give me a clear advice. I can only say: sure, that is common sense! 7. The best examples of successful cross-area work involve combining two pieces of expertise, with both parties having an incentive to complete the work. 4. Potentially, out of the 10 recommendations, you could flag the ones that might require some sort of process improvements. For example: 10. In general, the ability to associate work with all the areas that it relates to will be helpful not just for scheduling, but also for participants following an area of work, review teams, and so on. Regards, Benoit
Musing on draft-resnick-on-consensus-01
Hi Pete, I was musing on draft-resnick-on-consensus-01. In the Section 1: We don't require full consensus; that would allow a single intransigent person who simply keeps saying No! to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group ... The above is about working group consensus. I suggest adding some text in the Introduction Section which mentions that it is about that. The We only require rough consensus can be misunderstood as being the bar in an IETF-wide call. Participants ask, Why are we bothering with this 'humming' thing? Wouldn't a show of hands be easier? The IAB recently had a discussion about bottom-up organizational modes. If I am not mistaken (please correct me) the IETF is the only organization that uses humming. I would say that it works in the IETF as it is part of the culture; it cannot be grafted on an organization. There are cases when a show of hands can be used. The sentence that follows the quoted text explains when to use humming. In Section 2: The key is to separate those choices that are simply unappealing from those that are truly problematic. I leave it to you to see whether you want to use the following: Any attempt to determine consensus is difficult if the issues are technical, economic and political. Impassioned discussion, with little technical content, leads to an impass. It is up to the chair to tease apart the points and find out how to reduce the amount people disagree on. Find the bounds of the conversation. Separate out the technical issues. Credits to Ralph Droms for the above. 'This also brings up an important point about reaching consensus: Consensus does not really involve compromising. Compromising implies that there remains something wrong with the outcome, but that the objector has simply given up.' I read compromise as something intermediate between two things. Consensus is used for conflict resolution. It's not possible to resolve an issue if the two sides are not ready to compromise. If you have two sides you end up with a King Solomon scenario. It is very difficult to resolve the issue then. Maybe conciliatory may be a better term to express the idea (see text quoted above). The draft uses objection and objector in discussing about consensus. That works in a formal or legalistic context. In an IETF context you end up being the person standing out as you raised an objection. Arguments do not have to be for or against (objection). It's difficult for me to find the words to explain this. I see that you used the word concerns in Section 4. In Section 3: If the chair finds, in their technical judgement, that the issue has truly been considered, and that the vast majority of the working Is it technical judgement or the technical issue has been considered? For the former, the chair ends up taking a technical decision. For the latter, the chair only has to use judgement. that the vast majority of the working group has come to the conclusion that the tradeoff is worth making If you consider the arguments instead you don't have to get into majority and minority. Now, a conclusion of only rough consensus relies heavily on the good judgement of the consensus caller... I like that paragraph. RFC 3929 broaches consensus from a different angle. I'll highlight the following: There must be a clear statement of the decision to be reached. The decision process used to get there is based on consensus. However, it is not easy to attain consensus. Rough consensus is the lesser barrier when consensus is not possible. In other words rough consensus is not the default choice (re: rough consensus and running code). The draft explains that by using single intransigent person as an example. Section 2 discusses about lack of disagreement. Lack of disagreement can also be a sign that the working group has not carefully considered the question. It is not possible to reach consensus on the musings in the draft. I'll pick a sentence: it is a good solution to a real problem, even if the non-experts don't have the ability to fully judge the details. There is a theory that the good solution would be chosen by a group which includes a significant number of non-experts. If the questions being asked are too complex, it can end up with the wrong decision being taken. If the group is segmented (e.g. multishareholder :-)), it can lead to a biased decision. There are different types of consensus; e.g. the consensus of the girls, which is unappealable. Regards, -sm
back by popular demand - a DNS calculator
Hi, all, By popular request, I've restored the DNS calculator function as an operational service. See: http://www.isi.edu/touch/tools/dns-calc.html (this was designed for a Sigcomm OO session, but it's been used several places as an example why the DNS should NOT be anything more than a mapping service) Joe PS - if you do happen to use it as an example, please do drop me a note; I'd be very glad to track that info. and/or include a pointer to any classes that use it.
Re: back by popular demand - a DNS calculator
Op 15-02-13 00:02, Joe Touch schreef: By popular request, I've restored the DNS calculator function as an operational service. See: http://www.isi.edu/touch/tools/dns-calc.html Great! But I was hoping it would do DNSSEC by now. Like Bert's tool has been doing for ages: dig 2.3.*.2.+.rp.secret-wg.org TXT +dnssec http://bert.secret-wg.org/Tools/index.html ;-) -- Marco Davids smime.p7s Description: S/MIME-cryptografische ondertekening
Re: Musing on draft-resnick-on-consensus-01
On 2/14/13 2:02 PM, SM wrote: The IAB recently had a discussion about bottom-up organizational modes. If I am not mistaken (please correct me) the IETF is the only organization that uses humming. I would say that it works in the IETF as it is part of the culture; it cannot be grafted on an organization. There are cases when a show of hands can be used. The sentence that follows the quoted text explains when to use humming. It seems to me that this kind of misses the point. Consensus- based decision making is not simply not voting, but it's processy and a mechanism for reaching a decision collaboratively. Unfortunately it's been the case for a very long time that the IETF does not actually do that, that participants don't understand what it means to use rough consensus for reaching decisions, working group chairs often don't understand, IESG members often don't understand, etc. So if people in the process tend to see it as a particular variant on voting, and they're incorrect, it's probably a mistake to use mechanisms that tend to support the incorrect view. Hand raising looks so much like voting that it's confusing. It's not possible to resolve an issue if the two sides are not ready to compromise. This is probably *the* principal problem in consensus decision-making. The participants have to be invested in making the process work, and in having a mutually satisfactory outcome. That's very, very often not the case in the IETF, and I'm enthusiastic about Pete's draft as a result - as much about culture transfer as about process normativity and improvement. In some sense what's under discussion actually exists in the IESG, with DISCUSSes being blocking, etc. The difference, of course, is that at some level there's an expectation of altruism from IESG members but not of IETF participants. There's a huge issue here with education. And again, kudos to Pete for taking this on. It's a very steep hill. There are different types of consensus; e.g. the consensus of the girls, which is unappealable. Whut? Melinda
Re: Last Call: draft-arkko-iesg-crossarea-02.txt (Experiences from Cross-Area Work at the IETF) to Informational RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jari, although I was asked to complete an AppsDir review of this document, on reading it several times I realized that my feedback is more personal and less from the Apps Area perspective, so I am sending a more general message. On 2/6/13 4:49 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Experiences from Cross-Area Work at the IETF' draft-arkko-iesg-crossarea-02.txt as Informational RFC Section 3 begins: From an IETF participant's point of view, it is important that there is a working group where the technical topic that he or she is interested in can be discussed. I'm not convinced that IETF participants really care whether the institutional machinery of WG formation has been put in place. In my experience, a fair amount of interesting work has happened outside of any WG (e.g., Jeff Hodges and I worked on RFC 6125 on a special-purpose IETF mailing list, not in a WG). As long as there's some kind of venue, discussion can occur. A related note on the following sentence in Section 1: If the work is interesting, the necessary people come to the meetings and work on the specifications. Well, meetings (in the sense of WG sessions, or even IETF meetings) aren't truly necessary if there is some other appropriate venue available. IMHO, Section 2 could benefit from examples of cross-area work involving RAI and Apps. Current and recent WGs include PRECIS (with involvement from Apps, RAI, Security, and Ops/Mgt), ALTO (straddling Apps and Transport), OAUTH (straddling Apps and Security), CORE (in Apps but with close connections to 6lowpan in Int), PAWS (it was an open question whether it would end up in Apps or Ops/Mgt), and current efforts to define multi-stream support in MMUSIC, CLUE, and RTCWEB. The Apps and RAI AD can probably provide further insight here. In Section 3: Cross-area work is needed, of course, in any situation where a particular technical problem does not cleanly map to one organization. Is an IETF area truly an organization? Isn't the organization here the IETF? In Section 4: But it is also possible that concerns raised in one forum are not understood in another, and this can lead to an effort going forward after finding the lowest bar forum to take it up. By forum you seem to mean IETF area. OLD Similarly, requests for cross-area review are relatively infrequent or sent only to a particular subset of people in an area (such as a directorate). NEW Similarly, requests for cross-area review are relatively infrequent or sent only to a particular subset of people in an area (such as a directorate or related working group). I tend to agree with Benoit that the scope of, and audience for, the suggestions in Section 4 are not particularly clear. Unfortunately, I do not yet have actionable suggestions for improvement. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHantAAoJEOoGpJErxa2pVaQQAJ9KVAlQi0gCB5Y7EI0+D2JR O0LfIHyoFYQ532iuEvmsmngZfhg3kOYq8VmvsUQJmLs+ipIrOdH8jbJFmmZIHUXv HwX3E6H+pRpE0b4RLMMBa0qIOZmL0QmaxhkoSTre6OP5x10WT3OrmoBIY/56yiJ5 7TvTjET+MNOj0B6shO6bGzI/q5xUuRkDlP5/d4beD5VMDjXFFkcI6eHoXteVLlel DxAElJrmRWmpGs9Wqo9YABgdvVDGBUKwqR4ap1+9kIAi68nighu3BWLmBw2nRJXi eLA5jR7ZMvbVe+KD2hlE/3oG75QvcUNSBo/gh5NS1npPPl+xKng+1xgFus7XrAc0 KHBLuI39HwzHiNuybuLmFsuRlR1/Sxe8vqfK8nNYnddkGEe90a4O+Lq6TXnedDpY CJgsZnfk9MxAYFoGDKvLeVD5FN7dev0kUe+OdCrn6DlosHMUoOps3dYtMoyviEzv vx/qijxSIi5dvztWWrEvB816rjSg4KCm67rgfNtIW2YiVyZT0QoLFZdNt2+J6H2w OaxUYK0A4sE0Zk+eXcXaK2HVo3twG/CGnTYyDI7/u+dEfTNzePxxXHDavT5gQ8jl /xBDTzyD/2mbh1zeJb2ea6Dv7OYhg1NVj7F8DCaST9lJHdF6eEICBQe9X29X2gHm NYlQwrYXJ/TIvc2U1Oyd =cXfj -END PGP SIGNATURE-
Weekly posting summary for ietf@ietf.org
Total of 101 messages in the last 7 days. script run at: Fri Feb 15 00:53:02 EST 2013 Messages | Bytes| Who +--++--+ 14.85% | 15 | 13.68% | 130635 | abdussalambar...@gmail.com 8.91% |9 | 7.09% |67750 | s...@resistor.net 6.93% |7 | 7.53% |71897 | ulr...@herberg.name 1.98% |2 | 11.39% | 108741 | amanc...@google.com 4.95% |5 | 3.39% |32338 | melinda.sh...@gmail.com 3.96% |4 | 2.93% |27951 | mo...@network-heretics.com 2.97% |3 | 2.89% |27580 | jari.ar...@piuha.net 2.97% |3 | 2.46% |23500 | barryle...@computer.org 2.97% |3 | 2.01% |19205 | joe...@bogus.com 2.97% |3 | 1.75% |16737 | d...@dcrocker.net 1.98% |2 | 2.13% |20377 | i...@jiaziyi.com 1.98% |2 | 2.04% |19449 | frederick.hir...@nokia.com 1.98% |2 | 1.77% |16892 | rdroms.i...@gmail.com 1.98% |2 | 1.70% |16245 | nar...@us.ibm.com 1.98% |2 | 1.68% |16058 | brian.e.carpen...@gmail.com 0.99% |1 | 2.61% |24941 | vincent.r...@inria.fr 1.98% |2 | 1.54% |14714 | f...@cisco.com 1.98% |2 | 1.50% |14323 | eburge...@standardstrack.com 0.99% |1 | 2.46% |23465 | i...@thomasclausen.org 1.98% |2 | 1.40% |13356 | bob.hin...@gmail.com 1.98% |2 | 1.32% |12620 | wor...@ariadne.com 0.99% |1 | 1.94% |18570 | magnus.westerl...@ericsson.com 0.99% |1 | 1.59% |15178 | nabil.n.bi...@verizon.com 0.99% |1 | 1.53% |14599 | bcla...@cisco.com 0.99% |1 | 1.41% |13508 | adr...@olddog.co.uk 0.99% |1 | 1.29% |12308 | ron.even@gmail.com 0.99% |1 | 1.25% |11951 | hsan...@isdg.net 0.99% |1 | 1.25% |11918 | mdav...@forfun.net 0.99% |1 | 1.02% | 9744 | r...@rfc-editor.org 0.99% |1 | 0.98% | 9351 | aret...@cisco.com 0.99% |1 | 0.90% | 8568 | stpe...@stpeter.im 0.99% |1 | 0.88% | 8425 | s...@harvard.edu 0.99% |1 | 0.86% | 8194 | j...@joelhalpern.com 0.99% |1 | 0.85% | 8083 | dean.wil...@softarmor.com 0.99% |1 | 0.82% | 7836 | g...@gtwassociates.com 0.99% |1 | 0.73% | 6941 | d3e...@gmail.com 0.99% |1 | 0.73% | 6931 | d...@cridland.net 0.99% |1 | 0.71% | 6788 | mstjo...@comcast.net 0.99% |1 | 0.64% | 6114 | y...@checkpoint.com 0.99% |1 | 0.64% | 6112 | do...@dougbarton.us 0.99% |1 | 0.64% | 6099 | sc...@kitterman.com 0.99% |1 | 0.64% | 6079 | mcr+i...@sandelman.ca 0.99% |1 | 0.62% | 5941 | john-i...@jck.com 0.99% |1 | 0.60% | 5732 | rbar...@bbn.com 0.99% |1 | 0.60% | 5723 | ned+i...@mauve.mrochek.com 0.99% |1 | 0.56% | 5346 | ch...@ietf.org 0.99% |1 | 0.55% | 5248 | m...@sap.com 0.99% |1 | 0.52% | 4959 | to...@isi.edu +--++--+ 100.00% | 101 |100.00% | 955020 | Total
Re: back by popular demand - a DNS calculator
On 14 feb 2013, at 23:07, Marco Davids (Prive) mdav...@forfun.net wrote: Great! But I was hoping it would do DNSSEC by now. ...how can one otherwise know that 2+3 is 4^H5 Patrik
EXTENDED Last Call: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt (Client Link-layer Address Option in DHCPv6) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Client Link-layer Address Option in DHCPv6' draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-02-28. 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. Note that this is an extension of the IETF last call that was originally announced on 2013-02-04. The IETF last call has been extended because of IPR disclosure 1710, which was published in reference to draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt. Because draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt is a predecessor to draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt, IPR disclosure 1710 should be considered in this IETF last call. Abstract This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-layer Address option. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/ IPR disclosure 1710 may be relevant to this document.
RFC 6872 on The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
A new Request for Comments is now available in online RFC libraries. RFC 6872 Title: The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model Author: V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor Status: Standards Track Stream: IETF Date: February 2013 Mailbox:v...@bell-labs.com, ebur...@standardstrack.com, tri...@ece.iit.edu, hum...@gmail.com, olivier.fes...@loria.fr Pages: 39 Characters: 72134 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sipclf-problem-statement-13.txt URL:http://www.rfc-editor.org/rfc/rfc6872.txt Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents. This document is a product of the SIP Common Log Format Working Group of the IETF. This is now a Proposed Standard. 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
RFC 6873 on Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
A new Request for Comments is now available in online RFC libraries. RFC 6873 Title: Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) Author: G. Salgueiro, V. Gurbani, A. B. Roach Status: Standards Track Stream: IETF Date: February 2013 Mailbox:gsalg...@cisco.com, v...@bell-labs.com, a...@nostrum.com Pages: 28 Characters: 63449 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sipclf-format-11.txt URL:http://www.rfc-editor.org/rfc/rfc6873.txt The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. This document is a product of the SIP Common Log Format Working Group of the IETF. This is now a Proposed Standard. 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
RFC 6868 on Parameter Value Encoding in iCalendar and vCard
A new Request for Comments is now available in online RFC libraries. RFC 6868 Title: Parameter Value Encoding in iCalendar and vCard Author: C. Daboo Status: Standards Track Stream: IETF Date: February 2013 Mailbox:cy...@daboo.name Pages: 7 Characters: 11025 Updates:RFC5545, RFC6321, RFC6350, RFC6351 I-D Tag:draft-daboo-ical-vcard-parameter-encoding-04.txt URL:http://www.rfc-editor.org/rfc/rfc6868.txt This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications. This is now a Proposed Standard. 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
