RE: The Last Call social contract (was - Re: Rude responses)
On 23 Aug 2013 04:22, l.w...@surrey.ac.uk wrote: LC should not be treated as a right of passage, to test the patience of folks who have developed a document. rite? Right - right or rite? Lloyd Wood http://sat-net.com/L.Wood/
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 08/22/2013 07:18 PM, John Levine wrote: In article 5215cd8d.3080...@sidn.nl you write: So what makes you think the above 4 points will not be a problem for the next protocol that comes along and needs (apex) RR data? And the one after that? SPF is ten years old now. It would be helpful if you could give us a list of other protocols that have had a similar issue with a TXT record at the apex during the past decade. I don't know of any (at least ones that are used in the global dns namespace), and I would like to still not know of any in 2033. SPF may be a lost cause, let's try and make that the only one. Jelte
Visibility of shepherd writeup
On Aug 22, 2013, at 21:23, Barry Leiba barryle...@computer.org wrote: Most Excellent(tm) shepherd report: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/shepherdwriteup/ (This may not have helped much in this case, but:) Why is it that IETF last-calls do not contain a direct reference the shepherd writeup? Shouldn't those be required first reading for anyone commenting? Grüße, Carsten PS.: The last-call does contain a direct reference to http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ballot/ which is 404 at this point in the procedure.
Huawei to Host IETF 88 in Vancouver!
Announce Huawei Host Vancouver The IAOC is pleased to announce that Huawei will be the Host for IETF 88 in Vancouver. Huawei has been a long time supporter of the IETF through its participation and sponsorships at IETF meetings, but this is their first time as the Host of an IETF meeting. Congratulations, welcome and Thank You! Registration is now open for IETF 88 at: http://www.ietf.org/meetings/88/ Many sponsorship opportunities are still available: http://iaoc.ietf.org/documents/IETF-Sponsorship-Opportunities-20132002.pdf If interested contact Andrew Dvorshak, dvors...@isoc.org. Once again, thank you Huawei!. See you in Vancouver in 71 days. Ray IAD 2014 Meeting Venues IETF 89 London Hilton MetropoleMarch 2-7 IETF 90 Toronto Fairmont Royal York July 20 - 25 IETF 91 HonoluluHilton Hawaiian Village November 9 - 14
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
SPF is ten years old now. It would be helpful if you could give us a list of other protocols that have had a similar issue with a TXT record at the apex during the past decade. I don't know of any (at least ones that are used in the global dns namespace), and I would like to still not know of any in 2033. SPF may be a lost cause, let's try and make that the only one. Since we agree that the issue you're worried about has not arisen even once in the past decade, could you clarify what problem needs to be solved here? R's, John
RE: [Recentattendees] IETF 88 - Registration Now Open!
The URL below is missing letter g in the word meeting. http://www.ietf.org/meetin/88/hotel.html -Original Message- From: recentattendees-boun...@ietf.org [mailto:recentattendees-boun...@ietf.org] On Behalf Of IETF Secretariat Sent: Friday, August 23, 2013 10:26 AM To: recentattend...@ietf.org Subject: [Recentattendees] IETF 88 - Registration Now Open! 88th IETF Meeting Vancouver, BC, Canada November 3-8, 2013 Host: Huawei Meeting venue: Hyatt Regency Vancouver: http://vancouver.hyatt.com/en/hotel/home.html Register online at: http://www.ietf.org/meetings/88/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 28 October 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local Vancouver time. G. On-site Registration starting Sunday, 3 November 2013 at 1100 local Vancouver time. 2. Visas Letters of Invitation: Information on Visiting Canada, please visit: http://www.cic.gc.ca/english/visit/index.asp After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Canada. 3. Accommodations The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, the meeting venue, as well as at the overflow hotel Fairmont Hotel Vancouver, which is located across the street from the Hyatt. Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel room tax, GST and Destination Management Fee) are excluded from the guestroom rate and are subject to change. Room rates DO NOT include daily breakfast. Reservations Cut off Date: Hyatt Regency Vancouver - 20 October 2013 Fairmont Hotel Vancouver - 11 October 2013 For additional information on rates and policies, please visit: http://www.ietf.org/meetin/88/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 3 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 3 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 88 companions mailing list only see: https://www.ietf.org/mailman/listinfo/88companions Only 71 days until the Vancouver IETF! ___ Recentattendees mailing list recentattend...@ietf.org https://www.ietf.org/mailman/listinfo/recentattendees
Re: Last Call: draft-ietf-netext-update-notifications-07.txt (Update Notifications for Proxy Mobile IPv6) to Proposed Standard
Hi, I've taken a look at the current version of the draft and I think it is in good shape. I have a couple of comments: - I think it might be useful to include an additional NR Code for obtaining Updated Access Network Identifier (ANI) parameters. The LMA would send a UPN message to the MAG with NR=Updated-ANI-Parameters and then the MAG would send the PBU with the updated ANI parameters. - In the last NETEXT session we discussed about using the update notifications for the flow mobility solution draft (draft-ietf-netext-pmipv6-flowmob). I think it might be good to add a Notification Reason related to flow mobility updates, or at least a reference to the flowmob document (we can also define the Notification Reason in draft-ietf-netext-pmipv6-flowmob). Thanks, Carlos On Thu, 2013-08-15 at 11:32 -0700, The IESG wrote: The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Update Notifications for Proxy Mobile IPv6' draft-ietf-netext-update-notifications-07.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 ietf@ietf.org mailing lists by 2013-08-29. 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. Abstract This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ballot/ No IPR declarations have been submitted directly on this I-D.
Gen-ART review of draft-ietf-trill-directory-framework-07
The -07 version is also ready for publication as an Informational RFC
Thanks,
--David
-Original Message-
From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of
Black, David
Sent: Monday, July 29, 2013 7:20 AM
To: ldun...@huawei.com; Donald Eastlake; ra...@alum.mit.edu; igor@yahoo-
inc.com; General Area Review Team
Cc: Ted Lemon; ietf@ietf.org; tr...@ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-
06
The -06 version of this draft resolves all of the concerns raised by the Gen-
ART
review of the -05 version - the -06 version is ready for publication as an
Informational RFC.
Thanks,
--David
-Original Message-
From: Black, David
Sent: Wednesday, July 17, 2013 7:54 PM
To: ldun...@huawei.com; Donald Eastlake; ra...@alum.mit.edu; igor@yahoo-
inc.com; General Area Review Team
Cc: tr...@ietf.org; ietf@ietf.org; Black, David; Ted Lemon
Subject: Gen-ART review of draft-ietf-trill-directory-framework-05
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the
review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com Mobile: +1 (978) 394-7754
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-overload-reqs-10 Reviewer: David L. Black Review Date: August 17, 2013 IETF LC End Date: August 16, 2013 IESG Telechat date: (if known) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes scenarios in which Diameter overload can occur and provides requirements for development of new overload control functionality in Diameter. It is well written, and the inclusion of scenarios in which overload can occur, both in terms of the relationships among types of Diameter nodes and actual mobile network experience is very helpful. I apologize for this review being a day late, as I've been on vacation for most of this draft's IETF Last Call period. Major issues: (none) Minor issues: (none) Nits/editorial comments: The following two comments could be minor issues, but I'm going to treat them as editorial, as I expect that they will be addressed in development of the actual overload functionality: a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. b) The draft, and especially its requirements in Section 7 are strongly focused on individual Diameter node overload. That's necessary, but overload conditions can be broader, affecting an entire service or application, or multiple instances of either/both, even if not every individual Diameter node involved is overloaded. A number of the requirements, starting with REQ 22 could be generalized to cover broader overload conditions. This (b) has implications for other requirements, e.g., REQ 13 should also be generalized beyond a single node to avoid increased traffic in an overload situation, even from a node that is not overloaded by itself. There are limits on what is reasonable here, as the desired overload functionality is TCP/SCTP- like reaction to congestion where individual actions taken by nodes based on the information they have (which is not the complete state of the network) results in an overall reduction of load. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? Section 1.2, 2nd paragraph: as network congestion, network congestion can reduce a Diameter nodes nodes - node's good catch. Section 5, 1st paragraph: This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. Section 7 The long enumerated list of requirements is not an easy read. It would be better if these could somehow be grouped by functional category, e.g., security, transport interactions, operational/administrative, etc. agree. It is actually in sections in the XML (denoted by comments), we just did not promote those to visible sections in the txt. I recall there being some issue with xml2rfc and numbering, but now that the numbers are set, this would not be hard to do. idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - this is fine, as the boilerplate has been appropriately modified for this draft that expresses requirements (as opposed to a draft that specifies a protocol). idnits 2.12.17 got confused by the 3GPP and GSMA Informative References. I assume that they're all sufficiently stable to be informative references. However, [TR23.843] is a work in progress, and should be noted as such in its reference - is this needed for any of the other
Re: [netext] Last Call: draft-ietf-netext-update-notifications-07.txt (Update Notifications for Proxy Mobile IPv6) to Proposed Standard
Hi Carlos, Thanks for your review comments. Please see inline. On 8/22/13 6:28 PM, Carlos Jesús Bernardos Cano c...@it.uc3m.es wrote: Hi, I've taken a look at the current version of the draft and I think it is in good shape. I have a couple of comments: - I think it might be useful to include an additional NR Code for obtaining Updated Access Network Identifier (ANI) parameters. The LMA would send a UPN message to the MAG with NR=Updated-ANI-Parameters and then the MAG would send the PBU with the updated ANI parameters. Yes. We discussed this, but we seem to have missed this comment. Will include this NR code. - In the last NETEXT session we discussed about using the update notifications for the flow mobility solution draft (draft-ietf-netext-pmipv6-flowmob). I think it might be good to add a Notification Reason related to flow mobility updates, or at least a reference to the flowmob document (we can also define the Notification Reason in draft-ietf-netext-pmipv6-flowmob). Sure. Will add a reference to the spec. Regards Sri Thanks, Carlos On Thu, 2013-08-15 at 11:32 -0700, The IESG wrote: The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Update Notifications for Proxy Mobile IPv6' draft-ietf-netext-update-notifications-07.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 ietf@ietf.org mailing lists by 2013-08-29. 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. Abstract This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ba llot/ No IPR declarations have been submitted directly on this I-D. ___ netext mailing list net...@ietf.org https://www.ietf.org/mailman/listinfo/netext
Re: [dnsext] full standards, Deprecating SPF
Andras Salamon wrote: On Thu, Aug 22, 2013 at 11:53:29PM -, John Levine wrote: If you think it's important to move it to full standard, why don't you do somthing about it? A quick look suggests that 3597 meets the requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard to persuade someone on the IESG to sponsor the required last call. Ólafur Gudmundsson nominated RFC 3597 to advance from Proposed to Draft Standard in message 6.1.0.6.2.20040819092046.02d2dec0@localhost of 19 Aug 2004. This was based on -00 of Jakob Schlyter's draft, of which the most recent version is from May 2005: http://tools.ietf.org/id/draft-ietf-dnsext-interop3597-02.txt Since Jakob already did an important part of the work, I would first like to understand what happened to the advancement request, especially in light of the two revisions of the interoperability report after the request. Does anyone have pointers? (I know that PS/DS were merged a couple of years ago, but would still like to understand how the PS-DS process went, and if it failed, why.) I appreciate this level of work to see why it fell through the cracks. I believe it is one of the IETF growing lack of diversity issues, i.e., improving electronic communications, collaborations and networking among industry peers. This should be a project leader(s) responsibility to make sure the basic technology requirements are realistic or not, i.e., consult and get input from the DNS industry vendors, make them aware and/or to find out why this has not happen yet. For example, why hasn't Microsoft supported RFC 3597 yet? You will be surprise that a well respected Microsoft DNS Expert and MVP (Most Valuable Player) was unaware of such needs, nor was his microsoft contacts and the MSDNS beta team based on a discussion with him: http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records This was back in March/April 2012. If Microsoft isn't going to bother to add direct support for the SPF type99 RR, nor support RFC 3597 at the very least, I believe this matter is decided and closed. TXT only is proper for SPFBIF and for future DNS applications as well. I am sure there are key IETF decision makers with Microsoft DNS product manager contacts who can find out whats going on to help resolve this LC issue. -- HLS
Fwd: [dnsext] SPF isn't going to change, was Deprecating SPF
Begin forwarded message: Resent-From: bmann...@vacation.karoshi.com From: bmann...@vacation.karoshi.com Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF Date: August 23, 2013 10:03:26 PDT Resent-To: bmann...@isi.edu To: John Levine jo...@taugh.com Cc: dns...@ietf.org On Fri, Aug 23, 2013 at 03:14:38PM -, John Levine wrote: I counted my queries from a few days ago and got 7086 TXT, 263 SPF, or 3.7%. Nobody has argued that SPF usage is zero, and the reasons for deprecating SPF have been described repeatedly here and on the ietf list, so this exercise seems fairly pointless. the reasons for not deprecating SPF have been described here and on the ietf list repeatedly ... yet there has been little concrete data regarding deployment uptake. These published snapshots form a baseline - 201308, and it might be worthwhile to look again in six months to see if the magnitude and ratio have changed. The results of a second look should bring into focus the prevaling trends and solidify the argument. Surely there is no compelling urgency to conclude the current LC - given the duration of this work a six month period to gain emperical insight would not be a bad thing. Would it? /bill R's, John ___ dnsext mailing list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext ___ dnsext mailing list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
Re: IETF 88 - Registration Now Open!
and the hotel is fully booked…. /bill On 23August2013Friday, at 6:36, IETF Secretariat wrote: 88th IETF Meeting Vancouver, BC, Canada November 3-8, 2013 Host: Huawei Meeting venue: Hyatt Regency Vancouver: http://vancouver.hyatt.com/en/hotel/home.html Register online at: http://www.ietf.org/meetings/88/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 28 October 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local Vancouver time. G. On-site Registration starting Sunday, 3 November 2013 at 1100 local Vancouver time. 2. Visas Letters of Invitation: Information on Visiting Canada, please visit: http://www.cic.gc.ca/english/visit/index.asp After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Canada. 3. Accommodations The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, the meeting venue, as well as at the overflow hotel Fairmont Hotel Vancouver, which is located across the street from the Hyatt. Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel room tax, GST and Destination Management Fee) are excluded from the guestroom rate and are subject to change. Room rates DO NOT include daily breakfast. Reservations Cut off Date: Hyatt Regency Vancouver - 20 October 2013 Fairmont Hotel Vancouver - 11 October 2013 For additional information on rates and policies, please visit: http://www.ietf.org/meetin/88/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 3 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 3 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 88 companions mailing list only see: https://www.ietf.org/mailman/listinfo/88companions Only 71 days until the Vancouver IETF!
Re: Fwd: [dnsext] SPF isn't going to change, was Deprecating SPF
Nobody has argued that SPF usage is zero, and the reasons for deprecating SPF have been described repeatedly here and on the ietf list, so this exercise seems fairly pointless. the reasons for not deprecating SPF have been described here and on the ietf list repeatedly ... yet there has been little concrete data regarding deployment uptake. Sigh. We have RFC 6686. Since this is clearly an issue you consider to be of vital importance, it is baffling that (as far as I can tell) you did not contribute to or even comment on it when it was being written and published. Those of us in the mail community have a lot of anecdotal evidence, too. Most notably, none of the large providers that dominate the mail world publish or check type 99, and the one that used to check type 99 (Yahoo) doesn't any more. You don't have to like it, but it's silly to deny it. In any event, it's purely a strawman that nobody checks type 99. A few people do, the WG knows that, and we decided for well documented reasons to deprecate it anyway. R's, John
Re: The Last Call social contract (was - Re: Rude responses)
On Thu, Aug 22, 2013 at 11:12 PM, Dave Crocker d...@dcrocker.net wrote: In pragmatic terms, the current operational model for a LC (and IESG) review tends to enforce no rules or limits to what can be challenged or suggested, while simultaneously expecting those who have been doing the work to then be responsible for educating the commenter and defending decisions in the document, at the level of re-arguing resolved issues. Your admonition that these folks are already at a disadvantage encourages this sense of obligation. However this is direct contradiction to our published rules for Last Call: RFC 2418, Working Group Guidelines and Procedures Section 8, Review of documents It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review. Note that last sentence. It's the essential point, if we are to have any real /respect/ for the extended effort already put into developing the document. Remember the discussion about how last call is more like the middle of a document's evolution, and we should admit that in our process documentation? This is closely related. If, in reality, people are frustrated at the attempted rapid pace of last calls, then we should allow for that. We have time. We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Simple comments and questions -- your educating everyone who tracked the wrong group -- can be dealt with easily through referral. Even substantial ones can be directed to specific discussion threads. Real issues can be considered. It's only too late if we say it is, in our processes, and if an issue is substantial, it should never be too late.
Re: IETF 88 - Registration Now Open!
In article b4828b8f-b900-4dc1-ad3e-7e3044fb8...@isi.edu you write: and the hotel is fully booked�. Not if you use the link on the meeting hotel page. http://www.ietf.org/meeting/88/hotel.html R's, John
Re: IETF 88 - Registration Now Open!
On 23 Aug 2013, at 18:49, manning bill bmann...@isi.edu wrote: and the hotel is fully booked…. I guess it got fixed Bill, though I only booked for the meeting week itself. tim /bill On 23August2013Friday, at 6:36, IETF Secretariat wrote: 88th IETF Meeting Vancouver, BC, Canada November 3-8, 2013 Host: Huawei Meeting venue: Hyatt Regency Vancouver: http://vancouver.hyatt.com/en/hotel/home.html Register online at: http://www.ietf.org/meetings/88/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 28 October 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local Vancouver time. G. On-site Registration starting Sunday, 3 November 2013 at 1100 local Vancouver time. 2. Visas Letters of Invitation: Information on Visiting Canada, please visit: http://www.cic.gc.ca/english/visit/index.asp After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Canada. 3. Accommodations The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, the meeting venue, as well as at the overflow hotel Fairmont Hotel Vancouver, which is located across the street from the Hyatt. Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel room tax, GST and Destination Management Fee) are excluded from the guestroom rate and are subject to change. Room rates DO NOT include daily breakfast. Reservations Cut off Date: Hyatt Regency Vancouver - 20 October 2013 Fairmont Hotel Vancouver - 11 October 2013 For additional information on rates and policies, please visit: http://www.ietf.org/meetin/88/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 3 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 3 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 88 companions mailing list only see: https://www.ietf.org/mailman/listinfo/88companions Only 71 days until the Vancouver IETF!
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hello, This message has a Bcc to an IETF participant. In my write-up for the Responsible Area Director I mentioned that: There was an intermediate conclusion about the topic of whether the SPF protocol should use the SPF RRTYPE or the TXT resource record. It was followed by an objection. After discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as some DNSEXT WG participants were not aware of RFC 6686. The WGLC announcement [1] for draft-ietf-spfbis-4408bis-14 was sent on April 9, 2013 and it was mentioned that the WGLC will close on April 24. I posted my review as document shepherd on April 23 [2] and looked into the IANA Considerations Section of the draft as there is a question in the write-up about whether the IANA Considerations are clear and complete. Something unusual occurred. A very high number of messages were posted about on a thread about the DNS Parameters registry [3]. Most of the comments were submitted after the end of the WGLC. On April 25, the Responsible Area Director [4] commented that: This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter. In another message he commented [5] that: If you think SPFBIS was being superficial in its treatment of this topic and can identify an argument that was missed, fine. The thread was left to run in case an argument was missed. The SPFBIS WG Chairs [6] posted a message on April 30 about the planned deprecation of the SPF RRTYPE and whether TXT is an appropriate thing to use and if it is whether the SPF use of it is ok. There is the following text in the write-up: Some WG participants have mentioned that they may express extreme discontent about the decision to obsolete the SPF RRTYPE during the Last Call. That is a notification to the Responsible Area Director and the other members of the IESG about the matter. I reviewed the discussion about the RRTYPE several times in doing the write-up and after that to determine whether the following is correct: The WG consensus about the RRTYPE can be described as particularly rough. I did not find any problem in the process followed to reach that conclusion. I read the messages posted on the IETF mailing list [7]; there are around a 100 messages. I didn't notice any messages about an issue with the above statement. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg03507.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03681.html 7. http://www.ietf.org/mail-archive/web/ietf/current/msg81609.html
Re: The Last Call social contract (was - Re: Rude responses)
On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
On 23August2013Friday, at 11:04, John Levine wrote: Nobody has argued that SPF usage is zero, and the reasons for deprecating SPF have been described repeatedly here and on the ietf list, so this exercise seems fairly pointless. the reasons for not deprecating SPF have been described here and on the ietf list repeatedly ... yet there has been little concrete data regarding deployment uptake. Sigh. We have RFC 6686. Since this is clearly an issue you consider to be of vital importance, it is baffling that (as far as I can tell) you did not contribute to or even comment on it when it was being written and published. work assignments occasionally take me away from active engagement in IETF matters. sorry for the few years absence. Those of us in the mail community have a lot of anecdotal evidence, too. Most notably, none of the large providers that dominate the mail world publish or check type 99, and the one that used to check type 99 (Yahoo) doesn't any more. You don't have to like it, but it's silly to deny it. not sure why you think the DNS data presented is anecdotal. Looked kind of empirical to me. i've not seen a yahoo person describe what they have or have not done or why. we have no data on why Microsoft may or may not support type 99 (see Jay's questions). Much of the mail community data seems anecdotal… very little first hand, empirical stuff. (and I thank you for your data) In any event, it's purely a strawman that nobody checks type 99. A few people do, the WG knows that, and we decided for well documented reasons to deprecate it anyway. demuxing type 16 records is a choice. using type 99, which was specifically designed for this use, is a choice. using application specific types have distinct technological advantages (see PHB comments). They may be small, but are real and have an impact on the DNS and the application. regarding the specific claims regarding adoption, I was asking for a brief period to collect more empirical data to track the magnitude and ratio of type 99 v. type 16 use (noting, as PAF has already noted, that not all type 16 == type 99, so for accurate understanding - someone needs to look at type 99 muxed into a type 16 format… if only to correctly understand the change in ratio. the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? R's, John
Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
The SPFbis document improperly conflates DNS terminology with identical terms invented by this document. Examples are terms used to describe mechanisms having the same identifier differentiated between mechanisms and DNS resource records by using lower and upper case respectively. References to SPF records are differentiated by a textual prefix and not by TYPE as defined by DNS. In addition, the MARID WG NEVER reached consensus. A follow-on group operating outside of the IETF required a promise of support to subscribe to their mailing list. When one looks at how SPF is commonly used, the pre-existing APL resource record offered an effective alternative, but was oppose by a particular vendor unwilling to fully implement DNS. Currently this vendor is seldom used to directly interface with MTAs on the Internet and no longer justifies the use of the TXT records. As such, the SPF Resource Record should not have been deprecated. This draft should be made Informational and not Standards Track. Section 4.6.4 fails to offer a sufficiently clear warning about potential magnitudes of DNS transactions initiated by a single SPF evaluation where two are recommended to occur one for the separate identifiers. In fact, this section appears to make assurances no more that 10 DNS queries will result and is widely misunderstood. 4.6.4. DNS Lookup Limits Was: ,-- SPF implementations MUST limit the total number of mechanisms and modifiers (terms) that cause any DNS query to 10 during SPF evaluation. '-- Change to: ,--- SPF evaluation must limit the number of mechanisms, and the modifier term 'redirect' to occur in no more than10 instances within the evaluation process. The mechanisms 'ip4', ip6', and 'all' are excluded from this instance limitation. Each mechanism is permitted to resolve subsequent resource record sets (RRsets) that MUST not contain more than 10 resource records to complete a match check. When the number of instances exceeds 10, or when subsequent resolutions exceeds 10, check_host() MUST produce a “permerror” result. The maximum number of DNS transactions initiated by an SPF evaluation is therefore 1 for the initial SPF resource record, 10 for each mechanism times 10 transactions needed to complete a matching process for a total of 111 DNS transactions. This number excludes those required by DNS to fulfill a request and those required by an EXP modifier. The recommended 20 second evaluation timeout imposes a maximum network distance of less than 27,000 kilometers or a little more than half the circumference of the Earth. Even a 60 millisecond delay can result in more than a 6.6 seconds consumed by the round trip overhead needed for each SPF evaluation. The overall resulting maximum number of DNS transactions for both HELO and MAIL FROM is 222 DNS transactions. Since check_host() introduces macros and name expansions that combine mechanisms and modifiers in a manner not directly supported by DNS, the entire set and sequence of SPF based DNS transactions is required for each evaluation. While SPF now has a 2 limit of void lookups, use of synthetic domains has become a popular technique for tracking traffic which can be used by malefactors to overcome this SPF void lookup limit. Once DNSsec becomes a requirement, SPF will have created an inordinate number of transactions and overall traffic per message exchange that will impose a SIGNIFICANT reflected amplification risk. '--- Related information: random-stringcdr-ds.metric.gstatic.com random-string.g.vm.akamaistream.net are domains on sizable networks that act as a wildcards. In the second instance, the wildcard points to a CNAME that then resolves an A record. Such use compared against http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 produces a much larger amplification than the x320 gain estimated. Use of DNSsec further increases this gain estimate. Although details differ from case to case, the synthetic domain technique is seeing greater use. One of the initial reasons for using TXT records without any prefix was to permit use of wildcards. This dangerous feature means SPF allows malefactors to leverage any large TXT resource record that otherwise would not have been problematic. Again this risk increases when DNSsec becomes required and represents another reason for not deprecating the SPF resource record type. Remove this misleading paragraph within section 4.6.4: ,--- When evaluating the mx mechanism, the number of MX resource records queried is included in the overall limit of 10 mechanisms/ modifiers that cause DNS lookups described above. The evaluation of each MX record MUST NOT result in querying more than 10 address records, either A or resource records. If this limit is exceeded, the mx mechanism MUST produce a permerror result. '--- MX resource records do not contain IP addresses. Per RFC1035 the structure for an MX record is roughly as follows: A 16 bit PREFERENCE
Re: The Last Call social contract (was - Re: Rude responses)
Dave Crocker wrote: On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. d/ My particular concern is that you using this abusive argument increasingly against people leading to a next public suggestion to justify invoking IETF moderation, if necessary. Once a well respected senior member as yourself speaks as such, people do listen and its extremely intimidating to constantly see this threatening form of excommunications and moderation against folks. If one responds, then they are risk of getting labeled abusive, and hence moderation is invoked. In my opinion, I don't see highly debated issues like the SPF typ99e issue all the time with last calls. At least I don't or I don't get involved with it if its not related to my work. This rarity suggest that the IETF LC system still works and that we are simply experiencing a real divided technical infrastructure design issue that was highly predictable to be a conflict outside the working group. Pete suggested as much with fewer cross area reviews occurring within the IETF. I agree that this is one of those diversity improvements areas. Not enough cross area peer review before the WGLC and IETF LC takes place. The goal is to minimizes these contentious engineering issues. I have been involved with the SPF protocol before MARID, during MARID, an early adopter and also involved in the SPFBIS efforts. It is my assessment the SPFBIS WG did not receive adequate cross area reviews and DNS industry input *before* the removal decision was made, which was practically immediate and expected before the first draft was even written. Instead, the same already discussed arguments was used and the removal decision was implemented in the draft. In my opinion, there was significant concerns about the removal within the WG and outside the WG, yet the decision was made to pull it anyway at the IETF meeting. This immediately put the burden on everyone to reverse or at least get a better discussion going about keeping the migration path and also get a better handle of whats going on with the dearth in the supportive infrastructure for the handling of unknown RR types. In my opinion, it would be better to seek the input from DNS vendors to see what the future is regarding new RR types and passthru handling of unknown types (RFC 3597). I request reaching out to folks in Microsoft DNS product management to determine what has fell through the cracks. If there is continued lack of interest, then the SPF type99 removal is reasonable to me. You seem to think that this was already done. I don't think so. Perhaps you believe that the infrastructure will never be ready to support new RR types. If so, that is important to know. -- HLS
Re: The Last Call social contract (was - Re: Rude responses)
Hi Dave, I read the messages on this thread. I suggested to the participant to comment. I am okay with the comments which were made. I had an off-list exchange before the message that generated the other thread. The exchange was not antagonistic. Some people read please read the archives as a requirement. That led to a misunderstanding. During a Last Call someone has to figure out what the issues are and whether they have been addressed or not. The misunderstandings do not make the work easier. Regards, S. Moonesamy
Re: The Last Call social contract (was - Re: Rude responses)
On Fri, Aug 23, 2013 at 3:46 PM, Dave Crocker d...@dcrocker.net wrote: On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. I think you were out of line because the type of issues being raised are precisely the type of issues that are appropriate to raise in IETF last call, indeed are the reason for having an IETF wide last call in the first place. If I see a WG railroading a scheme that I think is botched architecturally then of course IETF LC is the place to raise it. Adding in a requirement, sure. In this case the issues being raised are a repeat of the arguments made from ten years ago and I don't have much sympathy for them given the way the folk raising them behaved then and in particular their total lack of concern for the deployment issues raised by the group. But I don't criticize them on the process question, IETF LC is exactly the place to raise this issue. It is one area kibitzing on the work of another. That is an IETF layer issue for sure. -- Website: http://hallambaker.com/
IETF 88 - Registration Now Open!
88th IETF Meeting Vancouver, BC, Canada November 3-8, 2013 Host: Huawei Meeting venue: Hyatt Regency Vancouver: http://vancouver.hyatt.com/en/hotel/home.html Register online at: http://www.ietf.org/meetings/88/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 28 October 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local Vancouver time. G. On-site Registration starting Sunday, 3 November 2013 at 1100 local Vancouver time. 2. Visas Letters of Invitation: Information on Visiting Canada, please visit: http://www.cic.gc.ca/english/visit/index.asp After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Canada. 3. Accommodations The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, the meeting venue, as well as at the overflow hotel Fairmont Hotel Vancouver, which is located across the street from the Hyatt. Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel room tax, GST and Destination Management Fee) are excluded from the guestroom rate and are subject to change. Room rates DO NOT include daily breakfast. Reservations Cut off Date: Hyatt Regency Vancouver - 20 October 2013 Fairmont Hotel Vancouver - 11 October 2013 For additional information on rates and policies, please visit: http://www.ietf.org/meetin/88/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 3 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 3 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 88 companions mailing list only see: https://www.ietf.org/mailman/listinfo/88companions Only 71 days until the Vancouver IETF!
Huawei to Host IETF 88 in Vancouver!
Announce Huawei Host Vancouver The IAOC is pleased to announce that Huawei will be the Host for IETF 88 in Vancouver. Huawei has been a long time supporter of the IETF through its participation and sponsorships at IETF meetings, but this is their first time as the Host of an IETF meeting. Congratulations, welcome and Thank You! Registration is now open for IETF 88 at: http://www.ietf.org/meetings/88/ Many sponsorship opportunities are still available: http://iaoc.ietf.org/documents/IETF-Sponsorship-Opportunities-20132002.pdf If interested contact Andrew Dvorshak, dvors...@isoc.org. Once again, thank you Huawei!. See you in Vancouver in 71 days. Ray IAD 2014 Meeting Venues IETF 89 London Hilton MetropoleMarch 2-7 IETF 90 Toronto Fairmont Royal York July 20 - 25 IETF 91 HonoluluHilton Hawaiian Village November 9 - 14
New Non-WG Mailing List: pntaw -- Discussion list for practices related to proxies, NATs, TURN, and WebRTC
A new IETF non-working group email list has been created. List address: pn...@ietf.org Archive: http://www.ietf.org/mail-archive/web/pntaw/ To subscribe: https://www.ietf.org/mailman/listinfo/pntaw Purpose: This mailing list will discuss how webrtc clients, proxies, NATs and TURN servers interact. For additional information, please contact the list administrators.
RFC 7020 on The Internet Numbers Registry System
A new Request for Comments is now available in online RFC libraries. RFC 7020 Title: The Internet Numbers Registry System Author: R. Housley, J. Curran, G. Huston, D. Conrad Status: Informational Stream: IETF Date: August 2013 Mailbox:hous...@vigilsec.com, jcur...@arin.net, g...@apnic.net, d...@virtualized.org Pages: 9 Characters: 19332 Obsoletes: RFC 2050 I-D Tag:draft-housley-rfc2050bis-02.txt URL:http://www.rfc-editor.org/rfc/rfc7020.txt This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today. 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/search/rfc_search.php 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
