Re: resignation business
On Mon, Apr 20, 2009 at 05:17:31PM +0200, Francis Dupont francis.dup...@fdupont.fr wrote a message of 28 lines which said: this was and is the rule but because of typewriters the rule was suspended during the 20th century. Now typewriters are in museums and current century is 21th. BTW accents can be necessary to avoid some ambiguities (cf 2nd reference) so the rule (in this case :-) is justified. That's true but it is completely unrelated to the Morfin troll and his various avatars. He uses French composed letters as he uses the Arabic Tatweel or any other thing that goes through his mind but he knows nothing about it and does not care. As Andrew said, if we discuss subtle points in writing French or Arabic, goto IDNAbis WG. If we discuss the resignation campaign of He-Who-Must-Not-Be-Named, the plenary list is not a bad place. Just remember there is no relationship between Morfin's claims and any sort of reality (even a virtual one). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
You are right money is more operation related not technical side. However, I believe that this is also one of the most important factors and popularly has been used for determining an interface with an (access) network among multiple active interfaces automatically and dynamically. And, the mechanism to adopt or apply like this network characteristic into the routing policy on the network environment of simultaneous use of multiple interfaces may be deeply related with technical side regarding simultaneous use of multiple interfaces though. == such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is Money or else. and also if it is not flat rate based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars. For instance, for a dual-mode device at home with WiFi and IP over cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of various network characteristics in it would be the major factors to determine either WiFi or cellular for packet transmission. My point here is how to present those factors into the routing policy in order to determine a suitable interface with the type of *DATA or PACKET* for the transmission would be one of the important technical side to be discussed in terms of simultaneous use of multiple interfaces. == Reply same as the above However, according to Hui, it seems to be out of MIF scope described in the charter. BTW, again regarding MIF scope, I am wondering if we have already gone through a scenario for simultaneous use of multiple active interfaces based on a network environment with necessary associated network entities (from enabling attachment of multiple access networks to processing a packet transmission over the access networks from the link layer up to the transport layer) in order to identify the MIF scope (presented in the charter). If it has been already done or everyone understands clearly in terms of the MIF scope, it is OK. Otherwise, it would be good to practice it in order to clarify the MIF scope in the charter. == Current charter says best current practice, and problems tatement, those work will be done after the re-charter. thanks -Hui Giyeong -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: April 19, 2009 11:40 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-...@ietf.org; dhc WG; black_da...@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language. thanks -HUi 2009/4/15 Giyeong Son g...@rim.com: I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they money to use the connection (e.g. WiFi vs. cellular), time to spend for the transmission, reliability of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; black_da...@emc.com; dhc WG; gen-...@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on
Re: WG Review: Multiple InterFaces (mif)
Hi, Jari, What I suggest is like the below: Connections to Multiple Networks (mif) Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD thanks -Hui 2009/4/21 Jari Arkko jari.ar...@piuha.net: Hui, I'm not sure if I understood your comment about the WG name correctly. We cannot change it at this stage easily. So lets just keep it as is. Please find below the full charter proposal, with the suggested changes folded in from you and others. Jari Multiple InterFaces (mif) Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms rdr...@cisco.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: TBD Mailing Lists: General Discussion: m...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Keith, I certainly agree that it's challenging to attack the generalized version. However, if you try to solve each version of this problem separately, the result will be even more complex, less workable, and less realistic than if you try to look at it from a broader view. There's a strong potential for those different solutions to collide with one another. Indeed. And I want to remind everyone that this charter is only about _problem definition_ and _documentation of existing solutions_, not about development of new solutions. The scope at this stage needs to be large, even if we later find out that we need to or can develop a specific extension of, say, DHCP. At that point the group can focus on a narrow aspect, or perhaps even be moved to existing WGs. But we are not in that stage yet. Or to put it another way, if you define a solution to a narrow version of the problem, it might not actually solve anything in the real world, and the WG's work will have been wasted. And from the POV of the application, or the transport layer, it really doesn't matter much _why_ the host (or peer) has multiple addresses - it still has to deal with them. As for whether attacking this in full generality is well beyond what we can manage: Based on previous work that I have done in this area, I suspect that this is exactly the case. Which is why I think that it should be reasonable for the WG to look at the problem and come back and say we haven't identified a good solution to this problem, and the best practices that we can recommend are to minimize the cases where a host or app has to deal with multiple addresses for itself or its peers. Of course, a better result would be for the WG to say we recommend that the use of multiple addresses per host be limited to these specific cases, and avoided in other cases... along with specific recommendations for networks, stacks, APIs, applications, etc. I think that this kind of output would be the most useful that the WG could produce. But it won't be able to produce a reasonable output if it looks at the problem through a narrow aperture. Yes. (Maybe this should really be in IRTF?) I think the proposed scope fits very nicely to IETF: we are documenting what the problem is and what various real-world implementations have done about it. (If we later decide that the real-world techniques are lacking and want to develop a magical solution that solves this problem in all situations, then it is probably a good idea to start a research project... but we are not there yet.) Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
There has been some discussion on whether the key issue is merging configuration from multiple sources (the DHCP view), multiple interfaces (the original view), multiple default routers (the routing view), multiple addresses (the IP layer view), multiple administrative domains (the operational view), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Keith, I've considered your points and continue to disagree. I'm mostly replying in the interest of judging consensus. I believe that the primary use cases identified in the MIF BOF are use cases that are not going to go away. I think that saying avoid multiple addresses is likely to be the same kind of head-in-sand thinking that caused us to get where we are today with a number of areas where there is a disconnect between what the market wants and what we're willing to include in our engineering model. Yes, the results of delivering what the market wants may be more complicated than our conceptually pure model. It will be less complicated and work better than ignoring the problem and letting the market come up with something. So, I'd prefer to make sure that our problem analysis is narrow enough that we're more likely to come up with an answer as useless as don't do that. We may get an answer of here are the issues to consider, here are points on a spectrum and the problems we introduce, but I think we can only do that if we limit the scope somewhat. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Sam Hartman wrote: Keith, I've considered your points and continue to disagree. I'm mostly replying in the interest of judging consensus. I believe that the primary use cases identified in the MIF BOF are use cases that are not going to go away. I think that saying avoid multiple addresses is likely to be the same kind of head-in-sand thinking that caused us to get where we are today with a number of areas where there is a disconnect between what the market wants and what we're willing to include in our engineering model. Please note that there is a subtle but important difference between saying avoid multiple interfaces and don't do that under any circumstances. Maybe avoid is too strong a word and I should have used discourage. I agree that the problems presented by multiple addresses per host are unlikely to go away. They are being driven by several independent factors. At the same time it needs to be made clear that adding addresses to a host does come with a cost, and (e.g.) network admins who wish to solve problems by adding prefixes to their networks (whether this be for multihoming or interconnection with private networks or whatever) need to consider the impact that this will have on applications. I still don't think that we need to consider this problem from only one angle. If we do that we will get a solution that only makes sense from one angle. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org
On 2009-04-21 00:00 Sam Hartman said the following: ... In conclusion, I do agree that abuse management for tools.ietf.org is necessary. I simply don't believe that assuming all our list/spam policies apply makes sense. I think that considering those policies and especially the principles behind them (good luck figuring out what those are) would be a good idea. That seems reasonable to me. I also don't think we need to spend a bunch of time defining policies; until the tools maintainers do something we disagree with, I see no need to spend a lot of time on it. WFM. Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Sam, We may get an answer of here are the issues to consider, here are points on a spectrum and the problems we introduce, but I think we can only do that if we limit the scope somewhat Point taken. But can you bring that to a concrete level by stating if something needs to change or be removed from the scope as defined by the charter? I'm including the latest charter proposal below for your convenience. Please remember that this charter and initial scope of the WG involves description of the problem and existing solutions; I do agree that if and when we ever get to developing a new solution, significant scope reduction seems likely. Jari Multiple InterFaces (mif) Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms rdr...@cisco.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: TBD Mailing Lists: General Discussion: m...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Jari Arkko wrote: There has been some discussion on whether the key issue is merging configuration from multiple sources (the DHCP view), multiple interfaces (the original view), multiple default routers (the routing view), multiple addresses (the IP layer view), multiple administrative domains (the operational view), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? 1. I really think that the emphasis on attachment to multiple networks is too narrow, as this is far from the only source of the problem. As long as the WG is just trying to understand the problem and identify existing solutions, it seems appropriate to broaden the scope to consider the more general problem of multiple addresses per host. 2. I also think that, when considering the effect on applications, it needs to be explicitly pointed out that p2p and distributed apps need to be considered separately from client-server apps that many people regard as representative. More generally I think that various kinds of effects need to be considered (i.e. not just the effects on applications) and it would be very helpful if the charter could lists some examples of these as illustrations of the breadth of scope. That would minimize the potential for the WG to start off with many participants thinking _the_ problem is X when the actual problem is much broader and hopefully get the WG in the mode where it tries to enumerate the various problems and impacts rather than to try to nail down _which_ problem it is and ignore the others. 3. I am a bit concerned by the charter's mentioning of BCP documents as a possible output from the WG. I thought I had seen language in the charter text saying that the group should write a BCP, but either I was mistaken or that language has since been removed. But there's still a BCP mentioned as a deliverable in the milestones. My concern is that the WG will take this as license to try to define best current practice, which I think is somewhat of a conflict of interest with trying to identify the problem - especially given the broad scope. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Keith Moore wrote: I think it's interesting that you appear to consider multiple addresses per host a narrower problem than multiple network connections per host, whereas I consider the latter to be a subset of the former. Yeah - I do, too. To expand on this a little, I think it's useful to frame this in terms of policy (which seems to be the direction it's already headed) and identify which policies are attributes of which entities. There are policies that apply to the network device (routing, for example), policies which apply to an interface (filtering and maybe QoS), and policies which apply to a network. I don't think the distinctions are always all that clean but I do think it's a useful exercise to try to get some clarity around what belongs to whom. If nothing else it might help sort out what's a tractable problem and what isn't. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Overall, I think the charter is good enough and we should ship it. A few minor comments. Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. Nit: this last point isn't really accurate. Having two routers on a network doesn't mean one is attached to multiple networks. The multiple is at least one hop away in this case... For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. Specifically, issues arise (only) when the information is in some sense contradictory, forcing the host to make decisions about which object to use under various circumstances. This is the root cause of all the problems being discussed. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts, document existing practice, and make recommendations about best current practice. Charter does seem to say here that BCP documents will be an output. That goes beyond just describing the problem. Personally, I'm skeptical that there is much in this space being done today that would qualify as a BCP recommendation. But that is something that we can figure out definitively when the WG tries to produce such a document and we see what they are actually recommending. So, as long as it is clear that one possible outcome is that no BCP is possible at the current time, I'm OK with going forward. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: resignation business
2009/4/19 Fred Baker f...@cisco.com I assume that the relevant procedures were applied, etc. Is there any action that is warranted in other domains, or should this be left to brew in your particular teakettle? Dear Mr. Baker, If you mean that usual ad-hominems applied against posters without a warning of the Chair, and that their posting rights were terminated not suspended, etc. I suppose these are the procedures of the new IETF, described by ISOC as a corporation consortium subject to Platinum member influence. Anyway, I only reacted to a nasty mail who did not even understand who/what it was standing for. IRT. the technical issues involved: (1)I belong to the fra...@large IDNA group, the same as other members of the WG-IDNABIS belong to the ASIWG or to Unicode. The same as the ASIWG we do not support the declared WG overwhelming consensus over the TATWEEL case. Not because we are experts in Arabic, but because we think that such a decision belongs to Arabic experts. (2)I can report that the total consensus (same rule as ASIWG) to solve this issue is to follow: - the advise given by Paul Hoffmann: wait for the IDNA2008 IETF/LC if it happens sometimes - the recommendation given by Andrew Sullivan to understand a key issue - the remark of Michel PY : write French before changing its spelling - the technical positions recently taken by Pete Resnick and John Klensin - the WG Charter which says: The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: ... (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol). We want independence and no character mapping in the protocol, what would be immediately opposed by usage leading to an Internet balkanization. To the contrary, we committed to get IDNA2008 as the core/default of the usage evolution we work on. For those wanting to understand better: there are two fundamental Internet architecture and economy issues at stake through the way IDNA is or is not implemented. They are the introduction of the missing presentation layer and its financial impact on the domain name market. Up to now we respected the principle of the IETF as an individuals’ organization, we protected the users against the some dangerous standardization bias, and tried to explain because we did not want to take the risk of an non concerted move. We have observed that the IETF is now “a small and large corporation” issue (cf. ISOC). That money plays openly its role as warned by IAB’s RFC 3869. That it is clearly intended to harm our interests and those of many, for erroneous or bad reasons we do not want to discuss, as we are only interested in facts and the adequate operations of our own systems. That the decision which, in our opinion, will balkanize the Internet has already been taken and fully exposed. This means that our job is not anymore to prevent but to fight it and to document a stable, open, and innovative alternative anyone may chose to oppose, follow, copy, or enhance. Marie-France Berny Chercheur On Apr 19, 2009, at 4:56 PM, SM wrote: At 13:09 19-04-2009, Iljitsch van Beijnum wrote: It would be very much appreciated if someone could explain this resignation business that recently spilled over into the IETF discussion list. Where did all of this start? This started in the IDNAbis WG. The WG Chair sent a message to a participant warning him that his posting rights may be removed [1]. Another participant was also warned [2]. The WG Chair then removed posting privileges for that participant and another one [3]. Regards, -sm 1. http://www.alvestrand.no/pipermail/idna-update/2009-April/004453.html 2. http://www.alvestrand.no/pipermail/idna-update/2009-April/004478.html 3. http://www.alvestrand.no/pipermail/idna-update/2009-April/004489.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Are you saying multiple addresses on one interface of the host? thanks -Hui 2009/4/21 Keith Moore mo...@network-heretics.com: Jari Arkko wrote: There has been some discussion on whether the key issue is merging configuration from multiple sources (the DHCP view), multiple interfaces (the original view), multiple default routers (the routing view), multiple addresses (the IP layer view), multiple administrative domains (the operational view), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? 1. I really think that the emphasis on attachment to multiple networks is too narrow, as this is far from the only source of the problem. As long as the WG is just trying to understand the problem and identify existing solutions, it seems appropriate to broaden the scope to consider the more general problem of multiple addresses per host. 2. I also think that, when considering the effect on applications, it needs to be explicitly pointed out that p2p and distributed apps need to be considered separately from client-server apps that many people regard as representative. More generally I think that various kinds of effects need to be considered (i.e. not just the effects on applications) and it would be very helpful if the charter could lists some examples of these as illustrations of the breadth of scope. That would minimize the potential for the WG to start off with many participants thinking _the_ problem is X when the actual problem is much broader and hopefully get the WG in the mode where it tries to enumerate the various problems and impacts rather than to try to nail down _which_ problem it is and ignore the others. 3. I am a bit concerned by the charter's mentioning of BCP documents as a possible output from the WG. I thought I had seen language in the charter text saying that the group should write a BCP, but either I was mistaken or that language has since been removed. But there's still a BCP mentioned as a deliverable in the milestones. My concern is that the WG will take this as license to try to define best current practice, which I think is somewhat of a conflict of interest with trying to identify the problem - especially given the broad scope. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Isms] Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) to Proposed Standard
On March 9, 2009 Alan DeKok wrote... Security Section: There are good reasons to provision USM access so supplement with AAA-based access, however. NIT: This doesn't appear to be a sentence. Yeah. Let's see what that was supposed to say... I think it's: There are good reasons to provision USM access to supplement AAA-based access, however. ISMS decided to handle this late WG Last Call comment as IETF Last Call input, so I'm re-posting the message now. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mif] WG Review: Multiple InterFaces (mif)
I think that there are many working groups, standard bodies and technologies who focuses on multiple addresses per host. So, I'd also like MIF to concentrate on simultaneous connections to multiple networks (or simultaneous use of multiple connections with multiple networks). I believe that most of cases for simultaneous connections to multiple networks require multiple addresses. However, it does not need to be the main focus, but MIF NEEDS it. So, I would like to say that multiple addresses per host needs to be addressed for simultaneous use of multiple connections. Therefore, I think working on MIF problem should be more than just focusing on multiple addresses. Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Sam Hartman Sent: April 20, 2009 6:09 PM To: Keith Moore Cc: Ted Hardie; Adrian Farrel; mif; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Keith == Keith Moore mo...@network-heretics.com writes: Keith It seems to me that the general problem is not multiple Keith interfaces, but multiple addresses per host. It doesn't Keith matter (much) whether those addresses result from multiple Keith physical interfaces, a combination of physical and virtual Keith network interfaces, multiple prefixes being advertised on Keith the network attached to any particular interface, or even a Keith mixture of v4 and v6. Keith So that might have some impact on the name, particularly if Keith you want to attract the breadth of interests whom this Keith affects. Something like Hosts Addressed Multiply (HAM), Keith perhaps? I'd actually appreciate focus on the multiple interfaces (or multiple network providers) problem. I think that attacking this in full generality is well beyond what we can manage. I think even a focused problem may prove challenging. ___ mif mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mif - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mif] WG Review: Multiple InterFaces (mif)
No, I am also interested in multiple network connections per host, but my main interesting topic is *simultaneous* if multiple networks (or multiple interfaces) are available. Sorry for this confusion. Giyeong -Original Message- From: Keith Moore [mailto:mo...@network-heretics.com] Sent: April 21, 2009 10:21 AM To: Giyeong Son Cc: Sam Hartman; Ted Hardie; Adrian Farrel; mif; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Giyeong Son wrote: I think that there are many working groups, standard bodies and technologies who focuses on multiple addresses per host. So, I'd also like MIF to concentrate on simultaneous connections to multiple networks (or simultaneous use of multiple connections with multiple networks). I believe that most of cases for simultaneous connections to multiple networks require multiple addresses. However, it does not need to be the main focus, but MIF NEEDS it. So, I would like to say that multiple addresses per host needs to be addressed for simultaneous use of multiple connections. Therefore, I think working on MIF problem should be more than just focusing on multiple addresses. I think it's interesting that you appear to consider multiple addresses per host a narrower problem than multiple network connections per host, whereas I consider the latter to be a subset of the former. I suppose that makes a good illustration of why I really want the WG to explore this issue from multiple points-of-view. Keith - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Excerpts from Giyeong Son on Mon, Apr 20, 2009 11:35:14AM -0400: For instance, for a dual-mode device at home with WiFi and IP over cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of various network characteristics in it would be the major factors to determine either WiFi or cellular for packet transmission. My point here is how to present those factors into the routing policy in order to determine a suitable interface with the type of *DATA or PACKET* for the transmission would be one of the important technical side to be discussed in terms of simultaneous use of multiple interfaces. I think it's partially in scope. I think of MIF as figuring out how to resolve conflicts or gaps in information and storing information in a way that it can be useful to forwarding. It does not cover how forwarding would actually use that information. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OPSEC] [tcpm] draft-gont-tcp-security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom.Petch wrote: ... If you're here for a rubber stamp, you came to the wrong WG ;-) Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and when it comes to advice on this issues, I believe it's even more credible. Ask the question in bugtraq or full-disclosure, and that's most likely the conclusion you'll get to. Which is for me the crux of the issue. This document is a done deal, let it go. If the document is a done deal, it should not be published as an RFC - individual or otherwise. If the document is being proposed as a WG item, then modifying it to be in line with the WG's viewpoint is not only appropriate, it is required. What that viewpoint is will be determined in the WG by consensus, but assuming that we cannot modify the document is a non-starter. On the other hand, looking at the references, I see that while much of it is based on IETF RFC, there are also a number of IETF I-D cited and I think that our efforts would be better spent progressing these to RFC, after which, this document may be worth revisiting. Not all of those RFCs or IDs are standards track or BCPs; some are informational, and many give more conservative advice than this document does. If this document is intended to reflect the sum of current IETF views, then it is *definitely* not done. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknuCFQACgkQE5f5cImnZrs5iwCgz3/mNjZDMTgXxg9gIK4zdNf0 ctIAoPaNNYvne2dJcolon9Bjx1BREZDe =kaPP -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Melinda Shore wrote: Keith Moore wrote: I think it's interesting that you appear to consider multiple addresses per host a narrower problem than multiple network connections per host, whereas I consider the latter to be a subset of the former. Yeah - I do, too. To expand on this a little, I think it's useful to frame this in terms of policy (which seems to be the direction it's already headed) and identify which policies are attributes of which entities. There are policies that apply to the network device (routing, for example), policies which apply to an interface (filtering and maybe QoS), and policies which apply to a network. I don't think the distinctions are always all that clean but I do think it's a useful exercise to try to get some clarity around what belongs to whom. If nothing else it might help sort out what's a tractable problem and what isn't. Policies are certainly an interesting set of questions raised by these circumstances. But they do not stand on their own, they interact with other concerns. I don't see any benefit in fragmenting the discussion so that policies are discussed separately from, say, application level issues, or network administration issues, or host administration issues (note that the latter two are not the same), etc. To the contrary, I don't think a policy discussion can be realistic unless it's held in light of those other concerns. And I don't know why you think that the discussion is already headed toward policy when the group isn't even chartered yet. Certainly the discussion on the IETF list isn't already headed that way. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Keith Moore wrote: And I don't know why you think that the discussion is already headed toward policy when the group isn't even chartered yet. Certainly the discussion on the IETF list isn't already headed that way. You can call it foo for all I care, but much of what's been discussed so far is policy. From the proposed charter: A host connected to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. That's all policy. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Keith, Melinda, I believe you are talking about an issue that is distinct from what was discussed in the BOF. My personal preference is to see work on what was discussed in the BOF. However to respond to Jari, I do not have have concerns with the charter as written. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Gen-art] Gen-ART review of draft-ietf-rmt-pi-norm-revised-10
Just to let people know, version 10 of this specification addressed my questions from version 09, and I didn't see any new issues in text that was added in this version. Thanks, Spencer I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-rmt-pi-norm-revised-09 Reviewer: Spencer Dawkins Review Date: 2009-04-08 IETF LC End Date: 2009-04-15 IESG Telechat date: (not known) Summary: This specification is almost ready for publication as a Proposed Standard. I have one minor issue that I'm pretty sure is just a missing word, but it's in a normative sentence, so clearly should be fixed before publication. (Please note - this is a previously-published Experimental specification going to Proposed Standard, so I spent most of my review cycle looking at NEW text) Major issues: None noted. Minor issues: 4.2.3.1. NORM_CMD(FLUSH) Message Note that receivers also employ a timeout mechanism to self-initiate NACKing (if there are outstanding repair needs) when no messages of any type are received from a sender. This inactivity timeout is related to the NORM_CMD(FLUSH) and NORM_ROBUST_FACTOR and is specified in Section 5.3. Receivers SHALL self-initiate the NACK repair process when the inactivity has expired for a specific sender Spencer (minor): I'm guessing s/inactivity has/inactivity timeout has/, but something needs help here... and the receiver has pending repairs needed from that sender. With a sufficiently large NORM_ROBUST_FACTOR value, data content is delivered with a high assurance of reliability. The penalty of a large NORM_ROBUST_FACTOR value is the potential transmission of excess NORM_CMD(FLUSH) messages and a longer inactivity timeout for receivers to self-initiate a terminal NACK process. Nits/editorial comments: Abstract This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This document obsoletes RFC 3940. Spencer (nit) - Requirements language is described before the table of contents - the RFC has it after the table of contents, which is where I would have expected it. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119]. This also isn't quite the suggested boilerplate for 2119, according to idnits 2.11.08, but the difference is that the draft text specifies [RFC2119], not RFC 2119 - that should be fine. ___ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
On Apr 21, 2009, at 2:04 PM, Melinda Shore wrote: You can call it foo for all I care, but much of what's been discussed so far is policy. From the proposed charter: A host connected to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. That's all policy. My shaman once said For God, everything is just a question of policy. But, we need to reduce this problem to a more mortal scope, and I'm not quite certain that the proposed charter text accomplishes this goal. There's a tremendous amount of complexity inherent in the problem. I suspect as worded that it is roughly isomorphic to the peering problem, with all the business-driven policy consideration that entails. Consider that peering policy is often driven by things that are well beyond the scope of protocol. Its potential range of expression is unlimited; in fact driven by a natural-language contract and heuristic operations on underspecified constraints derived from that natural- language contract. The only alternative I can see here is to try and reduce the range of expression. One such approach might be to develop a policy language having the property of an algebra, so that policies can be written and interpreted in a defined manner, and so that the combinations and interactions of multiple policies can be evaluated and applied predictably in automata and simulation. This requires a substantial body of precursor work: What things should the language be able to express? What combinatorial operations are required? What are the relative priorities of linguistic statements? What sorts of fundamental things should the policy describe (we have things like route selection, prefix manipulation, addressing, access rules, name services, name defaults, and so on to consider as options). Even with this sort of model, I am not confident at our ability to achieve success, at least without even more substantive reductions in the scope of the effort. Can we narrow it down some more? -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Dean Willis wrote: Consider that peering policy is often driven by things that are well beyond the scope of protocol. Its potential range of expression is unlimited; in fact driven by a natural-language contract and heuristic operations on underspecified constraints derived from that natural-language contract. Good heavens - I was not proposing, nor would I propose, that what's needed here is the development of a policy language. If the word policy is making people uncomfortable perhaps it would be better to drop it in favor of properties. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mif] WG Review: Multiple InterFaces (mif)
At the end of the day it doesn't matter what you call it, the fundamental problem is that the widespread assumptions about a single-interface / single-address are not realistic in today's Internet, and there are independent policy realms influencing each end system. The available tool set is built on a single-interface / single-policy-realm model, so it routinely fails. Any effort that does not recognize that there needs to be a way to describe the policy attributes is going to create a short-sighted mess. Keith is also right, in that aspects of the problem from the application perspective still fail even when there are multiple choices from the same administrative entity. That said, there should be a way to describe the local policy attributes to sort between choices from a common administration. The bottom line is that we need to stop the fantasy that there are -any- global attributes. This alone is the source of most of the confusion, and if removed it would be fairly obvious to most people how to sort between the choices. The IPv6 address selection effort is suffering from the same 'merged global attribute' mindset, and needs to be able to describe policy attributes to each source of addresses, then a hierarchy for sorting through them. I do object to having the charter spend any more time on IPv4 than to simply document current practice as a reference. It is long past time for the IETF to stop wasting cycles on a dead end, and this should be one place where we say 'it just doesn't work in IPv4, so move to IPv6 if you need multiple interfaces'. Other than that I think it is fine. Tony -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore Sent: Tuesday, April 21, 2009 3:09 PM To: Dean Willis Cc: IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Dean Willis wrote: Consider that peering policy is often driven by things that are well beyond the scope of protocol. Its potential range of expression is unlimited; in fact driven by a natural-language contract and heuristic operations on underspecified constraints derived from that natural-language contract. Good heavens - I was not proposing, nor would I propose, that what's needed here is the development of a policy language. If the word policy is making people uncomfortable perhaps it would be better to drop it in favor of properties. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Folks - It seems that folks are considering two related, yet still orthogonal topics for inclusion in the MIF charter: - Conflicts between configuration parameters. - Issues with address selection. (These two topics also span issues with multiple network connections, which has been brought up as well.) The first topic talks about a problem of the network stack: How are conflicting parameters for host or interface configuration reconciled with each other, or, if not reconcilable, which parameters win? This issue may come up if configuration parameters are received from multiple sources, such as from any set of default routers, DHCP servers, and manual configuration. Hosts with multiple interfaces are more likely to be confronted with this issue, but the issue may also come up for hosts with a single interface. The second topic talks about a problem of applications: When initiating a connection, which pair of source and destination address (and consequently which pair of interfaces) should be used? Again, this issue may come up independently of whether a host has one or multiple interfaces -- though the presence of multiple interfaces makes the issue more difficult to tackle and, since it determines which interface pair is used, also more important. Both topics need work; the arguments that have been put forth clearly show this. And we have to make a decision whether to tackle either or both of these topics in the MIF working group. Personally, I feel that the workload of both topics will be manageable for a single working group. Though, if we decide to tackle both, then the working group charter would have to explicitly list these topics as two separate ones. This would require some, but not much, rewriting of the charter. In any case, the working group acronym could actually stay as is. If the working group will tackle both topics, we could re-use the acronym for Multiply Interface Addressing and Configuration. If only one of the topics will be tackled, then we could just remove from this the words and Configuration or Addressing and, respectively. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
