STEAM: BOF proposal for Berlin
STEAM: BOF proposal for Berlin You may have noticed a recent trend in the IETF towards very lightweight protocols for the Internet of Everything. http://tools.ietf.org/html/draft-draft-draft is the most fully developed proposal on the table today. It is extremely lightweight by simply using UDP and nothing else. Recently, however, that draft has been criticized for lack of congestion control. And rightly so, because the only way to have congestion control is to use TCP. And, TCP is all you need. But then, clearly, there aren't enough RFCs about TCP yet [RFC4627]. A new WG will therefore develop Secure TCP Extensions for Application and Management (STEAM). Again, TCP is all you need, but it hasn't been used for Provisioning very much yet. The main objective of the new WG is therefore an informational document for Secure Provisioning for Applications and Management using TCP Reimagined as an Attractive Protocol, SPAM-TRAP. We aren't quite sure yet whether STEAM will be in the Security, Transport, Application, or Management Areas, or whether it should have its own area (EVG for Internet of Everything). We will use the BOF in Berlin to figure out, and to set up the new EVG area in the IETF, and to restyle the IETF to Internet of Everything Task Force. One other field that STEAM will be working in is IETF process innovation. (We also figure you can't post to the IETF mailing list without including at least one process improvement suggestion. So we make two.) 1) You might notice there is no R in STEAM. This is because we have to increase collaboration within a diverse IETF. The RTG area already has the ROLL working group, which has been very innovative in getting routing protocols to standards track RFC before there is even a glimpse of security, applicability or management. Doing standardization in smoke-filled backrooms is unhealthy, and STEAM has many of the properties needed for a replacement process. We don't want to spill the beans just yet, but can already say the process innovation will be named in honor of the two WGs, STEAM/ROLL. 2) Finally, preparing for the global deployment of the Internet-Enabled Smart Grid (IESG), and to further increase diversity, we probably want to enable the use of steam-powered typewriters for IETF work. The STEAM WG will enhance the RFC format and process to allow direct publishing from typewritten sheets and scanned printouts of Word documents. See you at the STEAM BOF in Berlin, Daniel Raft
Re: STEAM: BOF proposal for Berlin
I'm thinking the enhanced RFC format proposed below should be dubbed STEAM/PUNC. Tony Hansen On 4/1/2013 6:52 AM, Daniel Raft wrote: STEAM: BOF proposal for Berlin ... 2) Finally, preparing for the global deployment of the Internet-Enabled Smart Grid (IESG), and to further increase diversity, we probably want to enable the use of steam-powered typewriters for IETF work. The STEAM WG will enhance the RFC format and process to allow direct publishing from typewritten sheets and scanned printouts of Word documents.
Re:The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format draft-guo-idoca-with-the-html-file-format-00
Zhun : What are your I-D about? As I know , native office applications based on XML. Then you draft are about some product ,such as Google Docs, Microsoft Office 365, IBM Docs ,Zoho,ThinkFree,Cisco WebEx,Evernote...? Susie
RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
' revoked status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560.' I fail to understand this statement about backward compatibility. How does revoked being optional/required breaks backward compatibility? The only reason cited in the WG discussions to use revoked for not-issued was that any other approach would break backward compatibility with legacy clients. And now the draft says that revoked is optional because making it required won't be backward compatible. And it gives the impression that best course of action for 2560bis responders is to start issuing revoked for not-issued, which is far from the originally stated goal to provide a way for CAs to be able to return revoked for such serial numbers. -Piyush -Original Message- From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of Stefan Santesson Sent: Thursday, March 28, 2013 3:34 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; ietf@ietf.org Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 I have given this a go by expanding the note as follows: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. The revoked status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560. For example, the responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre produced responses in accordance with RFC 5019 and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers. Does this solve you issue. I think this is as far as dare to go without risking a heated debate. /Stefan On 3/27/13 5:08 PM, Black, David david.bl...@emc.com wrote: Stefan, Is this important enough to do that? IMHO, yes - the running code aspects of existing responder behavior/limitations are definitely important enough for an RFC like this that revises a protocol spec, and the alternatives to revoked feel like an important complement to those aspects (discussion what to do instead when responder behavior/limitations are encountered). I appreciate the level of work that may be involved in capturing this, as I've had my share of contentious discussions in WGs that I chair - FWIW, I'm currently chairing my 4th and 5th WGs. OTOH, when a WG has put that much time/effort into reaching a (compromise) decision, it really is valuable to record why the decision was reached to avoid recovering that ground in the future and (specific to this situation) to give implementers some more context/information on how the protocol is likely to work in practice. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 11:38 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 I could. My worry is just that this is such a contentious subject and it took us x hundreds of emails to reach this state, that if I add more explanations, people will start disagreeing with it and that we end up in a long debate on how to correctly express this. Is this important enough to do that? /Stefan On 3/27/13 3:30 PM, Black, David david.bl...@emc.com wrote: Hi Stefan, Does this answer your question? Yes, please add some of that explanation to the next version of the draft ;-). Coverage of existing responder behavior/limitations (important running code concerns, IMHO) and alternatives to using revoked (have a number of tools to prevent the client from accepting a bad certificate) seem particularly relevant. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 7:44 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen- a...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Yes I missed to respond to that aspect. This is a bit complicated, but we have a large legacy to take into account where some responders implements just RFC 2560, while some deliver
Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
On 3/29/13 5:17 PM, Piyush Jain piy...@ditenity.com wrote: ' revoked status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560.' I fail to understand this statement about backward compatibility. How does revoked being optional/required breaks backward compatibility? The only reason cited in the WG discussions to use revoked for not-issued was that any other approach would break backward compatibility with legacy clients. And now the draft says that revoked is optional because making it required won't be backward compatible. Yes. Making it required would prohibit other valid ways to respond to this situation that is allowed by RFC 2560 and RFC 5019. Such as responding good or responding with unauthorized error. And it gives the impression that best course of action for 2560bis responders is to start issuing revoked for not-issued, which is far from the originally stated goal to provide a way for CAs to be able to return revoked for such serial numbers. The latter is what optional means. /Stefan
RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
Joel, Yes, I think you do have the right end of the question, and that new text looks ok, as the previous sentence introduces the gratuitous ARP. To summarize, we've decided to address two of the three concerns from the review of -06. The third concern that will not be addressed is: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, I'm satisfied with this outcome. Thanks, --David -Original Message- From: Joel M. Halpern [mailto:j...@joelhalpern.com] Sent: Friday, March 29, 2013 6:08 PM To: Ted Lemon Cc: Black, David; McPherson, Danny; s...@ietf.org; ietf@ietf.org; gen- a...@ietf.org; Jean-Michel Combes; joel.halp...@ericsson.com Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 I have a draft version with this correction. David, would adding: When such a move is done without changing the MAC address, the SAVI switches will need to update their state. While the ARP may be helpful, traffic detection, switch based neighbor solicitation, interaction with orchestration system, or other means may be used. to the end of 5.2.3 address your concern? I am not sure whether I have the right end of the question here, given that SAVI can not create new protocol. Yours, Joel On 3/27/2013 10:56 PM, Ted Lemon wrote: On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct jmh.dir...@joelhalpern.com wrote: Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Old: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad] changes which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. New: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad], VRRP, or other link management operations, change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. I think you probably meant or, not are, in the second word of the second-to-last line of the new text. As far as I am concerned, given that David is happy with your recent change, I'm happy with it too. However, since you are asking, if you were willing to also accommodate David's other request (see below) by adding some text to the document in section 5, that would be an added bonus: A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. So if you can do this, it would be much appreciated; if you can't do it, I think the document is valuable enough to move forward without this additional work.
Re: STEAM: BOF proposal for Berlin
Tony Hansen t...@att.com writes: I'm thinking the enhanced RFC format proposed below should be dubbed STEAM/PUNC. And anyone that participates in said work would be STEAMed. -- Wes Hardaker SPARTA, Inc.
Re: STEAM: BOF proposal for Berlin
STEAM: BOF proposal for Berlin You may have noticed a recent trend in the IETF towards very lightweight protocols for the Internet of Everything. http://tools.ietf.org/html/draft-draft-draft is the most fully developed proposal on the table today. It is extremely lightweight by simply using UDP and nothing else. Recently, however, that draft has been criticized for lack of congestion control. And rightly so, because the only way to have congestion control is to use TCP. Is efficiency problem, did not you read draft-draft-draft ? And, TCP is all you need. But then, clearly, there aren't enough RFCs about TCP yet [RFC4627]. A new WG will therefore develop Secure TCP Extensions for Application and Management (STEAM). Again, TCP is all you need, but it hasn't been used for Provisioning very much yet Too complicated Daniel, you always attack my ideas since we twin babies together and now you attack even on our birthday. D.Raft (Ms)
Re: STEAM: BOF proposal for Berlin
I thought the DRAFT proposal was very interesting, but it includes RFC2119 for a single throw-away bit of normative language. Port 9? Please! You already excluded port 9 with the language in the later paragraph on port allocation. So it's blatantly obvious that you are referencing RFC2119 just to make your draft look cool. Please take that paragraph out. Let the proposal stand on its merits.
Re: STEAM: BOF proposal for Berlin
PORT 9 FROM OUTER SPACE
Re: STEAM: BOF proposal for Berlin
Dear Daniel, IETFers: With regard to security, I'm afraid the proposed scope of work is covered to a large extent by a breakthrough patent application titled Defending the namespace for which the abstract reads: This invention is about an global entity oriented declarative authentication and security system that can be used in the present and future internet based distributed applications and services. An entity here refers to an unique object (most likely to be physical or human) or aspect that can hardly be duplicated. The system provides both authentication and security (A S). It can be used in areas comprising one to one or one to many (OR or AND) content publication or distribution so that maximum granularity of access control is made possible. Examples comprise 1) A S in messaging or communication (one to one). 2) A S in publication or distribution or information sharing (one to many(OR)). 3) Secured document escrowing (one to many(AND)). 4) Declarative just in time A S for web-services. 5) Copyright protection for digital products. 6) Digital cash. 7) Internet based electronic voting system. 8) Witnessed digital legal papers. 9) Support large scale virtualized virtual private network and its applications. 10) etc. The reference is the US patent application publication 20040255137. If the BOF proceeds, at least this will deserve an IPR disclosure. - Thierry Daniel Raft wrote: STEAM: BOF proposal for Berlin You may have noticed a recent trend in the IETF towards very lightweight protocols for the Internet of Everything. http://tools.ietf.org/html/draft-draft-draft is the most fully developed proposal on the table today. It is extremely lightweight by simply using UDP and nothing else. Recently, however, that draft has been criticized for lack of congestion control. And rightly so, because the only way to have congestion control is to use TCP. And, TCP is all you need. But then, clearly, there aren't enough RFCs about TCP yet [RFC4627]. A new WG will therefore develop Secure TCP Extensions for Application and Management (STEAM). Again, TCP is all you need, but it hasn't been used for Provisioning very much yet. The main objective of the new WG is therefore an informational document for Secure Provisioning for Applications and Management using TCP Reimagined as an Attractive Protocol, SPAM-TRAP. We aren't quite sure yet whether STEAM will be in the Security, Transport, Application, or Management Areas, or whether it should have its own area (EVG for Internet of Everything). We will use the BOF in Berlin to figure out, and to set up the new EVG area in the IETF, and to restyle the IETF to Internet of Everything Task Force. One other field that STEAM will be working in is IETF process innovation. (We also figure you can't post to the IETF mailing list without including at least one process improvement suggestion. So we make two.) 1) You might notice there is no R in STEAM. This is because we have to increase collaboration within a diverse IETF. The RTG area already has the ROLL working group, which has been very innovative in getting routing protocols to standards track RFC before there is even a glimpse of security, applicability or management. Doing standardization in smoke-filled backrooms is unhealthy, and STEAM has many of the properties needed for a replacement process. We don't want to spill the beans just yet, but can already say the process innovation will be named in honor of the two WGs, STEAM/ROLL. 2) Finally, preparing for the global deployment of the Internet-Enabled Smart Grid (IESG), and to further increase diversity, we probably want to enable the use of steam-powered typewriters for IETF work. The STEAM WG will enhance the RFC format and process to allow direct publishing from typewritten sheets and scanned printouts of Word documents. See you at the STEAM BOF in Berlin, Daniel Raft
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
SM, On 03/31/2013 06:29 AM, SM wrote: 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-04-12. Exceptionally, comments may be From Section 6: In general, the possible mitigations boil down to enforcing on native IPv6 and IPv6 transition/co-existence traffic the same security policies currently enforced for IPv4 traffic, and/or blocking the aforementioned traffic when it is deemed as undesirable. My reading of the mitigation is that it comes down to block everything IPv6. The draft seems to treat every network as a military operation network. Please re-read the above paragraph -- you missed the part that says ...the same security policies. In the Section 1: Native IPv6 support could also possibly lead to VPN traffic leakages when hosts employ VPN software that not only does not support IPv6, but that does nothing about IPv6 traffic. [I-D.ietf-opsec-vpn-leakages] describes this issue, along with possible mitigations. I don't understand the relationship between the above and IPv4-only networks. Those issues are not present when your network employs v4-only. From Section 2: This means that even if a network is expected to be IPv4-only, much of its infrastructure is nevertheless likely to be IPv6 enabled. What is an IPv4-only network? A network were none of the devices connected to it implement v6. [CORE2007] is a security advisory about a buffer overflow which could be remotely-exploited by leveraging link-local IPv6 connectivity that is enabled by default. How is this attack mitigated within the context of the draft? The reference is meant to illustrate that that even if you think your network only employs IPv4 (and hence forget about the v6 support), you could be hit by that. Additionally, unless appropriate measures are taken, an attacker with access to an 'IPv4-only' local network could impersonate a local router and cause local hosts to enable their 'non-link-local' IPv6 connectivity (e.g. by sending Router Advertisement messages), possibly circumventing security controls that were enforced only on IPv4 communications. Where is the mitigation for this? For attacks that employ link-local connectivity, it bolds down to packet filtering (either by a personal firewall at the host, or by filtering v6 at layer-2) -- this is discussed in the I-D. From Section 4: IPv6 deployments in the Internet are continually increasing I am no longer worried about IPv6 deployment as the OPSEC working group has a plan to stop that. :-) 'Upstream filtering of transition technologies or situations where a mis-configured node attempts to provide native IPv6 service on a given network without proper upstream IPv6 connectivity may result in hosts attempting to reach remote nodes via IPv6, and depending on the absence or presence and specific implementation details of Happy Eyeballs [RFC6555], there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012].' I don't see what Happy Eyeballs has to do with operational security. Happy Eyeballs has to do with what you do when you drop packets. If you silently drop them, the host may have rely on timeouts rather than having a positive indication that a packet has been dropped. For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering records at the network ingress point to prevent the internal hosts from attempting their own DNS resolution. The above breaks DNS in an attempt to remove everything IPv6 related from the network. Could you please elaborate? The title of the draft is Security Implications of IPv6 on IPv4 Networks. The Abstract mentions IPv4-only networks. The Introduction Section mentions networks that are assumed to be IPv4-only. Please see the quotes when we say 'IPv4-only' networks -- in practice, there's no such a thing, and you should think v6 security even if you think/want to run an IPv4-only network. I don't understand what this draft is about. This one I cannot do much about. :-) -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: [OPSEC] Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Brian, On 03/29/2013 10:38 AM, Brian E Carpenter wrote: My minimal request for this draft is for my name to be removed from the Acknowledgements, as I do not think that my comments have been acted on. That has been my intent, and I sent a note before publishing one of the latest revs to double-check that (not sure if I missed your respond, or you didn't respond). In fact, I think that in its current state, this document is harmful to IPv6 deployment. It in effect encourage sites to fence themselves into an IPv4-only world. Particularly, it explicitly suggests a default/deny approach to IPv6-in-IPv4 tunnels, which would prevent the typical baby steps first approach to IPv6 deployment. Sites that implement any kind of security policy employ a default deny policy (for the simple reason that it's safer to open holes than explicitly close them). The bottom-line is that if your site enforces any kind of security policy, you should make an explicit decision regarding what you do with v6, rather than being unaware that it's there in your network. I would like to see the document convey a positive message, suggesting that an IPv4 site first decides which IPv6 deployment mechanism it will use, and then configures security appropriately (to allow that mechanism and block all others). There's an operational gap here: in many cases, operators have no tools to enforce security policies on such tunneled traffic. Besides, when thinking about v6, enterprise networks and the like should be doing native IPv6 (in which case v6 security controls would be enforced throughout the network), rather than having each node go their own way. A specific aspect of this is that if a site provides one well-managed 6in4 tunnel mechanism, all tunneled IPv6 packets will pass through well-defined points where security mechanisms may be applied. In which case you'd be enforcing IPv6 security controls, which is entirely in-line ith what this document is saying. We shouldn't imply that not having an IPv6 plan and blocking all IPv6 by default is a sound strategy. It's not, and I don't think we're implying that. However, I'd note that some people are in the position of blocking traffic, or not doing anything about it. Check for IPv6 support in different security products, and you might get depressed. Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
RE: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Since I was the one that provided some of this text and raised the issues it's addressing, I'll take a crack at responding at a couple of your concerns below. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM 'Upstream filtering of transition technologies or situations where a mis-configured node attempts to provide native IPv6 service on a given network without proper upstream IPv6 connectivity may result in hosts attempting to reach remote nodes via IPv6, and depending on the absence or presence and specific implementation details of Happy Eyeballs [RFC6555], there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012].' I don't see what Happy Eyeballs has to do with operational security. [WEG] It doesn't. This is a second-order effect, but IMO an important one. If one is attempting to prevent IPv6 from being used on a network in an effort to secure it from IPv6-related vulnerabilities, one must consider the fact that there are multiple IPv6 transition technologies specifically designed to enable IPv6 access on a network that is otherwise without IPv6 connectivity, some that can be used without any coordination from the upstream network admins. It might even helpfully try to share its IPv6 service with other hosts on the network (rogue RAs...). The act of preventing those transition technologies from passing traffic (by doing things like blocking protocol 41, for example) may create IPv6 connectivity that is broken or otherwise impaired, where an end host believes that it has IPv6 connectivity via a transition technology when it fact it does not because its transition mechanism is being blocked upstream. Happy Eyeballs attempts to fix this by ensuring that fallbacks to IPv4 happen more rapidly and IPv4 is preferred when issues are detected with IPv6 connectivity. However, it's inappropriate to rely on pervasive implementation of Happy Eyeballs as the sole solution to prevent end host impacts, since the end user may not know that IPv6 is actively being disabled on this network, or that their IPv6 implementation is otherwise broken. This is a problem that continues to get worse the more dual-stack content becomes available. For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering records at the network ingress point to prevent the internal hosts from attempting their own DNS resolution. The above breaks DNS in an attempt to remove everything IPv6 related from the network. [WEG] On a network with the stated goal of providing/allowing no IPv6 connectivity, records are effectively useless. Preventing hosts from receiving records in order to prevent them from attempting to connect to an IPv6 address and failing is not broken DNS. Regards, Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
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-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10,2013 IESG Telechat date: Not yet scheduled for a telechat Summary: This document is not ready for publication as an Informational RFC. It may be on the right track, but there issues both in substance and form that need to be addressed. Major issues: The document doesn't provide what its title and abstract claim it will provide. For instance, the abstract claims a gap analysis is presented following a renumbering event procedure summary, but neither appear in the draft. There are a few places in the text that say this is a gap, but usually it's not clear what this means. The stated intent is to identify missing capabilities (gaps) and the work needed to provide them. The document should lay these out very clearly. As the document is currently written, it is difficult to pull out a simple list of identified gaps. While addressing that, it would help more to provide some sense of the relative importance of addressing each of the gaps identified. There are several significant issues with clarity. I will point to the most difficult in a section below. -- Minor issues: The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. RFC4076 seems to say very similar things to this document. Should it have been referenced? Section 5.3 punts discussion of static addresses off to RFC 6866. That document was scoped only to Enterprise Networks. The scope of this document is larger. Are there gaps because of that difference in scope that were missed? Would it make sense to summarize any gaps RFC 6866 identified that are relevant to this document here? Should section 8 belong to some other document? It looks like operational renumbering advice/considerations, but doesn't seem to be exploring renumbering gaps, except for the very short section 8.2 which says we need a better mechanism without much explanation. -- Text needing clarity (more than nits): Section 4.1, second paragraph: The first sentence needs to be simplified. Something like Delegation routers may need to renumber themselves with new delegated prefixes perhaps. The second sentence speaks of the router renumbering issue as if it's clear which particular issue you're actually talking about. Is there a gap here? If so, consider replacing the entire paragraph with an explicit description of the gap. Section 5.1, first bullet, 2nd paragraph: The third sentence (starting In ND protocol,) makes no sense. The fourth sentence is also hard to parse. Section 5.1, first bullet. The list below the impact of ambiguous M/O flags says things like there is no standard and it is unspecified. I think you are trying to say that there is ambiguity in what's written, not that nothing's written. This entire list would benefit from being recast in terms of what needs to be done (what are the gaps?). Section 5.2, last paragraph. It's not clear what you are trying to say here. Is it simply that the natural pressures in an ISP make it more likely that an ISP would choose to use DNS names as part of configuration than an enterprise would? If so, can you list what some of those pressures are? What gap is this discussion trying to identify? Section 6.1, first paragraph, first sentence (starting For DNS records update) - this sentence does not parse. What is it trying to say, and what's the gap you are trying to point to? Section 6.3, 6th paragraph. So there's a big gap for configuration aggregation is unclear. Is it that configuration isn't stored in one place, or that it can't be found through one place, or something different? Section 7.1 second bullet. Taking this partial quote from RFC4192 destroyed the meaning of the sentence. The original sentence said The suggestion applies - this misquote says reducing the delay applies. There's no benefit to quoting 4192 directly - say what you mean and reference 4192. -- Nits/editorial comments: There are a few sentences ending with etc. in the document. Please consider deleting the word from the list - it doesn't help each sentence make its point. Introduction: Future efforts may be achieved in the future. doesn't add anything to the document. I suggest deleting the sentence. Section 3.2: Consider deleting basically from an IPAM is basically used Section 5.1: draft-ietf-dhc-host-gen-id is no
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Hi Fernando, At 05:49 01-04-2013, Fernando Gont wrote: Please re-read the above paragraph -- you missed the part that says ...the same security policies. I saw that. :-) I commented on Section 6 first as it's only when I reached that part of the document that I saw the trade-off between blocking IPv6 traffic and security. Those issues are not present when your network employs v4-only. What's missing is some text in the Introduction section explaining that the draft is discussing about IPv4 networks (what is mentioned above). A network were none of the devices connected to it implement v6. If that is the case some of the attacks would not be possible. The scenario the draft discusses about is when there are devices which have IPv6 support. The draft could have an explanation about IPv4 networks (see previous comment) and then follow it with the first sentence of Section 1. It can then go into a discussion of the threats and how to mitigate them. From Section 1: filtering IPv6 traffic (whether native or transition/co-existence) to mitigate IPv6 security implications on IPv4 networks should (generally) only be considered as a temporary measure until IPv6 is deployed. It's not a temporary measure in the sense that there is an assumption that the network should be IPv4 only. If the network is to support IPv4 and IPv6, filtering of IPv6 traffic is not recommended then. The reference is meant to illustrate that that even if you think your network only employs IPv4 (and hence forget about the v6 support), you could be hit by that. Ok. For attacks that employ link-local connectivity, it bolds down to packet filtering (either by a personal firewall at the host, or by filtering v6 at layer-2) -- this is discussed in the I-D. I don't see anything about that in the draft. There is a mention of filtering at Layer 2 and Layer 3. Happy Eyeballs has to do with what you do when you drop packets. If you silently drop them, the host may have rely on timeouts rather than having a positive indication that a packet has been dropped. This is a browser issue. I'll comment further in another message. Could you please elaborate? The text about DNS (Section 4) is about DNS replies. What I meant was that the draft recommends changing the answer for a (DNS) query in an attempt to stop IPv6 traffic. It's ok to block IPv6 traffic as it's an IPv4-only network. I don't think that it is ok to tamper with DNS replies (in this case you are covered by local policy and you can do that). Please see the quotes when we say 'IPv4-only' networks -- in practice, there's no such a thing, and you should think v6 security even if you think/want to run an IPv4-only network. It might help to reword the Abstract and the Introduction Section so that the purpose of the document is clear. I agree that it is good to think IPv6 security even if I want an IPv4-only network. This one I cannot do much about. :-) :-) Regards, -sm
RE: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
At 10:59 01-04-2013, George, Wes wrote: Since I was the one that provided some of this text and raised the issues it's addressing, I'll take a crack at responding at a couple of your concerns below. Ok. [WEG] It doesn't. This is a second-order effect, but IMO an important one. If one is attempting to prevent IPv6 from being used on a network in an effort to secure it from IPv6-related vulnerabilities, one must consider the fact that there are multiple IPv6 transition technologies specifically designed to enable IPv6 access on a network that is otherwise without IPv6 connectivity, some that can be used without any coordination from the upstream network admins. It might even helpfully try to share its IPv6 service with other hosts on the network (rogue RAs...). The act of preventing those transition technologies from passing traffic (by doing things like blocking protocol 41, for example) may create IPv6 connectivity that is broken or otherwise impaired, where an end host believes that it has IPv6 connectivity via a transition technology when it fact it does not because its transition mechanism is being blocked upstream. Happy Eyeballs attempts to fix this by ensuring that fallbacks to IPv4 happen more rapidly and IPv4 is preferred when issues are detected with IPv6 connectivity. However, it's inappropriate to rely on pervasive implementation of Happy Eyeballs as the sole solution to prevent end host impacts, since the end user may not know that IPv6 is actively being disabled on this network, or that their IPv6 implementation is otherwise broken. This is a problem that continues to get worse the more dual-stack content becomes available. I agree with the last sentence. Happy Eyeballs is about the HTTP. There are other applications protocols too. :-) In the context of the draft you have an IPv4 network and you want the devices or applications to be IPv4-only. I see that as configuring the applications (there is a browser option for IPv4 only access). There isn't any mis-configured node as the document intentionally argues for blocking IPv6 traffic and IPv6 transition technologies. [WEG] On a network with the stated goal of providing/allowing no IPv6 connectivity, records are effectively useless. Preventing hosts from receiving records in order to Yes. prevent them from attempting to connect to an IPv6 address and failing is not broken DNS. If there isn't any IPv6 connectivity it is useless to query for RRs as the host is not going to establish an IPv6 connection. Instead of looking at the problem from that angle the proposal uses a middlebox (not the correct term) to change things. Once it becomes best practice to tamper with DNS there is one more problem to solve as you can no longer rely on DNS working according to specifications. Regards, -sm
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
On 04/01/2013 06:14 PM, SM wrote: prevent them from attempting to connect to an IPv6 address and failing is not broken DNS. If there isn't any IPv6 connectivity it is useless to query for RRs as the host is not going to establish an IPv6 connection. Instead of looking at the problem from that angle the proposal uses a middlebox (not the correct term) to change things. Once it becomes best practice to tamper with DNS there is one more problem to solve as you can no longer rely on DNS working according to specifications. Welcome to the real world: That cat has been out of the box for years (no matter whether you consider that a problem, or a feature). FWIW, my TP-LINK router does that, even if I don't want it to. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Missing requirement in draft-sparks-genarea-imaparch?
May I suggest that the specific details of this be left to the implementation effort. What is easy to implement in this area depends significantly on what platform (and here I mean more imap libraries and imap server technology than say python vs ruby vs .net vs C) A simple requirement like the implementation should consider how to handle abuse of message marking.
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
RFC6921It is well known that as we approach the speed of light, time slows down. AB I know that time slows for something when it is in speed of light, but communication is not something moving. If the packet is in speed of light we may reduce the comm-delay but never less than zero. The communication times don't change if at least one communicator is not moving in light speed. My comment is that I think this RFC is not logical, and I don't understand its recommendations. There is no way that a packet can be received before send, packet-time never changes communicators-time while the positions of both Tx and Rx are semi-fixed (change is relative to communicators' times not their signal). I think the communication-times may change when the communicators are at/above speed of light not the signal/packet. Is my physics correct? AB On 4/1/13, rfc-edi...@rfc-editor.org rfc-edi...@rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 6921 Title: Design Considerations for Faster-Than-Light (FTL) Communication Author: R. Hinden Status: Informational Stream: Independent Date: 1 April 2013 Mailbox:bob.hin...@gmail.com Pages: 7 Characters: 15100 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-hinden-FTL-design-considerations-00.txt URL:http://www.rfc-editor.org/rfc/rfc6921.txt We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
Delete The communication times don't change if at least one communicator is not moving in light speed. AB I meant the communication times MAY change if at least one communicator is moving in light speed. On 4/2/13, Abdussalam Baryun abdussalambar...@gmail.com wrote: RFC6921It is well known that as we approach the speed of light, time slows down. AB I know that time slows for something when it is in speed of light, but communication is not something moving. If the packet is in speed of light we may reduce the comm-delay but never less than zero. The communication times don't change if at least one communicator is not moving in light speed. My comment is that I think this RFC is not logical, and I don't understand its recommendations. There is no way that a packet can be received before send, packet-time never changes communicators-time while the positions of both Tx and Rx are semi-fixed (change is relative to communicators' times not their signal). I think the communication-times may change when the communicators are at/above speed of light not the signal/packet. Is my physics correct? AB On 4/1/13, rfc-edi...@rfc-editor.org rfc-edi...@rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 6921 Title: Design Considerations for Faster-Than-Light (FTL) Communication Author: R. Hinden Status: Informational Stream: Independent Date: 1 April 2013 Mailbox:bob.hin...@gmail.com Pages: 7 Characters: 15100 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-hinden-FTL-design-considerations-00.txt URL:http://www.rfc-editor.org/rfc/rfc6921.txt We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
The words in this message are to be interpreted as described in RFC 6919. Here are some considerations for Faster-Than-Light Communication (see RFC 6921). * Bring value when you send a message. Do not seek value. Value-seeking questions such as, What are you doing tonight? make people sound too needy and also fail to inspire any emotion in the person whom they are communicating with. * Avoid sending too many messages. This is meant to keep someone who is interested in a person from sounding too desperate or like they have no reason to live other than to send messages. * Keep it simple, stupid. The whole point of communicating with a person is to make the person get the point without being long-winded, which can be boring. Regards, -sm
team to look at diversity
I have an update relating to the diversity discussions we've had on the list and at IETF-86. I promised that I'd set up a design team. I have found two people to lead such a design team: Kathleen Moriarty and Suresh Krishnan. Thank you volunteering to lead this! Please contact them if you are interested in contributing to the work. I have given them an open assignment, with a desire to get advice on what steps we could take to increase participation in various aspects of the IETF, hoping for some initial advice before the next IETF. The leaders will determine how they want to run the team and who to select to it, but the writeup below is my input for setting the stage and some scope for the work. The design team will present their recommendations to the community, and engage in the discussion. Recommendations with community support will be taken forward. The creation of this team should not stop other efforts or proposals from going forward. For instance, there is an independent effort in looking at improvements in mentoring. Jari Arkko - For the purposes of this team, we think of diversity as something that covers international participation, different cultures, gender, age, organisational background, and so on. While the IETF has become a very international organisation (with participants from 60 countries working on documents, for instance), there are many aspects of diversity where we could do much better. Overall participation is concentrated in some areas of the world, with little participation from Africa and South America, for instance. Similarly, while the IETF has some very active female participants and leadership members, the numbers are very small. Much of the work in the IETF is driven by large networking companies, yet academia and small companies would have more to give, and operational experience from additional operators would be similarly appreciated. Importantly, these disparities appear most prominently in our leadership, where institutional and structural issues can lead to even less diversity along all of the above mentioned axes than in our general population. All organisations benefit from a healthy influx of new participants at all levels, and in the IETF we need that to balance our well-established topics and participants, to build the next generation technologies, experts, and leaders. These issues are of course related to general engineering and industry issues, and are a source of discussions in other similar organisations. But we should not attempt to show how we match or do not match the general patterns. We should rather just make the observation that additional diversity would be beneficial to IETF and improve its results. The diversity team is a design team tasked with understanding the issues we are facing, drawing in experience from other organizations affected by similar issues, identifying obstacles to us having the widest breadth of talented participants and leaders, and making practical recommendations that could help us improve the situation. It is understood that many improvements may only take effect long-term, such as drawing in more participants from areas of the world where the IETF has traditionally not had much participation. Nevertheless, a set of actionable steps would be useful. The diversity team is not charged with evaluating the particulars of current or past Nominations Committee (Nomcom) decisions, and any discussion of ongoing NomCom activities is out of scope. The NomCom is expected to continue to do its utmost to recruit and appoint a top-notch and well-rounded set of people to our leadership. The diversity team will make recommendations on actions we can take going forward, both to increase diversity of IETF as a whole, and to help future NomComs (and other bodies selecting people) address issues of diversity in our leadership.
Re: draft-guo-idoca-with-the-html-file-format-00
Dear Mr. Guo, This I-D is a good idea. It is the first time I hear about the idea of IDOCA (Interconnection and Interoperability of Cloud-Office Application) with the html file format. If this idea comes true, it will be beneficial to all cloud-office user. However, the problem of security will arise with the interconnection and the interoperability, but the solution for it is not specific in this I-D. Maybe deeper discusses need to be made. Kun
Protocol Action: 'ForCES Logical Function Block (LFB) Library' to Proposed Standard (draft-ietf-forces-lfb-lib-12.txt)
The IESG has approved the following document: - 'ForCES Logical Function Block (LFB) Library' (draft-ietf-forces-lfb-lib-12.txt) as Proposed Standard This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ Technical Summary This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. Working Group Summary: Standard WG discussions, nothing controversial. The document was returned to the authors after AD review. The issues were addressed in public on the WG mailing list. Document Quality: There are known implementations of this document. Version 00 of this document was published in 2009 and has undergone feedback based on implementation and architecture discussion. Personnel: Jamal Hadi Salim (h...@mojatatu.com) is the Document Shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note The three unused references may be safely removed.
Last Call: draft-ietf-sipcore-sip-websocket-08.txt (The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)) to Proposed Standard
The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)' draft-ietf-sipcore-sip-websocket-08.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-04-15. 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 The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document normatively updates RFC 3261. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ballot/ No IPR declarations have been submitted directly on this I-D.
SUBJECT: UPDATED I2RS Working Group Interim Meeting April 22-23, 2013
A note from the I2RS Chairs regarding the Interim Meeting being held April 22-23, 2013 in Sunnyvale, CA: We've put up a registration page for the I2RS interim meeting at: http://i2rs-interim.eventbrite.com You must register in order to be able to attend. The cut off date for registration will be on April 17, 2013. Cheers all, and hope to see you there. best, -Ed and Alia On Mar 25, 2013, at 5:30 AM, IESG Secretary wrote: I2RS WG Interim Details Dates/Times: 22-23 April 2013 (9:00 am - 5:00 pm PDT) Location: Mountainview or Sunnyvale, California (hosted by Google or Juniper) Registration: For planning purposes only. Remote Participation: via Webex Please see the I2RS mailing list for further details and agenda.
RFC 6919 on Further Key Words for Use in RFCs to Indicate Requirement Levels
A new Request for Comments is now available in online RFC libraries. RFC 6919 Title: Further Key Words for Use in RFCs to Indicate Requirement Levels Author: R. Barnes, S. Kent, E. Rescorla Status: Experimental Stream: Independent Date: 1 April 2013 Mailbox:r...@ipv.sx, k...@bbn.com, e...@rtfm.com Pages: 6 Characters: 11076 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-barnes-2119bis-00.txt URL:http://www.rfc-editor.org/rfc/rfc6919.txt RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words MUST (BUT WE KNOW YOU WON'T), SHOULD CONSIDER, REALLY SHOULD NOT, OUGHT TO, WOULD PROBABLY, MAY WISH TO, COULD, POSSIBLE, and MIGHT in this document are to be interpreted as described in RFC 6919. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
A new Request for Comments is now available in online RFC libraries. RFC 6921 Title: Design Considerations for Faster-Than-Light (FTL) Communication Author: R. Hinden Status: Informational Stream: Independent Date: 1 April 2013 Mailbox:bob.hin...@gmail.com Pages: 7 Characters: 15100 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-hinden-FTL-design-considerations-00.txt URL:http://www.rfc-editor.org/rfc/rfc6921.txt We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
