Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org
Russ == Russ Housley hous...@vigilsec.com writes: Russ, I'm failing to understand how your comments are responsive to the points I made. One of the things I said is that I was not specifically speaking to the questino of whether removing Dean from the aliases was reasonable. However your entire response focused on Dean. My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. Your response is all about whether it is reasonable for Dean to post to these lists. ___ 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 Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote: My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. In my opinion, it is. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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
Andrew Sullivan wrote: On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote: My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. In my opinion, it is. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
Sam: I am assuming that you are referencing this paragraph from you original note: In addition, the IETF policies on spam control clearly do not apply to closed lists. Thes policies assume an archive that posters can check in order to see if their postings went through. If you are going to apply spam policies to these aliases as if they are mailing lists, then please point me at the public archives you set up for these aliases so I can see if my postings make it. I do not think we are talking about the spam policies. We are talking about whether the PR-Action for these mail aliases is a suitable interpretation. Russ At 04:18 PM 4/17/2009, Sam Hartman wrote: Russ == Russ Housley hous...@vigilsec.com writes: Russ, I'm failing to understand how your comments are responsive to the points I made. One of the things I said is that I was not specifically speaking to the questino of whether removing Dean from the aliases was reasonable. However your entire response focused on Dean. My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. Your response is all about whether it is reasonable for Dean to post to these lists. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
some level of generic network characteristics benefit for the user. one example could be that routing metric may need to be updated to align with various kind of access technologies. -Hui 2009/4/17 Giyeong Son g...@rim.com: Again as I mentioned, in order to prepare or build an efficient routing policy and to select an efficient connection/interface, it would be necessary to identify, classify and/or prioritize underlying network characteristics or information of the attached networks. In addition, as many network characteristics which are essential to be used for simultaneous use of multiple interfaces are not generic forms (e.g. SSID only for 802.11), these network characteristics may require a mechanism to make them be associated with generic (formed) elements used for routing policy preparation and routing decision. Therefore, if MIF can provide an efficient guideline or mechanism for associating, it would be really amazing. I believe, the current IP network related protocols and standardized technologies may not be enough to support that on multiple interface network environment. I think each vendor, carrier, service provider and/or technology, which utilizes or supports simultaneous use of multiple connections/interfaces, may have their own proprietary mechanism in terms of gathering of network characteristics of each interface/access network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their mapping mechanism with generic formed elements, routing policy and decision mechanisms with different IP based service networks owned by different service providers or different IP network enabling core networks owned by different carriers. So, the problem Ted and Ralph are addressing seems to be just one of issues (but only for WiFi network environments) in terms of network characteristic that may be necessary to be considered during selection of an efficient connection/interface from multiple candidates. Giyeong -Original Message- From: Ralph Droms [mailto:rdr...@cisco.com] Sent: April 16, 2009 1:32 PM To: Ted Lemon Cc: Giyeong Son; Hui Deng; dhc WG; gen-...@ietf.org; mif; ietf@ietf.org; black_da...@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. - 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: resignation business
On Mon, Apr 20, 2009 at 05:17:31PM +0200, Francis Dupont wrote: = 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. Please, if people are going to open that debate again, could you (1) only do it if you've read all the relevant material in the idnabis archives and (2) do it on the WG mailing list (idnabis), since that's where the relevant discussions are going on? I will not rehash the arguements about this here, but I urge people who want to weigh in on this to think about the matching rules for E and e in the DNS, and then think about what might happen if we also need to accommodate E-é _and_ É-é. Thank you. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. Thanks, let's see whether he is going to talk here. The gist of what he was saying is that if you have an IPv4 address that looks okay, and an IPv6 address that looks okay, you can't assume that they *are* okay, because there may be no route to the global internet on either your IPv4 or your IPv6 link. So you must attempt to use both addresses, not just one, and you must do it at the same time. Whichever one answers first, you take. It means that the new IP model will try host's multiple connections each time as you suggested as well. If you prefer either IPv4 or IPv6, and the transport you preferred happens to be the one that was broken, a smart user will disable the one you've preferred. That user will then advise his or her friends, for example, that IPv6 creates instability, so you should disable it. This impedes deployment. The unattended multiple interface situation is quite similar. I think the attended case (a laptop with two or more network interfaces) is actually better handled through user intervention, because the user has knowledge of the physical situation that would be difficult to communicate to the computer. But in the unattended case, you can get into the same sort of wrong learning situation, where a smart but naive user who debugs a network problem winds up learning a workaround that would impede interoperability if everybody did it. Interesting thoughing, workaround will impede deployment. Thanks -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mif] WG Review: Multiple InterFaces (mif)
Hi all, Jari seems to be using the term of connection in his emails as association between an interface and an (access) network. When I used connection so far during email exchanges, I have used it as more likely routing or routable path for packet transmission in an abstract manner. I feel that different usage of the same word connection may consequence confusion or misinterpretation to the audiences. Therefore, it might be better to clarify it in terms of MIF so that everybody can be in the same page without any confusion or misinterpretation:-) Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Jari Arkko Sent: April 18, 2009 5:25 AM To: IETF Discussion Cc: Adrian Farrel; mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) I wanted to bring up a comment that was raised during the IESG and IAB discussions about this charter by Adrian and others. When the work started, it was clearly about multiple interfaces. Upon closer inspection, we have realized that the overall problem is somewhat larger. Problems that occur with multiple interfaces also occur even with one interface, when you have a number of default routers on the same link. The current charter text reflects this in some parts of the text, e.g., Many hosts have the ability to connect 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. However, it was pointed out that the text is not consistent. Other parts still talk about multiple interfaces, e.g., A number of operating systems have implemented various techniques to deal with multiple interfaces. 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 surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. This has created some confusion with regards to what really is in scope. Are hosts with multiple physical interfaces in scope (obviously yes)? Are hosts with multiple virtual or physical interfaces in scope (yes)? Are hosts with one interface but multiple connections to different networks in scope (I think they should be)? Are we only talking about multiple interfaces or connections when they are to different administrative domains (I do not think it really matters, even in one domain the parameters can be different)? I would like to solicit suggestions on how to modify the text to be fully aligned. Note: we need to keep the name of the group the same, as it something that is already familiar to people, not to mention the fact that the IETF database system does not allow an acronym change very easily. Would it be enough to change s/multiple interfaces/connections to multiple networks/ in the second quoted text excerpt? Jari ___ 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] [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. 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. 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. 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 laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the
Re: The ietf-honest nonsense is back
I've found it quite useful to block all traffic from persistent spammers' network domains/network blocks. There's really no need for anyone, regardless of affiliation or role, to endure abuse of this nature. The originators of that abuse are disposable, and should be treated as such. ---Rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
On Apr 19, 2009, at 7:46 AM, Hui Deng wrote: And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. The gist of what he was saying is that if you have an IPv4 address that looks okay, and an IPv6 address that looks okay, you can't assume that they *are* okay, because there may be no route to the global internet on either your IPv4 or your IPv6 link. So you must attempt to use both addresses, not just one, and you must do it at the same time. Whichever one answers first, you take. If you prefer either IPv4 or IPv6, and the transport you preferred happens to be the one that was broken, a smart user will disable the one you've preferred. That user will then advise his or her friends, for example, that IPv6 creates instability, so you should disable it. This impedes deployment. The unattended multiple interface situation is quite similar. I think the attended case (a laptop with two or more network interfaces) is actually better handled through user intervention, because the user has knowledge of the physical situation that would be difficult to communicate to the computer. But in the unattended case, you can get into the same sort of wrong learning situation, where a smart but naive user who debugs a network problem winds up learning a workaround that would impede interoperability if everybody did it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Giyeong Son wrote: Hi all, Jari seems to be using the term of connection in his emails as association between an interface and an (access) network. When I used connection so far during email exchanges, I have used it as more likely routing or routable path for packet transmission in an abstract manner. I feel that different usage of the same word connection may consequence confusion or misinterpretation to the audiences. Therefore, it might be better to clarify it in terms of MIF so that everybody can be in the same page without any confusion or misinterpretation:-) Yes -- this is indeed an issue. Let me see what I can come up with. Jari ___ 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
Dean: The official nomcom addresses are at tools.ietf.org Not so. The current NomCom can be reached at nomco...@ietf.org. It does appear that Joel mistakenly sent some mail from an address at tools.ietf.org, but one that I got said: | Please return to nomco...@ietf.org no later than | Oct 3, 2008. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
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)
At 1:14 PM -0700 4/20/09, Jari Arkko wrote: 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. Huh? Why on earth is it hard? Strings are cheap. Not that I care much about this, but having been in many a working group name change (hi, DRINKS folks!), I don't know what has changed to make this hard. Ted 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Ted, Huh? Why on earth is it hard? Strings are cheap. On some previous WG creation exercise I was told that once the WG creation process is in the IETF's database system, the WG acronym cannot be changed, you can delete it and create a new one, but you cannot the acronym. Of course, I could create a new one and ask it to be brought to the right state... hopefully without having to re-do any real-life steps, like announcements going out or the topic being on the IESG telechat. This might work, but I'd have to investigate further to ensure that it actually is possible. If it was the only problem I would. The other problem is that people may already recognize the name. And I don't have a nice replacement acronym in mind. Multple Interfaces is a very concrete description of the problem, even if its not the most generic one. Multiple Attachments to Networks (MAN, but too close to 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But its too late in the day here to be creative. I'm sure someone sends the coolest acronym in reply :-) Bottom line: not impossible, but requires some effort. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
It seems to me that the general problem is not multiple interfaces, but multiple addresses per host. It doesn't matter (much) whether those addresses result from multiple physical interfaces, a combination of physical and virtual network interfaces, multiple prefixes being advertised on the network attached to any particular interface, or even a mixture of v4 and v6. So that might have some impact on the name, particularly if you want to attract the breadth of interests whom this affects. Something like Hosts Addressed Multiply (HAM), perhaps? Keith p.s. and if the software can't deal with changing a wg name before it's chartered, seems like that should result in a change request for the software. we really want to resist having our tools make the rules by which we operate, rather than the other way around. Ted, Huh? Why on earth is it hard? Strings are cheap. On some previous WG creation exercise I was told that once the WG creation process is in the IETF's database system, the WG acronym cannot be changed, you can delete it and create a new one, but you cannot the acronym. Of course, I could create a new one and ask it to be brought to the right state... hopefully without having to re-do any real-life steps, like announcements going out or the topic being on the IESG telechat. This might work, but I'd have to investigate further to ensure that it actually is possible. If it was the only problem I would. The other problem is that people may already recognize the name. And I don't have a nice replacement acronym in mind. Multple Interfaces is a very concrete description of the problem, even if its not the most generic one. Multiple Attachments to Networks (MAN, but too close to 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But its too late in the day here to be creative. I'm sure someone sends the coolest acronym in reply :-) Bottom line: not impossible, but requires some effort. Jari ___ 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)
Keith, I think this (multiple IP addresses) is one issue this WG seems to want to deal with. Another one is the availability of multiple paths (next hop routers) for a given destination. It seems indeed that whether the source addresses, and even the paths/routes, are over different physical interfaces or not, is somewhat secondary. There is, however, significance in the presence of different interfaces in a given non-router node...I do not think either of the other two points (multiple IFs, multiple routes) should be lost completely in the effort to widen/clarify the charter. George P.S.: It would be kind of funny to figure out that this WG really has nothing to do with Multiple IFs, and yet maintain the MIF name... it would enhance the already obscure tradition of nonsensical terms like BOFs, RFCs etc ..not to mention other rather funny WG names :-) On Mon, Apr 20, 2009 at 10:11 PM, Keith Moore mo...@network-heretics.com wrote: It seems to me that the general problem is not multiple interfaces, but multiple addresses per host. It doesn't matter (much) whether those addresses result from multiple physical interfaces, a combination of physical and virtual network interfaces, multiple prefixes being advertised on the network attached to any particular interface, or even a mixture of v4 and v6. So that might have some impact on the name, particularly if you want to attract the breadth of interests whom this affects. Something like Hosts Addressed Multiply (HAM), perhaps? Keith p.s. and if the software can't deal with changing a wg name before it's chartered, seems like that should result in a change request for the software. we really want to resist having our tools make the rules by which we operate, rather than the other way around. Ted, Huh? Why on earth is it hard? Strings are cheap. On some previous WG creation exercise I was told that once the WG creation process is in the IETF's database system, the WG acronym cannot be changed, you can delete it and create a new one, but you cannot the acronym. Of course, I could create a new one and ask it to be brought to the right state... hopefully without having to re-do any real-life steps, like announcements going out or the topic being on the IESG telechat. This might work, but I'd have to investigate further to ensure that it actually is possible. If it was the only problem I would. The other problem is that people may already recognize the name. And I don't have a nice replacement acronym in mind. Multple Interfaces is a very concrete description of the problem, even if its not the most generic one. Multiple Attachments to Networks (MAN, but too close to 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But its too late in the day here to be creative. I'm sure someone sends the coolest acronym in reply :-) Bottom line: not impossible, but requires some effort. Jari ___ 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: Extending the Dean Anderson PR-action to lists on tools.ietf.org
More to the point, the guideline in RFC 3683 is: A PR-action identifies one or more individuals, citing messages posted by those individuals to an IETF mailing list, that appear to be abusive of the consensus-driven process. If approved by the IESG, then: o those identified on the PR-action have their posting rights to that IETF mailing list removed; and, o maintainers of any IETF mailing list may, at their discretion, also remove posting rights to that IETF mailing list. Henk is applying the second bullet of the guideline and is, per the RFC, within his rights in doing so. With respect to rai-...@tools and similar lists, I can see it two ways. I should imagine that Dean could send mail directly to Cull at his Cisco email address, where only Cisco's and Cullen's filters are relevant, so there is not an argument that Dean really needs access to rai-ads@. But unless Cullen sees an issue with posting to that list, it also doesn't solve a problem that anyone has (unless Henk has a problem as administrator). I see the second bullet as addressing the case where someone is a pain on some list such as the IDN list and migrates the problem to another list; if he has been banned from one, the administrator of the second has everything he needs to make that change. But that doesn't really apply in this case. So I would ask what problem blocking access to lists at tools.ietf.org is solving, and if there is none, would argue in favor of a principle of least mechanism; there is no value in making someone go away from a place that he is not. My two yen. On Apr 17, 2009, at 8:32 AM, Samuel Weiler wrote: On Fri, 17 Apr 2009, Cullen Jennings wrote: I really don't understand why Dean should be blocked from rai-...@tools.ietf.org . Dean is the subject of a PR Action; Henrik needs no other reason to apply the blocking and, if there is a reason or triggering event (which seems likely), he needn't disclose it to Dean or to this list. In the general case, I also see no harm in the blocking: those aliases are for convenience, and it's easy to expand them using public sources. Blocking their use doesn't meaingfully hamper IETF participation. -- Sam ___ 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: Extending the Dean Anderson PR-action to lists on tools.ietf.org
On 2009-04-21 02:44, Dave CROCKER wrote: Andrew Sullivan wrote: On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote: My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. In my opinion, it is. +1 But the question is not whether they are IETF lists. It's whether they are official in the sense that IETF office-holders (such as WG chairs, ADs and IAB members) are obliged to read what is sent to them, in order to exercise their duties under our process BCPs. I don't believe they are official in that sense. From which I conclude that it's reasonable to extend any PR-action to cover them. Brian ___ 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 Apr 17, 2009, at 1:18 PM, Sam Hartman wrote: My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. And I would say that yes, they are IETF lists. For example, the tracker sends email through them. They are used by IETFers (well, by me at least) to get stuff to the right people without having to sort out who is the right AD/WG Chair/Author for a given email. They sprang into being out of Henk's forehead, as opposed to being lifted out of the sea foam of IETF discussion. But they serve a useful IETF purpose and are built into many of the IETF tools. If you are asking whether the policy SHOULD apply to them, that's another discussion. But as to whether they are IETF lists, if they are not, then to what do they belong? ___ 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 Mon, Apr 20, 2009 at 02:29:58PM -0700, Fred Baker wrote: So I would ask what problem blocking access to lists at tools.ietf.org is solving Well, one obvious one is that some chairs, c., might have tricky rules for capturing mail that actually pertains to the matters in which they must listen to every crank on the planet due to process rules, vs. other mail from the self-same cranks which can be cheerfully discarded. The role addresses represent a completely separate path that needs to be tested, and so I can imagine such chairs and so on asking, one at a time, for the filters to be installed in this or that way. This uses Henrik's valuable time. It seems to me like a problem worth solving. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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
I want to stress that I'm not making any of the following arguments: * Dean should be permitted to post to tools.ietf.org addresses--I don't care * We should not ban people who have PR actions against them from tools.ietf.org - after consideration, I think banning specific people who have PR actions against them from posting to tools.ietf.org is fine * The person running tools.ietf.org should not do something about abuse - absent any specific policy I think they should exercise good judgment Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian On 2009-04-21 02:44, Dave CROCKER wrote: Andrew Sullivan wrote: On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote: My question is whether treating tools.ietf.org aliases as IETF lists is reasonable policy. In my opinion, it is. +1 Brian But the question is not whether they are IETF lists. It's Brian whether they are official in the sense that IETF Brian office-holders (such as WG chairs, ADs and IAB members) are Brian obliged to read what is sent to them, in order to exercise Brian their duties under our process BCPs. I think that's one of two questions. I believe that most of the review directorates assumes that sending mail to *-chairs or draf...@tools.ietf.org is an entirely appropriate way to send review comments. I'd be really incredibly put out if a wg ignored my review comments because I sent to a tools.ietf.org address rather than the draft authors. Similarly, I'd be incredibly annoyed if I sent a bof proposal to int-...@tools.ietf.org and it was bitbucketed because of my choice of address. I have high confidence that 1) Chairs, ADs and draft authors should not treat legitimate mail to tools.ietf.org differently than mail to the individual email address. 2) Restricting someone's access to tools.ietf.org significantly impacts their ability to participate in certain ietf processes, including cross-area reviews, etc. It does not make it impossible; it requires them to do more work than someone who is not restricted. 3) It is possible to abuse the tools.ietf.org mailing lists. Doing so should be dealt with. 4) It is possible to abuse an individual's mail address. Doing so should be dealt with. 5) There are situations where it would be reasonable for an AD, chair, or author to block mail they were receiving at their individual address to deal with spam, abuse, etc. So, in some sense I do think that the tools aliases have some official status in that they significantly facilitate review within our processes. I think it would be a big problem if they were unreliable, if we granted access to them unfairly, etc. I also think it would be a big problem if they were abused in a manner where people started discarding legitimate traffic. I think that our spam-/list policies are a bad fit for the tools lists. The spam/list policies are designed to provide spam control and abuse handling for relatively large discussion groups. Having the archive remain useful is important to our lists, but not to the tools lists. Similarly, the availability of a public archive allows someone to see if their postings are making it through. In contrast each tools alias reaches a fairly small number of people. Certain network effects--for example the tendency of a flamewar to break out because of the actions of a small number of recipients are less likely. For example, I don't think it would make sense to suspend someone from posting for a few days until they cool down from the tools aliases although this has often been done with WG lists. I think that the boundaries for taking action are likely different for the tools aliases than for lists. In many cases individual mail filters will be better tools to apply than anything global. 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
