RE: [Sdn] FW: Last Call: draft-sin-sdnrg-sdn-approach-04.txt (Software-Defined Networking: A Perspective From Within A Service Provider) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Linda Dunbar - We all understand the challenges of Full Automation. However, the SDN and Full automation are two separate angles to Carrier networks. I find the Section 4.1 Implications of full automation actually de- rails the focus of the draft on SDN. [WEG] I strongly disagree. First, we all understand... is an overgeneralization, and a dangerous and grossly inaccurate one at that. Lots of SDN vendors have repeatedly demonstrated to me how little they actually understand about this problem. It's not a new problem by any means, but there's a really significant amount of hand-waving going on around the complexities of actually doing what they're saying is possible through the magic of SDN, when few have demonstrated how the abstract concept SDN actually makes solving this problem easier. The reality is that SDN and automation are inextricably linked. The next to last sentence in section 2.3 reinforces this, and I believe that 4.1 is absolutely appropriate for this draft. A truly software-defined network is an automated one, and any discussion of an operator's perspective on SDN is going to need to consider the same challenges that have been present in prior attempts to better automate network management, provisioning, and control. There are two models for managing a network like this, one that is fully automated, meaning that it is quite a lot more complex and susceptible to ghost in the machine problems, the other which has a human making most of the important decisions and then dictating those to the network. Even the latter model requires a significant amount of automation to execute what the human has decided should be done. The things covered in section 4.1 mirrors a lot of the discussion that I have had both internally and with other operators around the challenges of separating the hype of SDN from the actual benefit, and in selling this model to operations folks who are skeptical of ceding control to a set of computer logic. 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.
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush how about To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router may not validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. [WEG] fine, though it's unclear if may in the above is intended to be normative. I think it's not, but just pointing it out. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One also should consider trust boundaries, routing bootstrap reachability, etc. E.g. a router should bootstrap from a chache which is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. [WEG] this is better, but I still maintain that in the first sentence, close isn't actually the goal we're trying for. How about: ...operators SHOULD consider the relationship between the routers that require these data and services and the location of the RPKI caches in the network's topology. Caches SHOULD be located so that they can take advantage of geographic redundancy and minimize the impact of likely failures in local routing, And add this at the end to explain why reliance on routing protocols @ bootstrap is risky: ...or routing protocols. Reliance on routing protocol convergence to reach a cache at bootstrap time can result in significant increases in total convergence time as the router converges partially, synchronizes with the RPKI cache, and then must re-converge based on the data from the cache. Thanks Wes 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.
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: Randy Bush [mailto:ra...@psg.com] i don't even know what geographic redundancy is, alternate earths? [WEG] nah, the latency is too high until we sort out IP over Quantum Entanglement. ;-) Geographic redundancy in the context of things that live on servers is that it exists on servers in more than one physical location (e.g. Datacenter East and Datacenter West) so that there isn't a single point of failure. In this case, that'd probably be in the form of two caches backing each other up (router configured to use both). if you mean redundant network topology, i think it is more than that. i really think physical line length matters. as i said, the longer the circuit the more likely a boat anchor will whack it. hence close. [WEG] yes, but ultimately that's dependent on your network topology. If close is the only way to mitigate that (vs having a truly redundant backup that doesn't share any topology in its path), then sure, that's what you do. But I don't think it directly translates to should be close. We clearly disagree, but I'm not going to belabor the point any further. i think i understand what you want made more explicit. today's try To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router can not validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One should also consider trust boundaries, routing bootstrap reachability, etc. E.g. a router should bootstrap from a chache which is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. For example, if a router needs its BGP and/or IGP to converge for the router to reach a cache, once a cache is reachable, the router will then have to reevaluate prefixes already learned via BGP. Such configurations should be avoided if possible. [WEG] close enough, ship it. Wes 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.
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: Randy Bush [mailto:ra...@psg.com] are you really saying that i should be comfortable configuring a seattle router to use a cache in tokyo even though both are in my network and there is a pretty direct hop? [WEG] not necessarily. But I'm also not saying that there would *never* be a scenario where that makes sense. i am willing to hack the text. but i am just not sure that proximity is not a good attribute. the longer the wire the greater the likelihood of it being cut. [WEG] Proximity is generally a good attribute, but it's not free, so help the reader understand the tradeoffs so that they can justify spending money to get better proximity. The draft hasn't provided a good explanation of how proximity improves RPKI (or what problems a lack of it creates), nor how to determine whether the level of proximity in a given design is good enough to provide the perceived benefit. Your statement about long wires being cut is an argument for redundancy and geographic diversity, not proximity. Of course an operator needs to take into account the topology of their network when considering geographic diversity, but that's not necessarily going to translate to a need for proximity. The draft says one should consider latency, but never explains how increased latency impacts RPKI, nor gives any guidance on how much might be too much, especially when one considers that RPKI is an asymmetric system that changes on mostly human time-scales (order of hours or days). Most places where latency matters, it's a function of what RTT does to throughput or the perception of speed for interaction (how long it takes between when I click and when something happens). This isn't an interactive system. What is latency-sensitive in this system on the subsecond scale such that it can be affected by moving the cache closer? Even on systems configured for very frequent synchronization, are we expecting anything to change on that timescale? See my other response to CMorrow for questions around bootstrapping. Wes 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.
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] [CLM] In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem', balanced with 'gosh, maybe I don't want to put one on top of each router! plus associated management headaches to deal with these new systems/appliances'. [WEG] that's part of my issue - the only way that you get close enough that bootstrapping isn't a problem is when the cache and router are directly connected. Otherwise there *is* going to be some amount of time while the router is coming up that it can't talk to its configured caches e.g. while it learns the route(s) to the cache(s). I think that supports a recommendation to put the caches in your IGP instead of BGP, so that you get faster convergence of those routes and therefore have access to the cache when BGP comes up and starts converging, rather than once BGP is partially converged. But the draft doesn't say that. The question is, does the propagation/convergence delay for an IGP in an average network (let's call it somewhere between subsecond and 5 seconds) make a non-trival difference in RPKI's bootstrap behavior, especially since BGP convergence is also dependent on IGP convergence? Can we make a clearer recommendation of the performance envelope we're shooting for so that people can design accordingly? I'm not sure I buy a general faster(or closer) is always better recommendation - at some point, we hit diminishing returns, given that this is mostly a human time-scale system. The document doesn't provide clear guidance on how to balance that tradeoff. [CLM] I guess one way is to say: People should understand the dependencies and engineer appropriately ... which you kind of asked to not say in the original comment. (or is the issue that the dependencies aren't clear?) [WEG] The issue is that the dependencies aren't clear. I'm not expecting the text to be too prescriptive here, because all networks are different, but I need enough technical discussion to properly understand the dependencies and engineer accordingly. This is an operational considerations document, so it needs to tell operators what breaks if they don't do it as recommended. If this is about bootstrapping, then we need to be clearer about the relationship between bootstrapping and network convergence (since recommending that the cache is directly connected to the router is impractical) and how it impacts RPKI cache-router communication and performance. If it's about reducing latency via proximity, then we need to explain how much latency is too much latency and why. If it's about proper geographic diversity within a network's topology, then we need to say that. If we don't actually know if it makes a difference, and so are defaulting to recommendations that most folks agree are generally a good idea, we should say that. But right now we're assuming too much, IMO. Wes 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.
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: Randy Bush [mailto:ra...@psg.com] i think the two paragraphs you would like to see improved are [snip] i am not against further explanation, send text. but short text. :) [WEG] just the first paragraph really, and as I'll note below - I'd love to send text, but I don't understand one of the recommendations experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. [WEG] ok, so why is close important then? i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? [WEG] yes, completely obvious. Though the last two sentences of your suggested text in the other email is a useful addition what is missing from the second paragraph? [WEG] I'm actually happy with second para i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. [WEG] Generally, I understand why closer is better for content caches (Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between the two that I'm not following. Both of the former benefit from proximity because it reduces latency and reduces unnecessary backhaul and potentially allows for a geographically customized service, resulting in improved user experience. If latency isn't a factor (at least in the average-sized propagation domain), and RPKI caches aren't particularly bandwidth intensive, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending close because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. Thanks 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.
RE: Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
I've reviewed multiple iterations of this draft, and I believe it is mostly ready to go. However, the concerns I raised during WGLC in http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html regarding the ambiguity of some of the guidance regarding location of RPKI caches (close) in section 3 still have not been addressed. IMO if it is important enough to discuss proximity, it is important enough to devote some words to explaining the rationale for that recommendation so that operators can make an informed design decision. Thanks, Wes George -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, September 17, 2013 10:52 AM To: IETF-Announce Cc: s...@ietf.org Subject: Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI-Based Origin Validation Operation' draft-ietf-sidr-origin-ops-21.txt as Best Current Practice 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-10-01. 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 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/ No IPR declarations have been submitted directly on this I-D. 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.
RE: [Int-area] Last Call: draft-ietf-intarea-flow-label-balancing-01.txt (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC
I've reviewed this draft, and have one substantive comment: I think within the operational considerations (and possibly the info model), you need some discussion of diagnostics and troubleshooting, both for on-box and off-box implementations. How do I see that it's working properly, and how do I diagnose problems when it's not? One of the problems with the existing hashing algorithms is that they are often opaque, such that it's not clear what the device is doing, whether the hashing is working properly and the flows are of the sort that create imbalanced distribution, or whether hashing has broken somehow -- occasionally you can get info, but it's usually hidden commands, with difficult-to-interpret responses, and it's not like most vendors publish their secret sauce optimizations of hashing so that it's easy to predict what will happen given a certain set of flows. In order for this to be operationally manageable, especially in the case of on-router processing of this rebalancing, there has to be an easy way for the operator to access the information about what's happening - what the result would be if the flows were balanced according to the hash vs what is happening as a result of rebalancing, so that they can chase down things like rebalancing misses or situations where this local optimization is creating a problem elsewhere in the path because that device did something different in its attempts to balance better, etc. It may also be that this info is necessary to properly tune the frequency of sampling, the thresholds for things like long-lived vs short-lived flows, etc. to the specific network where it is being used. I realize that in the model you've proposed, we're somewhat limited because this is using sampled flow data instead of the realtime packet hash. It may be that this drives a requirement for the granularity of data being brought into the system in the external mode, and some requirements about the level of information available via the UI (or SNMP or XML or whatever) in the automatic hardware-based mode. Thanks Wes George -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, September 16, 2013 9:43 AM To: IETF-Announce Cc: int-a...@ietf.org Subject: [Int-area] Last Call: draft-ietf-intarea-flow-label-balancing- 01.txt (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Using the IPv6 Flow Label for Server Load Balancing' draft-ietf-intarea-flow-label-balancing-01.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. 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 describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- balancing/ballot/ No IPR declarations have been submitted directly on this I-D. Anything below this line has been added by my company's mail server, I have no control over it. - 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.
RE: [Int-area] Last Call: draft-ietf-intarea-flow-label-balancing-01.txt (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC
Please disregard, these comments are intended for draft-ietf-opsawg-large-flow-load-balancing-05. I replied to the wrong thread. Sorry for the spam. Thanks, Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of George, Wes Sent: Monday, September 16, 2013 11:49 AM To: ietf@ietf.org Cc: int-a...@ietf.org Subject: RE: [Int-area] Last Call: draft-ietf-intarea-flow-label- balancing-01.txt (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC I've reviewed this draft, and have one substantive comment: I think within the operational considerations (and possibly the info model), you need some discussion of diagnostics and troubleshooting, both for on-box and off-box implementations. How do I see that it's working properly, and how do I diagnose problems when it's not? One of the problems with the existing hashing algorithms is that they are often opaque, such that it's not clear what the device is doing, whether the hashing is working properly and the flows are of the sort that create imbalanced distribution, or whether hashing has broken somehow -- occasionally you can get info, but it's usually hidden commands, with difficult-to-interpret responses, and it's not like most vendors publish their secret sauce optimizations of hashing so that it's easy to predict what will happen given a certain set of flows. In order for this to be operationally manageable, especially in the case of on-router processing of this rebalancing, there has to be an easy way for the operator to access the information about what's happening - what the result would be if the flows were balanced according to the hash vs what is happening as a result of rebalancing, so that they can chase down things like rebalancing misses or situations where this local optimization is creating a problem elsewhere in the path because that device did something different in its attempts to balance better, etc. It may also be that this info is necessary to properly tune the frequency of sampling, the thresholds for things like long-lived vs short-lived flows, etc. to the specific network where it is being used. I realize that in the model you've proposed, we're somewhat limited because this is using sampled flow data instead of the realtime packet hash. It may be that this drives a requirement for the granularity of data being brought into the system in the external mode, and some requirements about the level of information available via the UI (or SNMP or XML or whatever) in the automatic hardware-based mode. Thanks Wes George -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, September 16, 2013 9:43 AM To: IETF-Announce Cc: int-a...@ietf.org Subject: [Int-area] Last Call: draft-ietf-intarea-flow-label- balancing- 01.txt (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Using the IPv6 Flow Label for Server Load Balancing' draft-ietf-intarea-flow-label-balancing-01.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. 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 describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- balancing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- balancing/ballot/ No IPR declarations have been submitted directly on this I-D. Anything below this line has been added by my company's mail server, I have no control over it. - 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. This E-mail and any of its attachments may contain Time
RE: [sidr] Last Call: draft-ietf-sidr-bgpsec-threats-06.txt (Threat Model for BGP Path Security) to Informational RFC
I've reviewed this document and have some comments. First, an apology, because although I'm an active participant in the SIDR WG, I'm pretty sure I missed the WGLC on this, so these comments shouldn't necessarily be construed as me taking my argument to ietf@ietf because I felt that SIDR ignored my concerns. Now, my actual comments: Maybe I'm hypersensitive to such in light of recent accusations of national actors subverting supposedly secure infrastructure to behave badly, but I find it odd that this threats document doesn't discuss the interaction between a national actor and the machinery provided by draft-ietf-sidr-ltamgmt. i.e. a national actor imposes upon SPs that operate inside their borders to use their own Local (and compromised) Trust Anchor to subvert the protections provided by RPKI. While this is primarily a concern for origin validation, I view it as distinct from the existing discussion of attacks on a CA covered in 4.5, and there is no equivalent Origin Validation threats document. It may be that the right path is to augment the discussion of this issue in the LTA management draft, and simply reference it from this draft, but I don't think that this is discussed suitably in the security considerations of either draft. Section 4.2 is missing any discussion regarding manipulation of other route attributes that may be used to affect a BGP route's selection, such as MED, Local Pref. It's covered in section 5, but since this occurred to me whilst reading section 4.2, perhaps some mention in 4.2 would be useful, I don't know. That said, I also think that the discussion of this topic at the end of session 5 is inadequate for a document in IETF LC. The SIDR WG made a conscious decision to secure *only* the AS_Path attribute, and leave other attributes insecure, but there is no summary of the underlying rationale supporting this choice. Pointing to a WG charter as the sole explanation, and noting that this document should be changed if the charter is updated is unacceptable, as it provides no context to a reader that was not privy to the discussion leading to that charter/scope decision. It also makes reference to something fairly ephemeral (a WG and charter) in a permanent document. Fine for a draft in WG discussion to have that sort of placeholder, but not anymore. There is a brief (and IMO incomplete) discussion of this matter to be found in section 2.3 of draft-sriram-bgpsec-design-choices that could be referenced, but since that document's future is unclear, some standalone discussion within this document might be more appropriate. At a minimum, a threats document should discuss why these threats are not considered high enough risk to justify the added complexity of securing them using the RPKI. Thanks, Wes George -Original Message- From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, September 09, 2013 6:26 PM To: IETF-Announce Cc: s...@ietf.org Subject: [sidr] Last Call: draft-ietf-sidr-bgpsec-threats-06.txt (Threat Model for BGP Path Security) to Informational RFC The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Threat Model for BGP Path Security' draft-ietf-sidr-bgpsec-threats-06.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-23. 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 describes a threat model for the context in which (E)BGP path security mechanisms will be developed. The threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP [RFC4271], consistent with the inter-AS security focus of the RPKI [RFC6480]. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in [RFC4271]. It concludes with brief discussion of residual vulnerabilities. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. Anything below this line has been added by my company's mail server, I have no control over it. - This E-mail and any
RE: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
+Bruce Schneier (at least the email address published in his latest I-D), since he should be at least aware of the discussion his callout has generated. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ted Lemon On Sep 5, 2013, at 8:46 PM, Lucy Lynch lly...@civil-tongue.net wrote: I'd like to share the challenge raised by Bruce Schneier in: I thought it was a great call to action. Is Bruce coming to Vancouver? [WEG] Sounds to me like he just volunteered to be the keynote for the Tech Plenary. Wes George Anything below this line has been added by my company's mail server, I have no control over it. - 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.
RE: Sunday IAOC Overview Session at the Berlin IETF
The IETF Administrative Oversight Committee (IAOC) will hold a session from 1500-1650 in Potsdam 1 at the Berlin IETF on Sunday July 28, 2013. The purpose is to provide an overview of the IAOC to allow the community to better understand what the IAOC does, how the finances work, venue selection, and provide the IAOC feedback on the job they are doing. [WEG] After Orlando, there was feedback from multiple folks (myself included) requesting that this session *NOT* be scheduled opposite the Newcomers' meet and greet, since that means that most of the folks who might want to see this but have leadership/mentorship duties must leave the session early. Could this be moved to the earlier time slot? If not, can you at least do the content in the reverse order from the Orlando session so that between the two, those who have to leave after an hour have a mostly complete view between this session and the previous one? Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. - 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.
RE: Regarding call Chinese names
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore I agree that this is probably not appropriate for publication as an RFC but it would certainly be useful to find someplace for it in the wiki. The chairs wiki might be an option but I think it's of broader interest and use. Melinda [WEG] I think writing language documentation isn't really a good use of IETF resources, even at an individual level, because neither the problem nor the knowledge necessary to address it is specific to the IETF, nor is the problem limited to Mandarin participants. As others have noted, this is just one of many languages represented by IETFers that we'd have to treat similarly. Further, an I-D is not a particularly useful format in which to present the info. Raw text in the form of $phoneme as in $English_word may not always be helpful, especially to nonnative English speakers who now have to work through two layers of pronunciation. Being able to click on a button to hear sample pronunciations, especially in the case of words where tones matter, is very helpful. So if pronunciation guides end up in the Wiki or the Tao or some other yet to be written Diversity and Cultural guide hosted within IETF, I think it's more useful to simply reference things already extant instead of generating our own. Those representing the language in question could certainly help us to source and vet the information, but that's much quicker and more efficient than writing it themselves. Protocol reuse, hurray! :-) e.g. http://mandarin.about.com/od/pronunciation/a/How-To-Pronounce-Mandarin-Chinese.htm http://en.wikibooks.org/wiki/Japanese/Pronunciation http://en.wikipedia.org/wiki/Swedish_phonology To be clear, I'm not saying that this doesn't expose a real problem, and the draft certainly drew attention to it, but I also don't think that more documentation will solve it, especially since the information is already readily available in more accessible formats. I think what you'll find is that there are two types of folks (in IETF and generally) - those who see an attempt at proper pronunciation and cultural awareness as important and worth making extra effort to learn proactively, and those who believe that if it's an issue, the person on the receiving end will correct them when they get it wrong (and hopefully not repeat the mistake). Not making a value judgment on either, merely an observation. Thanks Wes George PS: guess which one is my given name and which my surname? Even native English speakers aren't immune from name confusion. :-) Anything below this line has been added by my company's mail server, I have no control over it. - 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.
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.
RE: Martians
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Spencer Dawkins At least some of the nerdier nerds were probably thinking how could *I* become a Martian? because that would be so cool! ... [WEG] followed immediately by a complaint thread on this list asking why IAOC hasn't yet found a suitable meeting venue on Mars to encourage better participation in the IETF by Martians. 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.
RE: Nomcom Reports
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mary Barnes I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? While this is not listed as a requirement in RFC 3777... [WEG] Yes, and Yes. However, looking at this as an outsider based just on your report and the thread that caused you to send this email, we have a larger fault, in that it appears that no one in I* is taking ownership of the problems identified. We'd be in a bit less of a crisis mode right now if someone had gotten out ahead of this problem, which says to me that we may need an update to 3777 to require both this report *and* a formal response by I* orgs to any issues identified in said report, even if it is just to take this to the community for discussion and suggestions when the problem is identified, rather than after we've already tripped over it. Thanks for sending this out 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.
RE: Difficulty finding ADs (was: Appointment of a Transport Area Director)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Benoit Claise Recently, for a single draft, I spent hoouuurrr trying to track all the open issues from the directorates and the IESG, and chasing the authors. [WEG] While I realize that Benoit was originally speaking to the need for subject matter expertise, this comment also says to me that we are not doing a good enough job providing the tools that IESG needs to be as efficient as possible with their time, which when combined with the increased volume of work in IETF is leading to the borderline unsupportable time commitment. I therefore echo the suggestion that IESG should be charged with identifying actionable ways to make their jobs easier. I suggest that they set up a meeting, perhaps a half or full day with the full IESG, but also at least part of the day should be open to any interested former IESG members, plus perhaps secretariat, RSE, and tools team representatives. This group would discuss what improvements to process, workflow and tools are needed to make the IESG job easier by offloading some of the administrative overhead. The end result of that would be an internet-draft to track the suggestions and give the community an opportunity to provide additional suggestions and get some consensus behind it before some or all of the suggestions are put into motion. 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.
RE: Internet Draft Final Submission Cut-Off Today
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott Kitterman Sent: Tuesday, February 26, 2013 10:42 PM To: ietf@ietf.org Subject: Re: Internet Draft Final Submission Cut-Off Today How does that relate to working groups that aren't meeting? [WEG] Signal to noise ratio. I (and I assume others) use the IETF's RSS feed to see all new drafts when they are posted. This is in order to have a fighting chance to see drafts I might care about that happen in WGs that I am not an active participant in, both to help me see if there are other WG lists I need to subscribe to or if there are meetings I should attend as a tourist, or direct feedback to the authors prior to IETF LC. New drafts posted for WGs that aren't meeting (and while I'm at it, throwaway placeholder -00 drafts with no content) help contribute to the crush of drafts to sift through, because it's not readily apparent based on the RSS summary or the draft itself whether the WG is meeting. Add me as one more +1 in support of a quiet period to give me a chance to catch up on draft review before the meeting. It was silly I had to rush to post a draft on Monday for a WG that's not meeting. [WEG] Yes it was silly you had to rush, because if the WG isn't meeting, there's no reason why you couldn't have simply waited until after the moratorium elapsed, or posted it well prior to the inevitable rush of work that precedes every meeting. Though alternatively it should be possible to have the system continue accepting submissions and only make them public at the expiration of the posting moratorium. 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.
RE: Fwd: I-D Action: draft-barnes-healthy-food-06.txt
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM In Section 5: For cases of first time attendees for a specific location, relevant information can be gathered from attendees that have previously visited the city. There are recurrent discussions as nobody volunteered to gather that information in one place. [WEG] Perhaps a model similar to RFC 6640 would be appropriate - having this draft explicitly recommend use of a wiki or other semi-permanent method to store and share information collaboratively about specific locations' healthy/restricted diet options based on past experience. It could probably be a persistent subsection of the IETF meeting wiki, or it could just as easily be a pointer to a non-IETF-specific external website that is set up with precisely this goal (helping travelers with special dietary needs meet their requirements in strange cities) in mind. 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.
RE: presenting vs discussion in WG meetings (was re:Remote Participation Services)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Crocker Sent: Tuesday, February 12, 2013 12:06 PM To: ietf@ietf.org Subject: Re: Remote Participation Services [WEG] changed subject line to reflect actual topic If a meeting has good structure, management and content, the presence or absence of slides doesn't matter. [WEG] Perhaps it would be helpful to make an informal recommendation to WG chairs (via the wiki, for example) that generally they should carve each request for agenda time roughly in half, with a hard limit of $speaker_time/2 devoted to presenting or otherwise framing the discussion and the remaining time devoted to open mic discussion. Likely this will result in presenters asking for 2x their previous time, but at least it will be a more realistic method to plan out time during a meeting and reduce the instances where the WG will be running short of time for meaningful discussion if the presenter (or WG chair) isn't good at managing the available time and spends the whole allocation reading slides to the people in attendance. 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.
RE: A mailing list protocol
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of S Moonesamy (b) replies to messages which use an odd quoting style [2]. 2. http://home.in.tum.de/~jain/software/outlook-quotefix/ [WEG] The referenced program doesn't work for anything 2007 or later (aka versions still supported by MS), making it of limited use. Is there an IETF standard format for handling inline quote replies? Is it just not implemented in certain mail clients? If there isn't a relevant standard, then we have no business whining that people are doing it wrong, and we should probably get to work defining one, either for use on the client side, or possibly an extension for common mailman software to parse and fix it on the server side to compensate for odd client implementations. The last thread that talked about how to do email correctly focused on the usual bashing of those using outlook or company email addresses, rather than much in the way of helpful advice on how to make it less bad. [ https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=64911tid=1354657596 ] Browbeating people into changing mail clients will be less than effective, but something that systematically makes it easier to see who is responsible for what comment in a multi-person thread regardless of source email client would be welcome. While we're at it, we could maybe implement a fix for the common problem of mangled subject lines that make it very difficult to sort by thread, and add a server-side filter that removes the legal bilgewater automatically added to some outgoing messages (example will follow in this very message) before sending it to the rest of the list recipients, etc. I'd support a draft of that nature, but rehashing an old draft about nettiquete 101 is less helpful. A simple reference to the original in the Tao webpage would probably be sufficient to get the behavioral point across, and then we can focus more on the technical problem that we appear to have. 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.
RE: Useful slide tex (was - Re: English spoken here)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore it's kind of weird that we cut off discussion so that we can proceed to the next presentation. It's done all the time (I've done it, myself) and while there's definitely a sense that we need to cover the material we've said we're going to cover in a meeting, why does breadth take priority over depth? [WEG] I think this requires making a judgment call between a ratholed discussion, or an impasse between two strongly held opinions vs. meaningful progress. Sometimes the former and the latter masquerade as each other and are therefore mishandled. Again, comes down to how the meeting is structured - do you prioritize a set of current drafts that need to have meaningful discussion, and accept the fact that presentations on new work might lose their timeslots if discussion runs long? I think that's an acceptable risk, especially since anyone who is technically on the agenda can build a presentation and have it be in the proceedings so that people can review after the meeting. I know I had more than one meeting where there were many valuable presentations, and a large number of them were added to the agenda with zero minutes allocated, so that they'd be ready if we had time to discuss them during the meeting once the priority discussions were completed, but also so they'd be in the proceedings when we didn't. 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.
RE: Useful slide tex (was - Re: English spoken here)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore A different toolset, (e.g. pens and paper and overhead cameras coupled to projectors), would likely produce better results if that toolset did not encourage laziness in preparing materials to facilitate discussion. [WEG] I don't know about anyone else here, but you do *not* want me to attempt to facilitate a discussion using freehand drawings and writing. My handwriting and drawing skill was bad before I discovered a keyboard, and years of atrophy have made its usefulness approach zero as a meaningful method of communication. You'd be better off with the aforementioned stone tablets and cuneiform in terms of understanding. http://theoatmeal.com/blog/handwriting And I echo what Dave said - quit blaming the tools and assuming that forcing people to use tools they're not used to using will fix this. You have a very specific opinion of what an effective WG session should be like and what people should and should not be doing to facilitate such. Sounds like you need to work with the EDU team to give a Sunday afternoon training session entitled how not to turn a WG session into a broadcast-only medium possibly with a section for WG chairs and a section for potential speakers. 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.
RE: Useful slide tex (was - Re: English spoken here)
From: Keith Moore [mailto:mo...@network-heretics.com] Years ago, my impression was that that Sunday training sessions were pretty much ignored by anyone experienced in the organization. Is this still the case? [WEG] Depends on the subject matter. If they're all targeted at new attendees, it follows that no experienced attendees would be interested. At 5 years in, I guess you could call me experienced in the organization, and I attended one during IETF84 about crypto and security. 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.
RE: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore I'm not very clear on what problem you're trying to solve, or why it's a problem. I've seen some stuff around working group draft adoption that I don't like very much but am not sure that I'd identify those as a problem, per se, or that they would be done better with yet another process document. [WEG] My original message simply notes that this is the 3rd or more time in my recent memory that there has been a serious question within some part of the IETF about when in a document's lifecycle and maturity is the right time to adopt it as a WG document, and whether it is appropriate to discuss an individual document in a WG at any length without adopting it. It seemed odd to me that there would be this much confusion on the matter, and I provided several examples of different philosophies that I have observed when it comes to handling this question. The response I got back indicated that WG adoption of drafts isn't really a thing as far as the official documentation of document lifecycle is concerned, which made me wonder if perhaps we do as much WG adoption of drafts as we do mainly out of inertia, either people doing it because that's how they've seen others do it in the past, or doing it because they assume it's part of the documented process, rather than for any real reason. I'm not a big fan of doing things for no reason, so the ensuing discussion was intended to tease this out a bit to see whether we should have some clearer guidelines around WG draft adoption, better education on the reasoning behind it, or whether maybe we should stop doing it. Is it the largest problem facing the IETF? Not by a long shot. But it seemed worth a little discussion, at least to me. Process we just don't happen to like is not a problem. [WEG] process we don't happen to like because it adds no value or confuses people or wastes time is very much a problem. But I didn't bring this up because I didn't like the process, I brought it up because I was seeking a little clarity on the underlying reasons we use the process (at least partially to improve my own knowledge as a WG chair and draft author). Thus far that clarity has still not presented itself. 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.
RE: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)
From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of Barry Leiba There is no formal process that involves adopting anything. Working group chairs appoint document editors (this is in RFC 2418, Section 6.3). There is nothing anywhere that specifies how the first version of a WG document is formed. [WEG] snip We seem to have settled into a culture of starting with individual submissions and adopting them, but there's nothing that requires that [WEG] What this says to me is that we are adhering to an ad hoc or de facto process, and therefore in most cases we're not really thinking about why we do it, or even if we should, we're just going with the flow of past precedent. AKA, that's the way we've always done it/that's just the way we do things around here. We wouldn't do that with a technical protocol that we defined, we'd update the standard to reflect reality as implemented. So why are we behaving differently with our internal protocol? If it works and people like it, let's document it so that it can be applied consistently. If people think it's unnecessary and we should stick to the documentation as written (no adoption), let's do that. If we actively *don't* want an IETF-wide procedure here, we can even document that the process for WG adoption of drafts is WG-specific and could document those specifics in a WG policies wiki document maintained by the chairs. There are plenty of WGs that have specific ways that they like to handle document submission, reviews, and requests for agenda time. It might be useful to have that all in one place so that people can know what's expected of them. So, yes, the chairs get to decide how they want to seed the document development process, and they have a pretty free hand in making that decision. Your ADs are always there for further guidance if you need or want it. But there's no formal process for that, and I think that's how we want it to be. [WEG] Barry, I respectfully disagree. The whole point I'm making here (and Geoff underscored nicely) is that it's currently too variable and too reliant on a small group of individual volunteers implementing it correctly. When things are not documented, we are dependent on having leadership who innately know how to do the right thing. But that leadership turns over fairly frequently. so assuming that we'll always have people in leadership who know how to make this process work correctly without some guidance is pretty risky, IMO. As the IETF ages and grows, and personnel (participants and leaders) turn over, the oral tradition breaks down in a hurry. Further, no matter how good the individuals are at their jobs within the IETF, applying undocumented policy (especially doing it inconsistently) looks to the outside world as arbitrary and capricious, or as centralizing authority, and that's not at all productive in an open standards development process. It can be discouraging to new participants, because it contributes to the overwhelming nature of figuring out how to get started as a new document author, and it can make the process seem more closed than it actually is. It is quite possible to document a policy or procedure with directional guidance and enough flexibility to allow intelligent adults to think for themselves and adapt to the reality of the situation during implementation. I'm willing to work on an update to 2418 to cover this apparent gap, but I'd like to know whether others agree that this is a problem (and are willing to work on the update with me). 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.
RE: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)
From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of Barry Leiba we have a million things that are unspecified and should be unspecified and left to management choice. Trying to find all of those and explicitly say so will be a frustrating exercise, and one that won't have a lot of value in the end. In general, we specify what we want to specify, and what's left is up to judgment and management. [WEG] I'm sorry if it was unclear, but I am not saying that *everything* must be specified, nor do I think anyone should undertake an effort to even identify all of the things that are currently unspecified. I'm pointing out a specific area of confusion and inconsistency that has been created by something that is unspecified and asking should we specify? Further, no matter how good the individuals are at their jobs within the IETF, applying undocumented policy (especially doing it inconsistently) looks to the outside world as arbitrary and capricious Here's where we have a gap, you and I: what you call undocumented policy I call a management choice. [WEG] that's not really a gap, especially because you can replace my words with yours and the statement above still holds. I am saying is that there is an inconsistency because different people are making different choices on how to proceed, hopefully with the consensus of the WG behind them. IMO, the inconsistency goes beyond merely being flexible to accommodate the widest variety of cases, and adds confusion and variability to the process. I think the gap arises from the fact that you do not see this as inconsistent or that you do not see the inconsistency as a bad thing. It may not be bad in all cases, but I think there's a middle ground between overcreation and overapplication of rules and relative anarchy. I'm just trying to make sure we're actually in that happy medium, and that this is indeed the result of a conscious decision rather than simply imitating what we see in other WGs because that seems to work. FWIW, the WG Chairs wiki is also silent on this matter, and perhaps that is the best place to add a discussion about WG adoption of I-Ds. Is that more palatable? We hire the best and the brightest as our working group chairs in order to rely on their judgment and management abilities, [WEG] Well, no disrespect to any current or former AD, but this is giving us entirely too much credit for why the vast majority of our WG chairs are good at their jobs when it's more likely attributable to luck. Unlike other leadership positions in IETF, there's no formal interview or hiring process to determine who out of the group of engineers that make up IETF is best qualified to start chairing a WG. I certainly had no specific experience that made me any better than anyone else at being a WG chair the first time around. My qualifications included a non-zero amount of common sense, available cycles, interest in the topic, and joking the poor sense not to decline when asked to serve /joking. There's no mandatory training class. If one is lucky, you get paired with an experienced co-chair (I did) and given a pointer to the wiki (I didn't) to help you learn on the fly. It's clear that we trust our WG chairs, and there's nothing wrong with that. But sometimes providing them with more guidance is helpful. 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.
When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Leslie I'm increasingly seeing a paradigm where the review happens _before_ adoption as a WG draft. After adoption, there's a great lull until the deadline for the next IETF week. There tend to be a few, seemingly minor, edits for a version to be discussed. The meeting time is taken up listing changes, most of which get no discussion. Lather, rinse, repeat... [WEG] I've seen several discussions recently across WG lists, WG chairs list, etc about this specific topic, and it's leading me to believe that we do not have adequate guidance for either WG chairs or participants on when it is generally appropriate to adopt a draft as a WG document. I see 3 basic variants just among the WGs that I'm actively involved in: 1) adopt early because the draft is talking about a subject the WG wants to work on (may or may not be an official charter milestone), and then refine a relatively rough draft through several I-D-ietf-[wg]-* revisions before WGLC 2) adopt after several revisions of I-D-[person]-[wg]-* because there has been enough discussion to make the chairs believe that the WG has interest or the draft has evolved into something the WG sees as useful/in charter; Then there are only minor tweaks in the draft up until WGLC (the above model) 3) don't adopt the draft until some defined criteria are met (e.g. interoperable implementations), meaning that much of the real work gets done in the individual version It seems to me that these variants are dependent on the people in the WG, the workload of the group, the chairs, past precedent, AD preferences, etc. It makes it difficult on both draft editors and those seeking to follow the discussion for there to be such a disparity from WG to WG on when to adopt drafts. I'm not convinced that there is a one-size-fits-all solution here, but it might be nice to coalesce a little from where we are today. So I wonder if perhaps we need clearer guidance on what the process is actually supposed to look like and why. If someone can point to a document that gives guidance here, then perhaps we all need to be more conscientious about ensuring that the WGs we participate in are following the available guidance on the matter. 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.
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa Sent: Wednesday, November 21, 2012 8:49 AM To: ietf@ietf.org; l...@ietf.org Cc: j...@mercury.lcs.mit.edu; jcur...@arin.net; pwil...@apnic.net; i...@ietf.org Subject: Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC The concept, as I understand it, is that there will be no migration out of [that] allocation, for the simple reason that the entire rationale of this range of namespace is that it will be processed differently, i.e. require special casing in the code in various places; something like: if ((dest EIDSPACEMASK) == EIDSPACEALLOCATION) process_one_way(); else process_another_way(); That being the case, the last thing one would want is either i) changing the block that is handled specially, or ii) having a number of smaller blocks, allocated over time, as either one would require much more complex code to handle: you'd have to have some sort of config file, which could hold multiple blocks, code to read it, the code to process packets (above) would have to be able to handle multiple blocks, yadda-yadda. (Changing the block is the same as having multiple blocks, because past a certain point you're too big for a flag day, which would be the only way to avoid having multiple blocks in use at the same time.) [WEG] Then the draft needs to say some variant of the above - why it can't migrate, why a flag day won't work, and why it needs that size block right now for an experimental technology, including some justification about the size of the block. If the allocation justification is not going to be done within the RIR community, then it needs to be done here. Noel, you specifically complained about IETF not allowing experiments to proceed while some details are still a little hand-wavey [1], but you seem to want it both ways. If this is to be permanent space, then permanent justification and level of detail is required. If it's to be an experiment, then it should expect that there will be at least one renumber as it transitions from experiment to production. I don't think that expecting code to handle two blocks (the experimental one and the permanent one) is asking too much, nor is it expecting too much to require a line in the sand to ensure that the transition between experiment and production happens before you're too big for a flag day. If a single permanent allocation that never changes is truly necessary, putting a sunset date on the allocation from IANA seems a reasonable solution to me, but no one really responded to that in my last mail [2]. If the experiment is wildly successful and leads to a permanent deployment, then the currently experimental RFCs get updates written to elevate them to proposed standard, and while we're at it, we remove the sunset date from the IANA allocation. If the experiment ends up being a science project and doesn't gain wide deployment, this reclaims the space to prevent it from being another Class E space that is essentially stranded by an allocation that is no longer used. I suspect (I haven't communicated with them directly) that the people who are involved with this scheme don't really care _who_ allocates the space, and how - all they care about is that it's all in one chunk - for the reason laid out above. [WEG] and the people who are involved in number allocation have clearly told the people involved in this scheme that they do care who allocates the space and how, especially if the experiment has no bounded end. I think a compromise is doable, but saying it's not important right now probably isn't going to make the problem go away. Thanks, Wes George [1] http://www.ietf.org/mail-archive/web/ietf/current/msg75920.html [2] http://www.ietf.org/mail-archive/web/ietf/current/msg75919.html 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.
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa If a single permanent allocation that never changes is truly necessary Allocation != reservation. Nobody is asking for the entire chunk to be _allocated_ (i.e. given out), just that it be _reserved_ for this use. [WEG] You're hairsplitting on semantics in a way that is mostly unhelpful to the discussion at hand. Reserving the block for LISP means that it cannot be used for anything else. Whether that's an IANA reservation or an RIR allocation is really immaterial to the point I was making, which is that if you truly believe we have to identify a block once and for all for LISP that is the correct size to be used permanently and indefinitely, you need a better justification than you've given, and using experimental as a justification for not having the details worked out isn't going to be acceptable. 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.
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter *please*please*please* study what happened to 6to4 and the 2002::/16 prefix before continuing this discussion. The problem there was that the design of 6to4 assumed, and relied on, altruistic cooperation between operators, to ensure that there was a useable route to 2002::/16 *everywhere* in the IPv6 network. That assumption was naive and led to black holes. [WEG] The other problem with 6to4 is that by the time we tried to shut it down because we determined that it wasn't working acceptably and/or had fatal flaws in its design, there was a small (but extremely vocal) group of people who basically said you can have 6to4 back when you pry it from my cold, dead fingers!! -- perhaps we can kill two birds with one stone if you can convince those same people to let you repurpose the 2002::/16 space for LISP? *ducks* :-) More seriously: I echo the concerns that others have raised about the questionable justification for a /12 or /16, the limited details around how allocation and management might work, and the recommendation to go talk to the RIRs and learn how address allocation might work so that you can give them helpful recommendations when (and if) it comes time to write RIR policy to manage this space. I'd rather this not be deferred to a later document, because there is little incentive to complete such a document once the allocation is already made. Either you know how this will be used and can articulate it, or you don't. If you don't, you aren't ready to request it. Additionally: The LISP documents are classified as experimental (though this one is not...). Therefore I see two possible solutions that don't appear to have been discussed yet: 1) the RIRs have existing policy regarding experiments (e.g. https://www.arin.net/policy/nrpm.html#eleven ). You might consider looking at those policies to see if getting a direct allocation from one or more RIRs for your experiment would be a workable solution, rather than locking space into this via IANA. 2) Request the space (with improvements to the request as stated above and elsewhere in this thread) but include a sunset date for the allocation from IANA. If the experiment is successful, the expectation is that you will write proposed standard drafts refine the implementation and to make it not experimental, and you can make the IANA allocation permanent at the same time. If the experiment is not successful and this space is no longer needed in a few years, we don't have to fight a small vocal minority to shut it down. (c.f. RFC3701). While I'm *less* worried about us wasting IPv6 space, it's not infinite, and I'm having visions of the IPv4 Class E space, where we have this sizable chunk of addresses allocated for a special purpose that 10 years from now could (and should) be used for something else, and inertia means that they never do, filed under it seemed like a good idea at the time... 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.
in-person vs remote participation (was: Newcomers [Was: Evolutionizing the IETF])
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector Santos The IETF should be leading the charge for easy to use, multi-device readiness cyberspacing virtual meeting places, including better electronic groupware collaboration tools, etc. It is undoubtedly and inevitably the Achilles' Heel for the IETF Meeting. So the IETF needs to embrace it now, big time, before its too late. This includes getting on board with membership models to subsidize the business and its future. This shouldn't take away Face to Face communications - in fact, it will increase it. Its much more doable with today's higher universal bandwidth and the IETF needs to be prime examples of the various technology it is helping put together and standardize. In fact, the IETF can probably learn and help improve groupware communications with new working groups focusing on groupware. [WEG] as someone who normally attends meetings in person, and had no choice but to participate remotely this time on account of injury, I agree that IETF needs to be focused on ways to improve remote participation as a means to reduce the barrier to participation that our current travel requirements represent. However, this is not only a technology problem. Remote participants suffer from a cultural problem that is merely being exacerbated by the technology's limitations. It is by no means unique to the IETF, because I've experienced it plenty of times while working for companies that have remote offices and teleworkers, but we definitely need to acknowledge it and look for solutions to it if we're going to be successful with remote participation. Remote participants are figuratively (and often literally) invisible, and therefore people forget about them, and they get relegated to second-class status as a participant. Even if it's only subconsciously, the in-person participants don't see remote participants to be as committed to participation as those who gave up a week, traveled, paid for hotel, meals, registration, etc. and often the lack of a face to go with the name makes a tangible difference in the interactions. The only reason that remote participation even sort of works in the IETF is that there are enough people who have done it before and know how much it can suck when it goes poorly that they make a conscious effort to treat remote participants as an equal part of the meeting attendees such that they enforce good mic etiquette, volunteer to be jabber scribes, ensure presentations are posted, etc. even when the WG chairs fail to do so. While I am very grateful for those folks, that's an unreliable mechanism, one that failed on numerous occasions in several WGs I tried to participate in this past week. I don't post this message to whine, but to note that if we're going to get serious about remote participation, it's not all about shiny new tools, but instead the mentality of those who still participate in person. There are other less tangible issues that I'll address in another message. 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.
in-person vs remote participation (was: Newcomers [Was: Evolutionizing the IETF])
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Personally I believe there could be value in describing what the value is to attend the meeting physically. I attended the last meeting in Stockholm because it meant I only had to pay the entrence fee, since I live there. Getting buy-in from management to allow me to go for a week somewhere and not be available in the office, pay for hotel and travel, plus the entrence fee, it's hard to justify to management. What is a good answer to the question why?. [WEG] I've had to justify my participation in IETF multiple times in the last few years, and while official duties as a presenter or WG chair made justifying travel easier, prior to that point, I had to try to articulate exactly this. As noted in my other message, this was the first remote meeting for a while for me, and it put into sharp relief the difference between in-person and remote participation. While most folks do indeed attend IETF to attend WG meetings, I think that's only part of the story, and you're right, it's something we need to do a better job of articulating and considering when we attempt to replicate IETF attendance virtually or help new participants feel included. First and foremost, the act of getting away from the office and the financial and time commitments involved in traveling to a physical meeting a few times a year tends to reinforce the need to prepare for the meeting by reading drafts, catching up on IETF work that has languished, etc. The travel and meeting schedule imposes a deadline of sorts, in addition to providing physical separation that allows people to reprioritize their work so that for that week or so, $dayjob becomes secondary to focusing on what's happening in IETF, since everyone traveled all that way and spent all that money to meet together. The proximity provides an excuse to get work done, whether in a WG meeting, or sitting in the hall collaborating with a co-author in real-time. I don't know how you replicate that virtually, especially in the extremes of timezone differential. I know for me, life intrudes a lot when I haven't physically *left* my normal location and therefore I should be available for the things I would normally do when I am home or in the office. Perhaps if we move to a virtual-only model, we would be able to spread the work out in smaller chunks over more time so that it's more manageable as a portion of your overall workload, or perhaps we keep the defined meeting time as a way to ensure coordination across many timezones, I don't know. The other things that become important are the hallway track and the many fine lunches and dinners. Those come up when talking about attending IETF in person, but often it's meant to imply that those involved are there for the wrong reasons (i.e. IETF as company-sponsored tourism or job search) rather than to acknowledge its value in ensuring that IETF does make progress by forging personal and professional relationships between its participants. There is so much networking that happens during those that is mostly lost to remote participants, and it really is invaluable. Whether it's trying to work out a compromise on a particularly contentious part of a draft, or stumbling across a problem or solution in a freewheeling conversation, or just talking shop with like-minded folks, I find that this makes IETF a much more rewarding experience. I also find that this makes it easier to make progress in WGs when limited to low-bandwidth communications channels like email, because you now know the other people involved. In person attendance, food and drink provide the opportunity, and are the means, rather than the end. But that requires you to know people well enough at least professionally that you can take advantage of that. I can see that being challenging for those who are newcomers or have only met someone virtually. I am quite sure that there are ways to replicate those more unofficial/social interactions virtually with the improvements in video conferencing and telepresence technology, but I'm not sure it's possible to get past the strong psychology that makes doing it over food and drink more effective. The whole meatspace vs cyberspace argument has been going on ever since there has been a cyberspace, so I'm not going to act like this is new, but I think we're getting to the point now where the technology is catching up with the science fiction portrayal such that it's worth having the discussion again. 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,
RE: IESG Considering a Revision to NOTE WELL
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of IETF Chair === Proposed Revised NOTE WELL Text === - You understand that meetings might be recorded, broadcast, and publicly archived. [WEG] I might suggest a small tweak (in brackets below) to this part of the text given some of the previous discussions around blue sheets/privacy and documenting people's participation in IETF potentially against their will: - You understand that meetings [and therefore your participation in them] might be recorded, broadcast, and publicly archived. I think this makes things a little more explicit in a way that may be helpful to those who are less familiar with IETF meetings. Otherwise, consider this a +1 to comments supporting simplification of the Note Well text to make it a more effective summary. 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.
RE: Last Call: draft-ietf-behave-lsn-requirements-07.txt (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice
From: Simon Perreault [mailto:simon.perrea...@viagenie.ca] Sent: Saturday, July 07, 2012 5:21 PM Wes, Here's my take on this... CGN as defined in this document does not only include NAT444. It is more generic than that: it really means multi-user NAT. Dave Thaler came up with the example use case of the NAT in a wifi hotspot. It's just NAT44, but it still fits with the draft's definition of CGN because you have multiple users potentially fighting for the same NAT resources. Remember that the main raison d'être of this draft is for the operator to be able to ensure fairness between NAT users. So in this view I think it is clearly behave material since the sunsetting of IPv4 really is orthogonal to multi-user NATs. On the question of IPv6: I don't think we should talk about IPv6 simply because IPv6 NAT so far has not seen significant deployment in the context of multi-user NAT. And NPTv6 is stateless so there are no resources to fight for. [WEG] I agree with all of what you've said, but I think I need to make the point that I'm concerned with clearer, because the above doesn't exactly address it. I wasn't saying anything about IPv6 NAT, or even IPv4 sunset. I was saying that the current wording is unclear as to what you mean by IPv4-only. While the NAT specified by this document itself may only act on IPv4 traffic, as you note above it's not limited to just NAT444 or even an IPv4-only *network*. The recommendations in this doc will work for an IPv4 NAT associated with DSLite just as easily as a more traditional IPv4 transport. This is an important distinction, IMO. Back to your email, where you wrote: if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. How about Common Requirements for IPv4 Carrier Grade NATs (CGNs)? [WEG] This helps, but only in conjunction with additional clarification about the application - that is, just because the NAT is IPv4-only doesn't mean that the network must also be IPv4-only. Thanks 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.
RE: Last Call: draft-ietf-behave-lsn-requirements-07.txt (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice
I have a comment about this document related to some discussions that I've had with a number of ADs and WG chairs around the formation and charter of Sunset4 to determine what is and is not in scope for that WG. For a while both BEHAVE and Sunset4 had this document in their milestones, which clearly won't work. Therefore the distinction made between work to be done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically on the concept of NAT and the things necessary to make all flavors of it work, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, etc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only items. The BEHAVE chairs were represented in these discussions, and they believed that this document was in keeping with this distinction. In the document's introduction, for example, that generic nature is implied: It is not an IETF endorsement of CGN or a real specification for CGN, but rather just a minimal set of requirements that will increase the likelihood of applications working across CGNs. However, this document states in section 2: Note also that the CGN described in this document is IPv4-only. IPv6 address translation is not considered. I see that this is a new change to the -07 version, so I hate to rehash the discussion, but I think that this statement should be clearer. In reading the document, I don't believe that the intent was to limit it to being a discussion of NAT44[4], but that could be the way that this statement is interpreted. The distinction I might make to clarify is that since the document is talking about behaviors that are necessary to make IPv4 address-sharing work, it's specific to the IPv4 side of what could well be a dual-stack NAT, but it's not limited to simply NAT44[4]. I'm not advocating pulling this document back so that it can go to the right working group, because I don't think that'll actually add any value to the document and I'm not a fan of process for process's sake. My concern is really more about content and naming- if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. If it's meant to be a generic LSN requirements doc, the authors should make the appropriate changes to keep it generic. Thanks, Wes George, at least partially wearing my Sunset4 chair hat -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, June 26, 2012 12:59 PM To: IETF-Announce Cc: beh...@ietf.org Subject: Last Call: draft-ietf-behave-lsn-requirements-07.txt (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Common requirements for Carrier Grade NATs (CGNs)' draft-ietf-behave-lsn-requirements-07.txt as Best Current Practice 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 2012-07-10. 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 defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-lsn- requirements/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1648/ 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.
RE: IETF attendees reengineer their hotel's Wi-Fi network
I had recommended separately on the attendees list that perhaps Chelliot and his merry band of supernerds need to write an informational or BCP draft, accompanied by a round of *NOG presentations to share the wealth, as documentation in this area appears a bit sparse -- I've been to plenty of other conferences where the wireless network melted down in the hotel, conference itself or both. In response, Joel Jaeggli pointed to a NANOG presentation that is so old that it's still talking about 802.11G (and A) as a future thing, and the network in question was probably dealing with half or less of the devices that a modern one must do (no wi-fi phones, tablets, etc). So while the fundamentals of dealing with RF frequency overlap and power probably haven't changed much, I think that perhaps we're due for an update on the experience of managing and optimizing large-scale conference/hotel WiFi networks, especially the part about the tools that you use that enable you to re-engineer a network of that size on the fly (aside from pure awesome and lack of sleep, that is). :-) Thanks, Wes -Original Message- From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, March 29, 2012 5:44 PM To: George, Wes Cc: IETF Discussion Subject: Fwd: IETF attendees reengineer their hotel's Wi-Fi network Hi Wes, Could we perhaps add a section to your draft (draft-george-travel-faq-05.txt) on how to fix wifi network in the hotel you are staying ? Pointer to set of open source wifi troubleshooting tools would be welcome too ;) Cheers, R. Original Message Subject: IETF attendees reengineer their hotel's Wi-Fi network Date: Thu, 29 Mar 2012 17:28:26 -0400 From: Russ Housley hous...@vigilsec.com To: IETF ietf@ietf.org Disgusted IETF attendees reengineer their Paris hotel's Wi-Fi network What happens when a bunch of IETF super nerds show up in Paris for a major conference and discover their hotel's Wi-Fi network has imploded? http://newsletters.networkworld.com/t/6464858/258923304/355639/0/ 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.
RE: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ?
Which is why I'm wondering why it took us that long to punt him? Our rules shouldn't treat people like this as a first-time poster if it's the same nonsense that got them banned before, but from a new email address. Mr. Fleming had stopped trolling lists for the last 6-9 months, but prior to that he was hitting every list he could find plus Twitter (hashtag spamming), and it appears that it's about to start again, so I'd ask that the admins be a bit more aggressive in this regard. Thanks Wes George -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, March 29, 2012 6:01 PM To: Eric Burger Cc: IETF list Subject: Re: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ? Oh, this guy pre-dates RFC 4633 http://www.google.com/search?q=%22jim%20fleming%22%20site:ietf.org On Mar 29, 2012, at 11:48 PM, Eric Burger wrote: I was about to say we are at a point for an RFC 4633 action. Thanks. On Mar 29, 2012, at 2:26 PM, JORDI PALET MARTINEZ wrote: Hi Jim, This is my last message to you as IETF Sergeant-at-arms. I've asked the Secretariat avoid your posts going thru the email exploder. Regards, Jordi 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.
RE: Query to the community -- An additional IETF Meeting event?
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henk Uijterwaal We have had cases where the opening reception was sponsored by somebody other than the host for the meeting (if there was a host). The sponsor didn't get much more than the possibility to put a sign near the front door and get some recognition during one of the plenary sessions. This proposal essentially says that the sponsors can demonstrate equipment during the reception. [WEG] +1 I was one of the people who suggested this to IAOC after recently attending my first NANOG in a good while. While I realize the audiences (and therefore the attractiveness to marketing budgets) are different, the sharp contrast between the two made it clear that there may be some opportunities to tweak IETF's sponsorship methods and potentially reduce the costs attendees are asked to bear without turning it into yet another tradeshow or forcing I* members to wear auto-racing-style suits emblazoned with vendor logos. :-) In addition to Beer-n-gear, NANOG had 2 other sponsored (i.e. free to all attendees) socials, and enough free T-shirts to last a person a week, plus 3-4 slides full of sponsor logos. Not that we need any more free t-shirts, but compare that to this IETF, where if you want a shirt, you must purchase it because we didn't have a primary sponsor until Cisco took pity on us (and apparently the shirt cannot be sponsored separately). That said, I don't think that this potential experiment requires a *separate* night. I'd much prefer to replace the current overpriced hotel cash bar arrangement at the welcome reception with something more like beer-n-gear. I'm also willing to try it in lieu of a social event, since those are typically hit or miss in terms of whether the environment is conducive to socializing, whether they're worth the additional money one must pay to attend them, and the fact that these are generally limited participation (tickets required), thereby reducing the opportunities for group socialization. And, having been to such sessions at NANOG and others, I know that you don't have to look at the gear brought by the vendors, it is perfectly possible to have the beer (for free) and have the hallway discussion you wanted to have anyway, while ignoring the demos. [WEG] This is definitely true. The two are not mutually exclusive. 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.
RE: Last Call: draft-george-travel-faq-03.txt (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
Revision -04 has been posted which I believe addresses all of the comments received thus far. http://tools.ietf.org/html/draft-george-travel-faq-04 Thanks, Wes George -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, February 07, 2012 5:59 PM To: IETF-Announce Subject: Last Call: draft-george-travel-faq-03.txt (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'IETF meeting attendees' Frequently Asked (travel) Questions' draft-george-travel-faq-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-06. 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 attempts to provide a list of the common Frequently Asked Questions (FAQs) that IETF meeting attendees often ask regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF Wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or secretariat needs to provide, merely as a guideline. The file can be obtained via http://datatracker.ietf.org/doc/draft-george-travel-faq/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-george-travel-faq/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-george-travel-faq-03.txt (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM In Section 1: more efficiently than waiting until someone sends an email to the xxattend...@ietf.org list in the days leading up to the meeting. The XX is ambiguous. [WEG] Well, it was intended to be generic (a variable to represent multiple numbers). Are you saying ambiguous as in this intent is unclear, use a different method to represent this generically or you should use a specific number as an example, e.g. 83attend...@ietf.org? Would the meeting-specific attendees email list be better? The draft is written from am IETF perspective for an IETF audience. [WEG] It was written by an IETF person, in the IETF's process for managing documents. Within those constraints, it was meant to assume very little about what people know about IETF such that it could be useful to a non-IETF audience. If there's a point to this comment other than to be snarky, I'm missing it. Does http://wikitravel.org/en/Paris provide answers to some of the questions in this draft? [WEG] Probably. This draft is not about evaluating sources of information to be provided for individual and specific IETF meetings. It is meant to be generic. I'd encourage you to post that link to the Paris IETF's wiki. but that results in hundreds of people spending their time searching, which is not very efficient. If hundreds of people spent their time searching, there would have been more information on http://www.ietf.org/registration/MeetingWiki/wiki/doku.php Or is it not efficient for people to share the information they have found? [WEG] no one can force those who find an answer to their question (via whatever method) to post it to the wiki. The meeting wiki is only as good as its level of contribution, and this document isn't making commentary on that problem. This is simply noting that lots of attendees need a similar set of information. no matter how good online translation is getting, some of the most informative sites may be difficult for non-native speakers to Is this about informative sites being difficult for non-native speakers or for people from a specific part of the world? [WEG] I think this is pretty self-explanatory taken in the context of the preceding sentences, but I'll attempt to clarify. When one is attempting to do research about a place one is planning to visit, if the site with the best information is only available in the local language, and half of the site is flash or graphical text buttons, sending it to translate.google is not going to translate the text contained in flash or images, which may make the site difficult or impossible to use. The source and destination language/region is immaterial. This is simply defining a practical matter associated with language barriers online. I suggest that the author seeks feedback from people who use English as a second language. [WEG] The author has sought and received feedback from the IETF list multiple times prior to last call, and again now. One might be forgiven for assuming that there are a few nonnative English speakers among the subscribers of said list who have read the document. If those who use English as a second language have text to provide, he'll gladly accept it. Otherwise, maligning the document or its author because it attempts to cover language issues but was written by an native English speaker is not particularly productive. Visa requirements is a one-liner whereas food considerations are discussed in several paragraphs. [WEG] The main posting on the IETF site regarding the specific meeting includes a link to one or more Visa information sites. IETF has been providing links to Visa information for years, as it is far more critical to foreign attendance than any of the other items discussed in this document. Therefore I didn't spend a lot of time on it. The only part of the currently-provided visa information that I have seen complaints about is when the combination of the source and destination countries' embassies don't play nicely together and Visas take too long to be practical. That is a much different problem. However, more than one person has commented about the limited text with regards to visas, so I'll attempt to bolster the Visa discussion slightly, but suggested text is welcome. Section 3.3 is labelled International considerations. The entire document is about international considerations. [WEG] After reviewing what is in this section based on your comment, I'd argue the other way. Like the rest of the document, a large portion of it is not specific to international travel and may vary by region and municipality within the same country. I'm open to suggestions as to an alternate heading for section 3.3 that is more descriptive than other. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential,
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I've been recommending this direction (that this is basically just more private space, no magic) for some time, so I support the change. However, I strongly believe that the document should formally update RFC1918, not just 5735, especially now that it specifically says that in certain circumstances the space can be used as 1918 space. Having the linkage between the documents (from 1918 to this one, instead of just in the other direction) is quite important, IMO. Wes George -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, January 30, 2012 6:04 PM To: IETF-Announce Subject: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' draft-weil-shared-transition-space-request-14.txt as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. 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 requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier Grade Network Address Translation (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premise Equipment (CPE). Shared Address Space is distinct from RFC1918 private address space because it is intended for use on Service Provider networks. However, it may be used as RFC 1918 private address space in certain circumstances. Details are provided in the text of this document. As this document proposes the allocation of an additional special-use IPv4 address block, it updates RFC 5735. The following text captures the most salient change between version 10 and 14 of this document: Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space when at least one of the following conditions is true: o Shared Address Space is not also used on the Service Provider side of the CPE. o CPE routers behave correctly when using the same address block on both the internal and external interfaces. The file can be obtained via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for allocating this space was that 1918 space _couldn't_ easily be used for CGN because there were too many conflicting usages. [WEG] yes, but the general sense I got from the ensuing discussion was that no one expects anyone to actually adhere to that advice (ie MUST NOT be used as substitute for 1918 space), and as soon as the space is released, it'll be cats and dogs living together, mass hysteria... because everyone and their cousin will start using it as 1918-bis anyway, no matter whether the IETF wags their fingers at them or not. So, now we're making more 1918 space? This is a good idea... how? If we need more 1918 space, let's do so deliberately, and not kill the usefulness of this space for CGN. (Unless, of course...) [WEG] I think it provides a window of opportunity - get in before the place gets busy. Hopefully by the time people have really adopted the space for 1918-type uses, working IPv4 CGN will be of less relevance... or at least that's what I'm telling myself. This just acknowledges what people believe to be the case instead of trying to deny that it'll happen. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-george-travel-faq-02
I've made updates to this document to improve the structure (more subsections instead of multiple levels of bullets) as well as to incorporate the great feedback on content that I've received from lots of folks. I'm sending it for one more round of review and feedback before I move towards publishing. http://tools.ietf.org/html/draft-george-travel-faq Unless I receive feedback to the contrary, I'll be pursuing this as an Independent Submission. Thanks Wes George -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Tuesday, January 10, 2012 2:25 PM To: George, Wes Cc: George, Wes Subject: New Version Notification for draft-george-travel-faq-02.txt A new version of I-D, draft-george-travel-faq-02.txt has been successfully submitted by Wesley George and posted to the IETF repository. Filename:draft-george-travel-faq Revision:02 Title: IETF meeting attendees#39; Frequently Asked (travel) Questions Creation date: 2012-01-10 WG ID: Individual Submission Number of pages: 11 Abstract: This document attempts to provide a list of the common Frequently Asked Questions (FAQs) that IETF meeting attendees often ask regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF Wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or secretariat needs to provide, merely as a guideline. The IETF Secretariat 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
primary Paris hotel booking
Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-arkko-ipv6-only-experience-04.txt (Experiences from an IPv6-Only Network) to Informational RFC
I support the work behind this document, but I do have a concern that gives me pause regarding publishing it as an RFC in its current form. I worry that it will serve as a disincentive for people to attempt IPv6-only deployments. This is not because of the way that it's written, nor a commentary on the quality of the document itself. I think that it does a good job of noting that it is a snapshot and that things will continue to improve, etc. but it runs afoul of the limitations of the IETF's document process- a static document reporting current test findings is almost instantly obsolete. This is a much larger problem than this draft, but it is something to consider when thinking about the content of this draft and how it will be interpreted, the audience, etc. If the draft were to focus strictly on things which the *IETF* must fix in order to resolve outstanding problems with IPv6-only operation, those would be clearly actionable and new drafts written to resolve those issues could update this one, so that it's clear to future readers when something materially changes. In its current form, most of the noted broken things are related to specific implementations and therefore largely beyond the IETF's control (eg Skype, video game consoles, mobile phone stacks, etc). Unless it is updated with bis versions periodically when those issues are found to be resolved, it has the potential to mislead people as a source of information that they might use to determine if they should even consider trying this. Some of that information perhaps is better suited to a curated wiki, since it is easier to update it as the situation improves. FWIW, draft-donley-nat444-impacts has similar problems - very useful information, but not well-suited to s tatic documents. I don't know if that's enough to block the document, and I'm not going to be upset if it's published as-is, but I thought it was something that IESG should consider in their evaluation of the document. Perhaps it's a matter of delaying it for a bit and touching the document with updates to keep it active until we feel like we've reached an equilibrium after a bit more IPv6 deployment over the next 6-12 or even 18 months. Thanks, Wes George -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Friday, December 09, 2011 5:34 PM To: IETF-Announce Subject: Last Call: draft-arkko-ipv6-only-experience-04.txt (Experiences from an IPv6-Only Network) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Experiences from an IPv6-Only Network' draft-arkko-ipv6-only-experience-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-06. 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 discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-arkko-ipv6-only-experience/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-arkko-ipv6-only-experience/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Travel/Attendees list FAQ
Based on the discussion on the 82 attendees list, I put together a draft that provides a list of common questions (but not necessarily answers) that people ask when preparing to travel to a meeting. As the draft states, this is an attempt to provide a list of ideas for folks who can contribute to a wiki or host site (because they're familiar with the area), to help them ensure completeness of the information that they provide. It doesn't compel anyone (host, IETF, secretariat, etc) to do anything, merely makes recommendations. I got some feedback on the -00 version from folks on the 82-attendees list, and I've updated the draft with an -01 version based on that feedback. I am now expanding the audience to the larger list so that I can get additional feedback. Please have a look and send comments my way. I'm also open to suggestions as to the appropriate publication track for this document, whether I should look to have it sponsored as a GenArea doc or simply put it forward as an individual submission. http://tools.ietf.org/html/draft-george-travel-faq Thanks, 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Travel/Attendees list FAQ
From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, December 07, 2011 9:28 AM To: George, Wes Cc: IETF Discussion Subject: Re: Travel/Attendees list FAQ However I suggest that the document cast itself as a snapshot of an on- going documentation process, with the master copy being an IETF Wiki; the document should contain a point to the wiki. [WEG] There is currently a pointer to the wiki, but I'll have to think on how to update the text to make this distinction about how updates are managed. I'd like to hope that we can get to something quasi-complete in terms of the questions, since they should be relatively static and the answers are what changes from meeting to meeting and are stored in the wiki, with the idea that updates to this document could be handled through the draft process periodically (similar to other docs like the Tao). I'll also suggest that there be an on-going mailing list for discussing meeting logistics issues, rather than a different mailing list for each meeting. (ietf-meeting?) [WEG] I think because you have different attendees for each meeting that this might be problematic. I didn't miss the email chatter for the last IETF meeting that I didn't attend, and in fact, the whole point of this draft is to try to cut down on said chatter. Perhaps the way to manage this is to have two lists - an IETF-meeting list, and then an xxattendees list, and then people interested in higher-level meeting logistics (not specific to one meeting) can manually subscribe to the IETF-meeting list, and the xxattendees list itself is simply subscribed to the ietf-meeting list for the duration of its relevant period, and then unsubscribed afterwards (or vice versa). Thanks 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Travel/Attendees list FAQ
On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote: What is the value in publishing a living document as an RFC (which inherently a static, archival document)? Wouldn't it make more sense to convert the contents of this document to a Wiki page that we could jointly edit and maintain going forward? +1 I think it's important that this be dynamic and easy to change. Bob [WEG] I think that we're already off in the weeds based on an incorrect assumption, so I'd like to clarify before we get too far along with this. This is a list of the *questions* because they do not change much from one meeting to the next. The document already recommends that the *answers* which will be different for every venue be kept in a place where they are more easily updated. From the abstract: This document attempts to provide a list of the common Frequently Asked Questions (FAQs) ... if they wish to pre-populate answers to some or all of these questions either in the IETF Wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. I'm going to take a crack at refining this text a bit based on Dave's prior feedback, but if I'm missing something as to why you're saying don't put this in an RFC because it changes too much please clarify. Thanks 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Travel/Attendees list FAQ
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore I think it's great that Wes put together a proposal and I hope that it's seen as a starting point for a wiki or some such rather than as yet something else that needs an editor and needs an approval process and that isn't as lightweight and responsive as something like an attendees info sheet should be. [WEG] For my part, since I've gone to the trouble of draftifying this, I plan to get my document to a point where I feel that it's reasonably complete (ie I'm not receiving any additional feedback on items that are missing) and publish via the individual submission process. As with most other RFCs, what folks choose to do with the document once it's published (use as a wiki/info website template, summarily ignore, etc) is really up to them. It was intended to be a (hopefully helpful) tool, and my best-case result would be that it is provided with the information that we typically give to hosts to assist them in hosting an IETF. However, I purposely left any sort of formal direction to IAOC or the secretariat out of this document, at least partially because I think that this is simply one example of a recurring problem about how IETF should manage non-static info (cf previous discussions about official per-RFC wiki entries, etc), and I didn't want to have the solution to the generic problem be blocking for this specific example. In the meantime, my hunch all along has been that if for some reason the baseline information necessary (not the answers to the questions) changed enough that this document was in need of significant updates, someone (maybe me if I'm still involved) would simply write an update to it. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Doug Barton Thank you for confirming publicly that the issue here is not a technical one, but rather that the ISPs would prefer not to bear the costs of dealing with the problem that they helped create. [WEG] Thank you for confirming publicly that you'd prefer to preach at/blame ambiguous entities (the ISPs) for perceived past sins as a way to make their problem seem illegitimate. Yes, ISPs would rather not make a bad situation worse. We're already bearing costs to deploy IPv6, and eventually will be bearing the costs of deploying and supporting CGN no matter how distasteful we find it. We'd rather not add additional CGN breakage to the mix. This is primarily because we want our customers to be happy, and broken customers != happy customers. Yes, broken customers have associated support costs that we'd rather not pay, but that's secondary. What's mystifying and frustrating me is that some folks in the IETF refuse to believe us when we say that based on what *we* know about *our* networks and the CPE that *our* customers use, use of 1918 or squat space will be worse. You've made it clear that you don't think that the 90/10 problem is a large enough problem to justify a separate allocation, and it seems unlikely that anyone will convince you otherwise, apparently because this is somehow someone's fault and they should take responsibility for it. I'm not sure what else I can say here. I'd love for you to be right and it's not a problem, but I'm not willing to stake my job on it. Are you? More seriously, it sounds to me like the most persuasive argument in favor of doing the new allocation boils down to simple extortion. Give us a $50,000,000 'gift' or we'll do bad things to the intahrnetz. [WEG] Really? Solutions to operator problems = extortion? Glad to see that discourse here has degenerated to same extent it has in politics - when all else fails, resort to hyperbole, FUD, and namecalling... And we wonder why we can't get better operator participation and representation here... 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
On Dec 4, 2011 10:40 AM, Joel jaeggli joe...@bogus.com wrote: 10.170.127.192/27 link#12UCS 20 en3 10.170.127.193 4c:47:45:56:44:58 UHLWIi422 34 en3 1197 10.170.127.207 127.0.0.1 UHS 00 lo0 And Cameron Byrne cb.li...@gmail.com wrote: An additional fact is that Verizon reuses 10/8 across their network, 10/8 per region. Net net, rfc1918 is used in cgn today. Squat space is also used in cgn today. Making an allocation creates another permutation of how cgns are deployed. Furthermore, a /10 is not a large enough allocation to be the one solution everyone can converge on. [WEG] I don't believe that anyone is suggesting that any one size of block fits all. I fully expect that networks of sufficient size would end up reusing the shared space multiple times for multiple NAT regions just like they would 1918 space. I also don't believe that the IETF could ever formally recommend using squat space given the known breakage cases that exist, especially since the party subject to the breakage may not be involved in the discussion of the calculated risk being taken. Put another way, existence proofs don't make it any better of an idea or reduce the risk of breakage. This leaves either GUA space, which we're ostensibly trying not to waste on things that shouldn't use up the precious resource, or 1918. I don't think that anyone on here is saying that it's completely impossible to use 1918 for CGN. I think they are saying that it has enough breakage cases that it's not possible to say that it's good enough for all cases by itself. Just as you say above that the size isn't good for all, you have multiple operators saying that 1918 as a solution is not good enough for all, along with technical and operational justifications as to why, and it mainly sounds like this is a question of whether IETF knows best trumps those justifications in determining whether they're legitimate problems or not. Also, independent of whether VPN works or does not work if the host is using 1918 space + NAT, there is an important distinction on the wireless CGN using 1918 example that covers the other breakage case: It's NAT44 in wireless (device directly to CGN), and not NAT444 as it would be in most broadband applications. It's only when you start talking about using a mobile device for connection sharing (MiFi or Phone WiFi hotspots, routers with LTE cards in them instead of wired uplinks, etc) that you're really comparing the two in a way that's directly applicable, since then you could have: [local 1918 segment] -LAN- SOHO/res NAT router -WAN- [CGN 1918 block] -- CGN -- [PublicIP] If these hotspot devices are doing NAT444 with private space on both LAN and WAN, vs doing NAT444 using Squat space on the WAN side vs doing NAT44 with a public address on the WAN side, that'd be good information to have, as it may be an existence proof one way or the other regarding whether having 1918 on both sides of a CPE router actually works. However, it's worth noting that in most cases, the mobile provider owns the device being used as that intermediary, so they can explicitly configure and test it to ensure that it functions correctly in the case where there is 1918 addresses on both LAN and WAN interface. There's no way to make that assumption with customer-provided CPE. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron Byrne The ietf did act. It is called ipv6. [WEG] sarcasm thanks for that wonderfully relevant and technical rebuttal. I'm so glad we've stopped debating philosophy and religion in this thread and gotten down to solving technical problems. I'll be sure to tell all of my customers (and my shareholders, for that matter) that when they call to ask why their new internet-enabled TV, Xbox Live/PSN, Skype, etc doesn't work on my IETF-approved (IPv6-only) Internet service. /sarcasm I don't know how much clearer I can make this, so I'll keep repeating it until it hopefully sinks in: Independent of whether we have any left, continued support for IPv4 in the home and enterprise is *non-negotiable*, no matter how many people stand atop the IETF soapbox and decree that it MUST be otherwise because IPv6 exists. I would also like it to be different, but there are a *lot* of stars that have to align before it actually is, most of which are not in my control. It's extraordinarily unproductive to vilify a group of operators as the singular scapegoat for IPv6's failure to generate critical mass when all they're trying to do is keep their network running and their customers happy, especially since they're simultaneously deploying IPv6, not using CGN to avoid it as folks on this list seem so quick to assume. If you have a way to convince my customers (or anyone else's) that they don't need IPv4 anymore, be my guest. Until then, let's stick to solutions to the actual problem, shall we? Saying that IPv6 is a solution to an IPv4 CGN implementation problem is like saying that a railroad car is a perfectly acceptable alternative to renting a truck to move the contents of my house across town without considering whether both my source and destination are in reasonable proximity to the railroad tracks. Or worse yet, saying that I shouldn't be moving house in the first place because trucks are scarce and less efficient than rail cars. And, they underscored that point by rejecting various past attempts at expanding private ipv4 space like 240/4. [WEG] Every argument I've ever heard regarding 240/4 was related to the difficulty of ensuring that it was going to work *everywhere* just like the rest of the currently allocated IPv4 space. It's similar to the problems associated with going to CIDR, but the installed base is much, much larger. The concern was that most, if not all router and host stacks would have to be updated to make it work. Even if it was only commenting out a few lines of code, that was viewed as a virtual impossibility, making it impractical to consider releasing the space for general use. I'm disappointed that the space wasn't simply released (even as additional private/experimental space) with the caveat that it may not work on old equipment, and then allow the market to decide how important it was to fix such equipment, even if just for specific use cases rather than globally routable space. IPv6 figured into the discussion, but only as a follow-on to the above. That is, it makes far more sense to expend efforts to ensure good support for IPv6 if we're proposing modifying the host stacks of lots of devices, as well as the idea that by the time we fixed 240/4, IPv6 would be well-deployed, and everyone would have their own personal 128 bit unicorn to ride, making this a case of too little too late. Depending on how far back in time you rewind, I think at least that latter point has been proven wrong repeatedly, and subsequent attempts to cut our losses and try to fix a previous poor assumption have been unsuccessful. I think that when people look back on the IPv4 to IPv6 transition, 240/4 will be a great example of IETF's hubris and failure to use all of the tools available to them in the name of upholding some misguided sense of principles (no matter how noble they might be) or forcing people to do it our way because there's no way that we could be wrong. I would still support releasing 240/4, but I don't think that it's a solution for this problem. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush talk to free.fr, camron byrne, ... there are roadmaps. but this proposal is not about migrating to ipv6. it is about ipv4 life extension and nat444 4ever. to hell with that. [WEG] let's see... free.fr = 6rd. Cameron Byrne (TMO) = NAT64 (which requires IPv6-capable end devices) + squatting on routable space (*not* 1918) + CGN. Please explain how either of those help to ensure that I can stay in business, given that my business requires me to provide functional IPv4 service to devices that my *customers* own which do not support IPv6, *IN ADDITION TO* deploying IPv6 [citations: 1, 2, 3, 4] for devices that do. Should I stop selling IPv4 service citing the IETF's principles on the matter? Tell all of my customers that they must spend hundreds or thousands of dollars to upgrade all of their otherwise functional IP-capable devices because the old ones are obsolete (not to mention that the current new ones *still* might not support IPv6)? I admit that DSLite would potentially help, but that requires support in CPE that is currently extremely limited, and my business model does not allow for me to purchase a new router for all X Million of my customers anyway. *taps the mic, clears throat* RandyBush I strongly encourage all of my competitors to do the above. /RandyBush snip this has become a contest of wills, not a technical discussion. [WEG] only because a number of folks, including you, insist on arguing about the principle of the thing and making the internet work better and IPv4 life support while rejecting technical arguments that you don't believe/like despite hearing them from multiple operators and other sources. This is turning into a referendum on CGN and whether the industry as a whole has deployed IPv6 fast enough for a set of armchair quarterbacks' taste, and now people seem content to wag fingers and revel in saying I told you so... because business reality didn't line up with their view of how the universe should work. This is akin to standing on the deck of the Titanic and yelling I told you we needed more lifeboats! instead of finding a piece of wood to float on. CGN = RFC6264. I'm not sure why it passed IETF LC or IESG vote given the resistance this draft is getting, but if you don't like it because it breaks the internet and extends IPv4, then write the draft to make that historic, along with NAT44, and any other astoundingly bad ideas that IETF has had for extending IPv4 beyond its original design life. For that matter, write a draft to make IPv4 historic. I (along with several authors of this draft) am already trying to update IETF's official position (for some value of official) from version agnostic to IPv6 is a requirement, and I'd welcome the help. But stop conflating a practical solution to a practical problem with whether IPv6 is deployed or whether CGN (and IPv4) is fundamentally bad. I've been conflicted on this draft all along. I hate the idea for all the same reasons everyone else does, and I'm just as unhappy that IPv6 isn't further along. But I see few good alternatives, and I'm not sure it's worth cutting off my nose to spite my face, so I chose to stop opposing it. You may be correct, that RFC1918 would work in the majority of cases, and that people are likely to use this new space for off-label uses the first time they run into an RFC1918 conflict. So what? Is squatting on allocated space really the better idea? What about people who legitimately *can't* use RFC1918 space? Are they just SOL, or are you convinced that they're lying? As far as I can tell, your argument regarding this being used as RFC1918 annex is - people are idiots and they'll do things we tell them not to, despite RFC that says 'Very Bad Things will happen if you do x', so we shouldn't even give them the option. The problem with idiot-proofing is that there are always better idiots. Wes George CF 1 http://www.timewarnercable.com/SoCal/support/IPv6.html 2 http://www.comcast6.net/ 3 http://ww2.cox.com/residential/idaho/support/internet/article.cox?articleId=%7B0bced860-9666-11df-6baf-%7D 4 http://www.att.com/esupport/article.jsp?sid=KB409112cv=812_requestid=723971#fbid=V_Bys5OCNCJ 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
RE: An Antitrust Policy for the IETF
Tl;dr version: I think that there is value in having IETF legal counsel evaluate us against other SDOs specifically regarding considerations around membership (or lack thereof), voting (or lack thereof), and openness (or lack thereof). That would help us to determine if this is really something we need to pursue/be concerned about, because it would help to determine if IETF is just like the other SDOs who have an antitrust policy, or if they are materially different enough that it's probably not necessary. Responding to a couple of specific points inline below... Wes George -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Donald Eastlake (c) The IETF does not have any members The governance of the I* is complicated but I don't think any court would have any trouble finding that, for some purposes, the membership of the IETF is those qualified to serve as voting noncom members. [WEG] Yes, but that is by definition not restricted other than to ensure that those involved have some familiarity with IETF by virtue of having paid registration for multiple meetings. Note the distinction here - while 3777 says attended it is not more specific on what can be considered attendance. One could easily register and skip every single meeting if it suited their purposes - we're not checking blue sheets here... Further, eligibility as a voting nomcom member affords no additional influence in the process of defining standards. It only provides influence if one is randomly selected (via a publicly published algorithm) to participate on nomcom, and even then, that is only to install leadership, not to dictate technical policy. Yes, there is a relationship between nominated leaders and technical standards, but that's a stretch IMO. (d) People participate in the IETF as individuals [WEG] this would be tough to defend. We say that, but we still allow people to place a company affiliation on their badge and on any drafts that they write, use company email addresses (including those who forcibly append stupid legal disclaimers at the end of every message :-/ ), and run afoul of company IPR, not to mention the fact that the vast majority of people attending meetings are funded by their company, both in time, travel costs, and registration fees. (f) The IETF does not vote Legally, I don't think there is much difference between many IETF decision procedures and the voice voting commonly used in various assemblies. [WEG] I disagree. Anyone can participate in the unofficial votes that the IETF holds in WG meetings and on mailing lists. The vote can be skewed by tourists in the WG meetings, people who hum particularly loudly, the acoustics of the room, people who join the WG mailing list simply to voice an opinion on a certain draft or issue, etc, etc. And the votes are untallied, non-binding, primarily serving as guidance to WG and IESG leadership. Many other SDOs have very defined requirements around what is considered a member and when you can vote (such as IEEE, which requires a certain amount of documented attendance before one can vote on technical proposals: http://ieee802.org/3/rules/member.html). Votes are also tallied and used as official decisions. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 support in hotel contract?
From: Andrew Allen [mailto:aal...@rim.com] We can put all kinds of wonderful constraints on hotels if we want to - [snip] - then we will likely never be able to meet anywhere. [WEG] I am not suggesting that this be a deal-breaker constraint. We have quite a number of nice to have items that we will ask for, but not necessarily take our business elsewhere if we do not get. The sense I get from IAOC is that dates, capacity, and cost are the constraints. IPv6 support is window dressing (or deck chairs, depending on your perspective). IF IPv6 really requires IETF to use its business to influence hotels to adopt it then its a technolgy that deserves to go the way of the DoDo. IPv6 will be adopted because it is needed and brings commerical benefits to those that deploy it. [WEG] This is not an attempt to force *whether* IPv6 will be deployed, but when. Hotels are sort of an extension of the consumer space - right now, they don't know/care what IPv6 is, nor see a reason why it's necessary. It is quite unlikely that your average person will walk to the counter and say, your internet service is partially broken because it doesn't support IPv6. It is even less likely that this will happen enough times that they say, gosh, perhaps we need to look into this eye pee vee six thing... IETF has some leverage, and by definition should be on the early adopter curve, so I'm simply suggesting that they use it to accelerate the timeline a bit. From: Cullen Jennings [mailto:flu...@cisco.com] I love the taste of dog food, but v6 in the hotel is not something that I find critical to accomplish the task I come to IETF to get done. [WEG] We're working contracts for hotel venues 3+ years out at this point. How long are you willing to assume that IPv6 will not be critical to tasks that you need to do at IETF and that the IPv4 service in the hotel will be an acceptable alternative? 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)
I'm also completely mystified as to why IPv6 support for all proposed/requested features is not an explicitly stated requirement, even at this phase. It's not always as simple as we'll make sure we make it IPv6 capable when we implement it... with the sorts of solutions you're looking for here. Knowing that we require this at this phase would allow for some vendor self-selection or proper time to fix the gaps prior to formal proposals, so that we don't end up with lip service around IPv6 support. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 support in hotel contract?
My last message caused something else to occur to me - there has been a lot of discussion both here and at NANOG about hotels being woefully underprepared for the internet (and address) use that their guests generate when a conference full of geeks and their multiple devices per person descend upon them. Sometimes the IETF is successful at convincing the hotel to let them take over the internet service in the guest rooms, sometimes not. Perhaps we can kill two birds with one stone by starting to require IPv6 service in the guest rooms when we enter into negotiations with hotels. If they don't have it, we'll be happy to temporarily take over the internet service, or assist them in getting it enabled permanently in their existing network, and if neither of those options are acceptable, it provides negotiating leverage on other things. This also has the net effect of starting to make it clear to hotel management that IPv6 is going to start being mandatory for some subset of their guests before too much longer. I realize that having something in the contract doesn't mean that we're any more likely to get it. But the fact that it's in the contract makes a statement in and of itself. IAOC, any reason why this couldn't be added, especially given how far in advance you're negotiating with venues? Thanks, 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 support in hotel contract?
From: Joel jaeggli [mailto:joe...@bogus.com] At least, we should start *trying* to get IPv6 service from hotels. We may have a very hard time getting it, but the fact that customers are starting to *ask* for it will help make hotels aware of IPv6. I see no pointing in asking for something that a hotel agent is going to not be able to respond to. if you want a brown M M's crontract you're going to actually have to work with an agent that can grok and then meet your requirements. [WEG]] Joel, I think this is a spurious line of logic. We already have plenty of brown MMs requirements. We bring in our own internet access (sometimes by running new fiber into the building). We ask for the ability to take over the hotel's guest room wireless network or at least the uplink. If we get told no, we try (I hope) to ask about their abilities to cope with an extremely high amount of simultaneous internet usage, we ask lots of questions about the technical logistics of putting on a conference of this size, including using their power and cabling to provide wireless in common areas, interacting with their PA system, using their equipment, etc, and the hotel agent either answers them directly or finds someone who can. We don't generally work with Roscoe's Motor Lodge whose internet service is a single residential AP managed by my brother Darrel. These are international hotel chains, usually with contracts to national/international corporations to professionally manage their guest internet services. If we ask, the response is likely to be well, no one's ever asked for that before... but that should be followed with ...but we'll find out... 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.org On Behalf Of Iljitsch van Beijnum And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. WEG] The problem is that people really can't today, because vendors mostly do not want to implement something for general consumption that is deliberately out of compliance with one or more RFCs. My point in asking the question was that I'm not sure that we need to define what use cases it can/should be used for as much as we simply need to unreserve it and provide some guidance about risks. IMO, the question tree on determining what (if any) course of action to take is something like this: 1) should it be unreserved for *any* reason, or are we just going to stick with the 5735 status quo (Future use)? 2) should it be made into more global unicast space in all or in part? 3) should it be simply unreserved as non-global space with a few caveats about limitations, and leave the use cases to the consenting adults considering its use? 4) should it have a designated use(s) to the exclusion of all not explicitly defined? For #1, My view is that there's no good reason to maintain the reservation, because then essentially no one can use it, and the likelihood of someone coming up with a use for it that justifies holding it in reserve for future use continues to drop. So it's more a question of how we might use the space, and the justification for doing any one of several things. I don't agree that the burden of proof should favor doing nothing. For #2, We know that it is not trivial to get it working for this purpose due to the critical mass of support required. But in some cases where there is tight control over equipment and networks, and a community of interest that routinely communicates between one another across a portion of the Internet, perhaps it's possible. I'm thinking that this makes more sense as a means to buy us time to get IPv6 deployments completed if CGN ends up being bad and the demand for global IPv4 space gets high enough that any tradeoffs associated with using this space as global unicast are deemed acceptable. It may be that we carve the space up so that some of it is tentatively reserved for global unicast, but not released to IANA until some later point to give folks time to fix things. I agree that this one has a lot of risk that it ends up simply prolonging IPv4 without aiding the transition to IPv6. For #3, it's mainly about the caveats to its use - it may not be supported by legacy equipment, we have to carve out 255.255.255.255 (or perhaps something between 255/8 and 255.255.255/24) for broadcast, it MUST NOT show up in the global routing table, etc For #4 - I'm not sure we can come up with enough designated uses at the outset to not have to continue evaluating new ones all of the time and end up needing a WG just to keep up with the discussion. So far, we've heard about its use within a mobile provider in place of RFC1918 as Mobile UE addresses behind a CGN that's already in place today. The folks wanting a shared CGN address pool have already turned down 240/4 because of the limited support within the legacy home router CPE gear. What other potential uses are there? 1918 space in enterprises where all of 1918 is already in use (eg mergers, extranets, etc)? I think Iljitsch's point is a good one - why do we care how people use it? As long as we can give them some guidance about how *not* to use it in order to avoid breakage, I think we're doing our jobs. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM To: Cameron Byrne Cc: IETF Discussion Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC Furthermore, I find this draft's statements about we are trying real hard to deploy ipv6 as not convincing... we are 10 years in on v6, no? I only seriously deployed ipv6 when it was clear the business had to deploy ipv6 there were no other choices. WEG] I really don't think it's useful to discuss penetration of serious IPv6 deployment based on absolute timescale for precisely that reason - until there's a business reason, being visionary or leaders in the space doesn't convince enough money to be shaken loose for that particular budget cycle or planning window. I think it's more useful to look at the progress made since IANA exhaust actually happened and since some testing showed how bad CGN might be, signifying some idea of when this actually got real and at the next 12-18 months in terms of major last-mile providers and their rollout plans. ARIN is looking for the IETF to bless this because they know it's bad, they know this is a step in the wrong direction but the IETF made me do it... WEG] Well, no. ARIN is looking for the IETF to allocate this because they were told by the IAB that they couldn't do it on their own, which sort of removes the teeth from the policy that their membership approved. I think that ARIN happened to be the first forum that the folks suggesting this (very much not new) idea found enough support to move it forward. That said, I don't think that support for the idea is in any way specific to ARIN, it just came up at the right place and time. I think that more and more folks (myself included) are coming to the realization that the need is legitimate, and we sort of need to hold our noses and do it, and focus on making it less harmful rather than blocking it on philosophical grounds. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM To: Cameron Byrne Cc: IETF Discussion Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ? It's hard to know for sure, but I believe there's greater risk associated with use of 240/4 than with a /10 from existing public IPv4 space. That is, I think more software would be needed to allow 240/4 to be used reliably. WEG] you know, the more I think about this line of logic, the more I wonder about it. In essence, the 240/4 problem is that lots of host and router implementations have one or more functions in their input validation code that says 240/4 == invalid thus preventing you from configuring or using it. To my (admittedly oversimplified) view, this is a simple matter of: 1) Search source code for 240 2) Comment out any relevant code you find 3) Recompile, test (changes only), ship I'd be happy for one or more folks who have some experience with the appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would explain where I'm oversimplifying. Now, compare that with the discussion of adding a new set of non-unique address space where you likely have to add code to catch this if you care about the scope of the address that you've been assigned. The authors (or at least one of them) of draft-bdgks maintain that they've discussed this with vendors (http://www.ietf.org/mail-archive/web/opsawg/current/msg01879.html, search for Linksys to find the relevant section of the message) and the vendors seem willing to make code changes in support of this, at least in new gear. Now this doesn't represent a commitment nor a critical mass necessarily, but I'm wondering why 240/4 is so much harder? Also, I don't see why we don't use all of the tools in our toolkit. We're out of IANA space, except for a whole /4, which keeps getting shot down due to the perceived problems with getting global support, when there are probably multiple use cases that absolutely don't require global support. Why haven't we gone ahead and unreserved the space, and then let those interested in using it beat on the appropriate folks to fix it, rather than not even trying? I think that it would be fully possible to caveat use of the space appropriately so that people know what the risks are, but right now it's essentially useless even for those who might be able to try. Seems wasteful, no? I'm willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I'd like to hear support either privately or publicly before I undertake it. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. snip Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. WEG] See that's the point, I think we keep looking at this from a boil the ocean perspective. The question is not, could we use 240/4 as more global unicast space? as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done. The question is, if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it? This idea of limited use puts the impetus on the network/operator itself to identify a use case and force their vendors to confirm support for the space, but it makes it more likely that for that definition of widely used it would be successful. But if IETF/IANA removes the reservation, this means means that people can go in and check in the update to the 3 lines of BSD kernel code (based on a private reply I received on the matter) necessary to remove the block, vendors can stop putting that logic into new devices, etc, thus making it more attractive to attempt to use the space from that point forward. I don't expect this to be a perfect solution for legacy IPv4-only devices, but I do expect that it could have some use, especially when compared with other alternatives. Cameron's example is a case in point - you have a mobile provider who for the most part tells the vendors exactly what features their user devices need to support and they are built to spec, plus a closed network with NAT at the edges that is currently squatting on public space. This means that a large amount (or possibly all) of the devices that would need to support use of this space are within their administrative control, and they would be responsible for updating the code to a version that won't reject 240/4, and they could contain it within their environment by keeping it inside of the NAT border. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
-Original Message- From: Jari Arkko [mailto:jari.ar...@piuha.net] Sent: Thursday, September 22, 2011 5:59 PM To: George, Wes Cc: ietf@ietf.org; draft-weil-shared-transition-space-requ...@tools.ietf.org; draft-bdgks-arin-shared-transition-sp...@tools.ietf.org Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC what I am asking should not be a long piece of text or require a huge amount of analysis. Basically, it should state that the effects are here and that these undesirable implications may be seen, and that this type of IETF specifications need revision. Making those actual revisions should be done in separate documents. WEG] Jari, effects and implications probably wouldn't add much. However, I'm wondering about the value of maintaining two separate drafts (-weil and bdgks) if weil is now being asked to include these things that are mostly already covered in bdgks. Regarding this type of IETF specifications need revision - would you be ok with something like, any existing standard that prescribes different behavior in the presence of RFC1918 (or non-unique) addresses will need to be evaluated. ? If you're wanting something more in-depth than that, I think you're underestimating the work involved. That in and of itself could be a whole draft. If we're going to undertake it, I don't want to do it half-assed, and I would rather not see it be gating to these drafts. But if we are unsure and somehow asked ARIN to make the reservation anyway, the address space would already be nailed down, the knowledge of the actual usable space would leak and everyone would be using it anyway. WEG] I think that this is a minor concern at best. ARIN can be explicitly instructed not to divulge the reservation. This is something that could be reserved internally by ARIN staff without publishing it publicly. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
-Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Thursday, September 22, 2011 6:32 PM To: George, Wes Cc: Jari Arkko; ietf@ietf.org; draft-weil-shared-transition-space-requ...@tools.ietf.org; draft-bdgks-arin-shared-transition-sp...@tools.ietf.org Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases? I don't believe so. I believe that conflating these drafts with RFC-1918 would only serve to further increase the probability that someone would consider this additional space for the same purpose. I would not oppose adding a reference to RFC-1918 that links to these documents as additional related considerations. WEG] adding a reference to RFC1918 that links to... means updating RFC1918, which is why I suggested it. It is not necessary to rewrite/replace/obsolete 1918, and I believe that some of the language that you added to bdgks after our discussion about how these cases are different from 1918 would be fine to help prevent conflation between the two. It's incumbent upon us to ensure that the draft is very crisp in defining acceptable and unacceptable uses of the space and its relationship to existing RFC1918 uses, and I believe that this is quite doable. Regarding increased risk of off-label use, all we can say is don't do this and only do this using the strongest language we feel appropriate. What implementers ultimately decide to do will be driven by their individual business and technical needs more than whether or not we choose to update 1918 formally. There is urgency to make the space available for use, so, the split you describe does not actually help. The urgency is to make this space available before providers start having to deploy NAT444 without it, or, at this point, more accurately, to limit the amount of NAT444 deployed using GUA, Squat Space, or any of the other alternatives that these drafts show are a significantly worse alternative vs. this /10 shared transition space. Pushing draft weil back as you describe would be extremely harmful IMHO. WEG] this is exactly the type of hand-waving I'm trying to avoid when discussing whether there's actually this much urgency and what is driving it. While I've heard good support for this reservation of shared transition space, and the concern that if we screw around for too long the address space will be gone, I have not heard anyone saying I need this within the next few weeks (or even months) or I'm going to have to do something else. It's been over a year since this round of discussion started (with draft-weil-opsawg-provider-address-space-00), and yet no one has unequivocally said I'm being materially impacted by your failure to get this done *right now*. As may be obvious, I work for a broadband residential ISP. This idea of when/if we have to do CGN is pretty important to us and to my colleagues in the industry right now, and I'm not hearing event horizons earlier than 12-18 months. If anything, people are starting to look at this and say, wow, this is going to suc k, I wonder how long I can hold it off? So I simply don't see the necessity for short-circuiting the process. Even if the timeframe is more like 6 months, we still have time to do this correctly. I speak for no one but myself, but if you fall into the category of needing this address space ASAP, you'd be wise to speak up to lend credence to the perceived sense of urgency. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
-Original Message- From: Benson Schliesser [mailto:bschl...@cisco.com] Sent: Friday, September 23, 2011 1:21 AM To: Jari Arkko Cc: draft-bdgks-arin-shared-transition-sp...@tools.ietf.org; ietf@ietf.org; draft-weil-shared-transition-space-requ...@tools.ietf.org; George, Wes Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC Given constraints on existing IPv4 inventory (i.e. we're running out of the stuff), our desire has been to have draft-weil proceed without delay. snip However, I would like to make sure we don't lose sight of the need for some urgency with draft-weil. WEG] I won't repeat my comments to Owen here, but I will note that if the concern is about the availability of the address space, my suggestion would allow us to ensure it's available without any artificial (?) sense of urgency over getting the documents to a form that we're happy with. 1) Does IETF recommend the practice of inferring address scope in IPv4 based on address/bit value (the actual numbers), and then using this to trigger different behavior based on that inferred scope? We could probably have varying opinions on this, but I think the reality is that software *does* depend on specific bit values, for better or worse. I propose we spend our effort elsewhere, we can't change the situation. So what would this translate to, in terms of updates to draft-weil and/or draft-bdgks? I think it's safe to say that address-inferred scope will break in a number of circumstances - basically, every time an address+scope pairing is not what the implementation expects. And this concern exists for any new reservation that we make for scope purposes. As you pointed out, draft-bdgks makes note that either GUA or the Shared Transition Space (STS) will have a similar effect on existing implementations when deployed behind a NAT. The only way to avoid these impacts is to use RFC1918 space, because it's already well-known, which frequently is not an option (for reasons described in draft-bdgks). WEG] my thought is that it's useful to say exactly that - this exists, so if you're going to do it to avoid breakage, know that there's now additional space to be aware of, especially if we go the route of updating RFC1918. I do appreciate the clarification of the difference between deriving address scope based on bit value for defined-scope values vs. assuming that everything not included in that defined-scope of private space could be unique and global, but I'm not sure that particular distinction is important in the context of these drafts. Similarly, the idea that squatting on other GUA space has a similar problem is mostly interesting as a justification for doing STS instead of squatting, and so that idea is probably minimally important in the grand scheme of things. 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases? My personal concern was with making the impacts clear, but I think other people in the IESG have commented on the updates aspect. I personally think it would be useful if draft-weil updated RFC 1918, because then when someone looks up RFC 1918 from the web site they would see the Updates: header and go read the new RFC as well. We should be somewhat careful with this. I respect Wes' comments around updating existing documents etc. But we would need to update RFC1918 in a way that reflects the difference in scopes. The STS may have similar semantics as RFC1918 space, in that it's non-routable on the Internet etc. But it is not meant to be used in the same scope. While it would be appropriate (when possible) to use RFC1918 space inside a CGN, it would not be appropriate to use STS in many of the same places RFC1918 space is used. WEG] Agree, the wording and the distinction between the use cases are important, but I believe it is possible to articulate it properly. I think that crispness and clarity is required anyway, in order to clearly explain why these use cases are not simply solved by use of existing RFC1918 space. BDGKS is getting there, so let's refine that to address both your concern and mine. 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
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, September 22, 2011 2:35 PM To: ietf@ietf.org; draft-weil-shared-transition-space-requ...@tools.ietf.org Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work: - what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444) - what kinds of application practices may be affected - what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc) Jari - It's unclear from your statement if you're proposing adding the above to this draft or to a subsequent draft. To respond to your concerns and recommendation, I think that there are three separate issues here that merit some discussion: 1) Does IETF recommend the practice of inferring address scope in IPv4 based on address/bit value (the actual numbers), and then using this to trigger different behavior based on that inferred scope? 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases? 3) Independent of consensus on the state of the *draft* directing it to happen, is there consensus on the *idea* that the /10 of IPv4 space should be reserved as shared transition space? My own opinion on each question: 1) We do link the scope and bit values pretty closely in IPv6. Multicast (Class D) is definitely a scope link, and RFC6250 doesn't say otherwise, though it would have been a recent opportunity to clarify our position. My sense is that there are a number of standards (notably 3056) that recommend specific behavior when private-scope or non-unique addresses are used, but the terms behind a NAT, RFC1918 addresses and private addresses are often used interchangeably, thus reinforcing this link between scope and value. However, draft-bdkgs section 4.1.2 implies that this is not a valid assumption to make, but your concerns over what breaks and how to test support the idea of a link, which is why I bring up the question. I think that it might be useful to formalize this link, but I'm not sure if that belongs in these drafts, and I don't think that it's gating to them moving forward. 2) I really believe that one or both drafts should either be an update or -bis document for RFC1918. I believe that they are in essence documenting additional use cases for private scope address that are beyond what was covered in RFC1918, with the added requirement that they cannot conflict with the existing space. While the address space and use cases are not interchangeable for reasons documented in draft-bdgks, most of the same considerations regarding usage (how not to break things) apply to both. Formally updating RFC1918 would at least give implementers a warning that there is new space to test for wherever 1918 is referenced in an existing standard and should therefore address your concern. Based on your proposal, if we don't formally update 1918, we end up having to go through existing standards to find places where the authors used RFC1918 interchangeably with non-unique addresses or private-scope address space. We would then have to evaluate if they used this as an indicator to recommend a different behavior in cases where one can infer the address scope based on the bit value and decide whether those cases apply to this new space or not. I think that using 1918 as a baseline and only documenting items which are unique considerations for this space and application represents a lot less work than what you're proposing above, whether it's part of this draft or its own work. 3) The reason I bring up consensus for the idea rather than the document is that there seems to be some urgency behind getting *something* approved to make the allocation happen, but it seems to be driving this strange behavior to push through incomplete documents and sort out the details in subsequent drafts. Assuming that it is in fact necessary to get the allocation completed rapidly, I'd rather see us split the logistics of making that happen from the process required to produce consensus documents. This may be as simple as IAB or IESG giving ARIN (and/or IANA) provisional clearance to allocate or reserve the space on the belief that there is consensus to make the reservation, but that we want our documentation in order before it is made public for use. That removes any pressure to push the documents through before they are ready, while still ensuring that the address space is available when we are happy with the documentation. If for some reason the document fails to achieve consensus in its final form,
