Re: [tcpm] [OPSEC] draft-gont-tcp-security
Hi, Todd, On 2009-4-14, at 22:21, Todd Glassey wrote: Fernando Gont wrote: Lars Eggert wrote: I agree with Joe that some of the hardening techniques that vendors are implementing come with consequences (make TCP more brittle). To me, this is a *reason* this document should be published via the IETF (i.e., TCPM) - we are probably in the best position to correctly evaluate and classify the impact of various hardening techniques. Stack vendors have been putting these mechanisms in to their stacks without clear specifications and discussions of the potential upsides and downsides that would let them make an educated decision. It seems clear to me that the vendor community is looking for guidance here, and I do believe the IETF should give it. This is the reason for which the output of the CPNI project was submitted as an IETF I-D. Yeah - so then this would be tested across all of the local TCP implementations including the MS, ATT *(i.e. Lachman Associates Inc) and possibly Mentat's fast system? Nothing would be tested, the IETF isn't in the business of auditing TCP stacks. What we're talking about is describing attack vectors, potential countermeasures and the the impact (downsides) those countermeasures might come with. Implementors will need to decide for themselves if and how to apply any of these techniques to their stacks. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
On 14 apr 2009, at 16:37, IETF Secretariat wrote: Be sure to make your reservation at one of the Stockholm hotels the IETF has a block of rooms held. Cutoff dates for the blocks are relatively early. No kidding: some are next week. Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Some of the phone numbers have a (0) in there. Is this the European (0) which means if you don't know that you sometimes have to remove that 0 you will get some unlucky soul on the line who doesn't know why he gets so many crank calls or the North American (xyz) which means it's a normal part of the number? (My phone number in Holland used to be 31073... and it took me years to figure out why people would keep calling me over and over again when they clearly needed someone else. But this person apparently decided that +31(0)73... was a good way to write down their number +3173... / 073...) Do we have an RFC for how to format phone numbers? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Iljitsch van Beijnum iljit...@muada.com wrote: Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Some of the phone numbers have a (0) in there. Is this the European (0) which means if you don't know that you sometimes have to remove that 0 you will get some unlucky soul on the line who doesn't know why he gets so many crank calls or the North American (xyz) which means it's a normal part of the number? The European one. All phone numbers on that page are in the Stockholm area, with area code 8, therefore all numbers should be read as being in the format +46 8 xxx yyy... and dialled in that way from abroad. --Johnny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
I don't think an RFC is needed. Unless I am mistaken, the + format, leaving out leading 0s was introduced by CCITT (now ITU) in the Red Book back in 1984, perhaps even in earlier works. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 15 Apr 2009, Iljitsch van Beijnum wrote: On 14 apr 2009, at 16:37, IETF Secretariat wrote: Be sure to make your reservation at one of the Stockholm hotels the IETF has a block of rooms held. Cutoff dates for the blocks are relatively early. No kidding: some are next week. Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Some of the phone numbers have a (0) in there. Is this the European (0) which means if you don't know that you sometimes have to remove that 0 you will get some unlucky soul on the line who doesn't know why he gets so many crank calls or the North American (xyz) which means it's a normal part of the number? (My phone number in Holland used to be 31073... and it took me years to figure out why people would keep calling me over and over again when they clearly needed someone else. But this person apparently decided that +31(0)73... was a good way to write down their number +3173... / 073...) Do we have an RFC for how to format phone numbers? ___ 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: Security Assessment of TCP
Hi, On 2009-4-14, at 20:51, Fernando Gont wrote: Lars Eggert wrote: My personal take is that the IETF is responsible for the maintenance of its protocols, and this effort carried ut by the UK CPNI should be welcome, and the IETF should take the chance and benefit from this work to publish advice on TCP security/resiliency. I agree with you, as I've already said on the TCPM list. (See my email there for details.) What are your thoughts about working on this I-D in the transport area? (with hat on). I believe this should be done in the transport area, because at least some of the techniques under consideration could be argued to not be fully conformant to the published TCP specs, and I want the TCP experts to evaluate their impact. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Stockholm info
Hi Here some info that might be useful when you visit Stockholm. I don't claim it to be the complete manual and others welcome to add info and correct where needed. Getting from Arlanda to the City: There are a number of alternatives. If you want it cheap you take the bus and then the metro. If you take the taxi, make sure that you negotiate the price beforehand (the cost should be ~500SEK). http://beta.stockholmtown.com/en/Travel/Tips/Getting-to-and-from-the-airports/ Public transportation: Driving a car in Stockholm is almost as stupid as stupid can get. Unless you'll stay at a hotel out in the boondocks I would recommend that you use the public transportation. See http://www.sl.se/Templates/SubStart.aspx?id=1906 for info. Also you may consider the travel cards which will keep the transportation cost down. See also http://beta.stockholmtown.com/en/Travel/In-Stockholm/ Stockholmskortet: If you plan to see more that just the IETF-venue then you want to get Stockholmskortet http://beta.stockholmtown.com/en/Information/Buy--Order/The-Stockholm-card/ It will give you free admission to a whole bunch of attractions + free travel with the public transportation. Taxi: There are a lot of unregistered taxis in Stockholm, a friendly advice.. avoid them. http://beta.stockholmtown.com/en/Travel/In-Stockholm/taxi/2087 Pickpockets: Summer in Stockholm is high season for pickpockets who often like to operate in teams, so keep your wallet close. To see: Well.. there are lots of things to see.. Stockholm is IMHO one of the more beautiful cities I have seen (alright some of the suburbs are really ugly). You shouldn't miss Vasamuseet, it hosts one of the worlds best preserved ships from the 17th century, BTW the ship sank almost immediately due to too much optimization:-). Djurgården and Skansen are waterholes for the locals. Skansen hosts a sort of compressed version of Sweden. As Stockholm is surrounded by water it is never wrong to go with one of the many boats. And please don't forget Gamla stan. I have probably missed a lot but I believe that this is at least a start. Regards Ingemar Johansson *** Ingemar Johansson Senior Research Engineer, IETF nethead EAB/TVP - Multimedia Technologies Ericsson Research Ericsson AB Box 920 S-971 28 Luleå, Sweden Tel: +46 (0)10 7143042 ECN: 852-43042 ECC: 852-19042 Mobile: +46 (0)730 783289 Visit http://labs.ericsson.com ! *** ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Ole, You're not mistaken - the standard + format is defined in ITU-T Recommendation E.123 (http://www.itu.int/rec/T-REC-E.123/en). - Lyman On Apr 15, 2009, at 7:17 AM, Ole Jacobsen wrote: I don't think an RFC is needed. Unless I am mistaken, the + format, leaving out leading 0s was introduced by CCITT (now ITU) in the Red Book back in 1984, perhaps even in earlier works. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 15 Apr 2009, Iljitsch van Beijnum wrote: On 14 apr 2009, at 16:37, IETF Secretariat wrote: Be sure to make your reservation at one of the Stockholm hotels the IETF has a block of rooms held. Cutoff dates for the blocks are relatively early. No kidding: some are next week. Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Some of the phone numbers have a (0) in there. Is this the European (0) which means if you don't know that you sometimes have to remove that 0 you will get some unlucky soul on the line who doesn't know why he gets so many crank calls or the North American (xyz) which means it's a normal part of the number? (My phone number in Holland used to be 31073... and it took me years to figure out why people would keep calling me over and over again when they clearly needed someone else. But this person apparently decided that +31(0) 73... was a good way to write down their number +3173... / 073...) Do we have an RFC for how to format phone numbers? ___ 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: Your favorite network faults
A NAT that if it's external IP was 1.2.3.4, any time it saw the binary pattern 0x01020304 passing through it in any data it would replace it with the nats internal IP. (Many NATS call this feature a Generic ALG so if you see a NAT with that, run screaming) Most stuff worked fine but the bug was found when someone was downloading the ISO image for a Linux CD that just happened to contain the external IP in some executable that got changed in the download. Credit to Adam Roach for figuring out what was going on. On Apr 10, 2009, at 10:48 AM, Henning Schulzrinne wrote: As part of a research project, we are working on automated diagnostics of network-related faults in residential, SOHO, conference/special event, hotel and similar networks. If you have observed errors that were hard for a lay person to diagnose, whether due to end system problems, NATs, LAN or Internet issues, please send me a brief description. (Also, contacts in tech support for such environments would be most helpful, particularly if they might be willing to talk to us.) Henning ___ 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: [tcpm] [OPSEC] draft-gont-tcp-security
Lars Eggert wrote: Hi, Todd, On 2009-4-14, at 22:21, Todd Glassey wrote: Fernando Gont wrote: Lars Eggert wrote: I agree with Joe that some of the hardening techniques that vendors are implementing come with consequences (make TCP more brittle). To me, this is a *reason* this document should be published via the IETF (i.e., TCPM) - we are probably in the best position to correctly evaluate and classify the impact of various hardening techniques. Stack vendors have been putting these mechanisms in to their stacks without clear specifications and discussions of the potential upsides and downsides that would let them make an educated decision. It seems clear to me that the vendor community is looking for guidance here, and I do believe the IETF should give it. This is the reason for which the output of the CPNI project was submitted as an IETF I-D. Yeah - so then this would be tested across all of the local TCP implementations including the MS, ATT *(i.e. Lachman Associates Inc) and possibly Mentat's fast system? Nothing would be tested, the IETF isn't in the business of auditing TCP stacks. Yo Lars Good-morning, let me respond. Sure it is... let me amplify - Don't the IETF standards processes require the development of two or more independent implementations of any given protocol specification and the associated interoperability testing to document that the suite runs as advertised in the specification? - I generally refer to that as IOT (Inter-Operability Testing). And for what its worth the IETF's mergence towards a leading edge standards process also reinforces the importance of that testing too by the way. By comparison, in trailing edge standards processes the IOT is accomplished in the various implementations which are done in the industry. In leading edge models where there is genesis happening the testing would have to be included in the implementation of any prototypes of the stack or system and its operations. This IMHO is the real issue with the worlds abuse of the IETF's processes - they seem to think that RFC's are standards and there are many here who use that to substantiate their technological advantage in their marketing, meaning that they derive financial value from misrepresenting this to the commercial community as well I think. The fix for that is to make RFC's unreliable for use as a protocol specification for anything other than a Standards Track effort as they should be - a Request For Comments rather than something the Trust's selling access to. Todd Glassey What we're talking about is describing attack vectors, potential countermeasures and the the impact (downsides) those countermeasures might come with. Implementors will need to decide for themselves if and how to apply any of these techniques to their stacks. Which would be filed as a Use Case Document as a set lf BCP's for a protocol stanadard. This by the way is where the real value of the IETF comes in - in also telling people how to and how not to use these protocols. Todd Lars ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Be sure to make your reservation at one of the Stockholm hotels the IETF has a block of rooms held. For these hotels, is the IETF group rate always less than (or equal to) the non-group rate? Apparently this was not always the case in San Francisco. Ross. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Hi - From: Iljitsch van Beijnum iljit...@muada.com To: IETF Discussion Mailing List ietf@ietf.org Sent: Wednesday, April 15, 2009 2:49 AM Subject: Re: 75th IETF - Hotels ... Do we have an RFC for how to format phone numbers? ITU E.123 would be what you want. http://www.itu.int/rec/T-REC-E.123-200102-I/e Clause 2.8 hints at those annoying parenthesized things, and 7.2 makes it clear it's not an appropriate notation for international numbers. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
On Wed, 15 Apr 2009, Randy Presuhn wrote: Do we have an RFC for how to format phone numbers? ITU E.123 would be what you want. http://www.itu.int/rec/T-REC-E.123-200102-I/e Clause 2.8 hints at those annoying parenthesized things, and 7.2 makes it clear it's not an appropriate notation for international numbers. And for the next RIPE meeting remember any 7 digit phone number means Amsterdam :) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: pickpockets
Dave, Good advice, everyone should follow this. But lets not get overly worried though. In my experience Stockholm is one of the safest possible places to visit. And a great place, particularly in the summer! Of course, being careful whether home or abroad is always a good idea. Don't drink so much that you can't take care of yourself, follow the local laws, move that pile of money from your backpocket somewhere else, don't argue with the skinheads or the engineers ;-) Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: pickpockets
More personal comments, based on having lost a laptop to a two-man team at the exit to the Brussels train station in the last two months I got hit upon arrival to the country, where I was badly jetlagged after arriving early into London Heathrow, and then taking a connecting flight to Brussels, and being badly short on sleep before starting the travel in the first place. So be especially vigilant on that first day, when your defenses are down and if you are desperately tired and/or jet lagged. In my case, one of them slimed the back of my jacket with spit and a what appeared to be mouthful of partially chewed sandwidch, and the other one tried to sell me postcards while babbling in French and pretending not to know English. When you're tired, grumpy because the train station is badly labelled and you're wondering whether you took the right escalator or not, and are generally lost, it's ridiculously easy for a pickpocket to overload you enough that while you thought you should know better, you don't. Other lessons learned/reinforced --- (1) back up your laptop before leaving on an trip, (2) keep a backup copy of your presentation on a USB stick stored separately in the luggage or on some system accessible outside of your firewall, so you don't have to try to regenerate it on the fly, (3) keep all sensitive information encrypted at rest on your hard drive, (4) never, *ever* set down a shoulder bag even under extreme provocation, (5) if something strange happens to you, don't stop, don't turn, just keep walking briskly away. Personally, my experience of Belgium was badly tarnished as a result of being hit by pickpockets, and I'm not at all keen on wanting to go back as a result. So a word to the wise --- be careful out there it really can happen to anyone, especially those who thought they were knew how to be careful enough. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Does others also have a problem in reserving a room at the Clarion Sign? I get only a generic error message the the system can not process the reservation and I should check my data... Best regards Michael On Apr 15, 2009, at 11:49 AM, Iljitsch van Beijnum wrote: On 14 apr 2009, at 16:37, IETF Secretariat wrote: Be sure to make your reservation at one of the Stockholm hotels the IETF has a block of rooms held. Cutoff dates for the blocks are relatively early. No kidding: some are next week. Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Some of the phone numbers have a (0) in there. Is this the European (0) which means if you don't know that you sometimes have to remove that 0 you will get some unlucky soul on the line who doesn't know why he gets so many crank calls or the North American (xyz) which means it's a normal part of the number? (My phone number in Holland used to be 31073... and it took me years to figure out why people would keep calling me over and over again when they clearly needed someone else. But this person apparently decided that +31(0)73... was a good way to write down their number +3173... / 073...) Do we have an RFC for how to format phone numbers? ___ 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: [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 type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks
Re: 75th IETF - Hotels
Michael Tüxen wrote: Does others also have a problem in reserving a room at the Clarion Sign? I get only a generic error message the the system can not process the reservation and I should check my data... Best regards Michael We believe we succeeded, but there was some wierdness. There were two different room rate figures shown on our confirmation. Fortunately (!?) the higher one was the IETF rate. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700: I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. I'm just saying the WG should make an explicit decision one way or another: - decide the draft needs no change - document source info as TBD and outside of the container syntax or - document source info as part of container syntax Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Network-Based Mobility Extensions (netext)
I think this charter requires some clarifications. Since this is about extensions to NETLMM protocols, it should clarify what principles it inherits from the NETLMM charter. For instance, one major thing that stands out is about no changes to the mobile node - I believe NETLMM's main value was seen as providing mobility without MN involvement and I don't believe we have consensus to allow any changes to the MN. I think this charter should explicitly clarify that. Other points worth clarifying are that the protocols that may be specified need to remain link layer agnostic and independent of a global mobility management mechanism that may be used with it. Cheers, Vidya -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 14, 2009 1:00 PM To: ietf-annou...@ietf.org Cc: net...@mail.mobileip.jp Subject: WG Review: Network-Based Mobility Extensions (netext) A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 21, 2009. Network-Based Mobility Extensions (netext) - Last Modified: 2009-04-03 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: http://www.mobileip.jp/mailman/listinfo/netext Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Hosts are not affected, as they still send and receive their packets via the MAG. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing, and is complementary to the initial LMA discovery work in the NETLMM WG. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2009 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
I support this version of the document. Tony Hansen t...@att.com The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-05-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a second IETF LC on the document, after the author has addressed most of the issues raised during the first IETF LC. Please see http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=http://tools.ietf.org/id/draft-crocker-email-arch-12.txt for the list of changes. In particular note that the Internationalization section has been updated. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Virtual Interim Meeting for IPSECME
The IPSECME WG will have a conference call on Tuesday, 5 May 2009 at 15:00 GMT (11:00 EDT, 08:00 PDT), for two hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Details for the meeting can be found on the IPSECME Wiki page: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
