automationtechies.com
EXPAND THE REACH OF YOUR RECRUITING EFFORTS www.automationtechies.com is a job postings website with an exclusive focus on the automation and controls industry. It is designed to expand the reach of your recruiting efforts by directly connecting your company with established controls and automation professionals. We market our site only to the professionals who work in automation and controls. This reduces the number of non-qualified iquiries you will receive. Our current Employer Members are providing us with fantastic feedback. With our Techie-Membership growing by 20-30 per day, this satisfaction will also continue to grow. Our site is perfect for manfacturers in this industry as we provide advertising options as well as access to qualified job candidates. We are currently running a 40 percent discount for sixty day job postings, with further discounts for multiple listings. If you would like to take advantage of this discounted offer please call our toll free number at #877.300.6792, or : Go to: www.automationtechies.com Click on: Employers Register as a New Employer You will receive an e-mail with your Username and Password You may then: Purchase Job Postings Edit your Job Postings Request them to be activated If you have any questions, feel free to contact us: Gregg Peterson [EMAIL PROTECTED] 877.300.6792
Re: draft-ietf-nat-protocol-complications-02.txt
At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote: This draft is very incomplete and in my opinion not ready for prime time. The working group has in the past requested lists of protocols and applications which do not work with NATs. I have replied discussing those items for which I am most familiar: [...snipped] I think everyone agrees that the draft is incomplete. I've been begging for input for over a year now in the NAT WG meetings and on the NAT list. I've also asked every IETF WG chair for input. Our hope is that through IETF last call, we will get enough contributions such as yours to get a reasonable document together that folks can reference. I am not on the NAT mailing list; nor do I attend NAT working group meetings. I consider NATs to be architecturally unsound and that the IETF and IESG should in no way endorse their use or development. All of the energy and money being spent on NATs could and should be spent to begin the migration to IPv6 instead. It is my hope now that Windows 2000 supports IPSec that enough pressure will be applied to halt the deployment of NATs Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
At 12:39 PM 4/20/00 -0400, Jeffrey Altman wrote: At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote: This draft is very incomplete and in my opinion not ready for prime time. The working group has in the past requested lists of protocols and applications which do not work with NATs. I have replied discussing those items for which I am most familiar: [...snipped] I think everyone agrees that the draft is incomplete. I've been begging for input for over a year now in the NAT WG meetings and on the NAT list. I've also asked every IETF WG chair for input. Our hope is that through IETF last call, we will get enough contributions such as yours to get a reasonable document together that folks can reference. I am not on the NAT mailing list; nor do I attend NAT working group meetings. I consider NATs to be architecturally unsound and that the IETF and IESG should in no way endorse their use or development. Just so there is no more confusion, in no way is the IETF endorsing the use or development of NAT. You've completely missed the point of the draft. It's purpose is to clearly point out the problems that NAT causes to a given set of protocols. Also please do not steer this thread towards a NAT bashing-fest. We need to complete this document and we need constructive input to this draft. Thanks again for your original input.
Re: draft-ietf-nat-protocol-complications-02.txt
From: Matt Holdrege [EMAIL PROTECTED] ... Just so there is no more confusion, in no way is the IETF endorsing the use or development of NAT. You've completely missed the point of the draft. It's purpose is to clearly point out the problems that NAT causes to a given set of protocols. Also please do not steer this thread towards a NAT bashing-fest. We need to complete this document and we need constructive input to this draft. Thanks again for your original input. If the document is not intended to be read as advocating NAT, it also needs substantial non-technical changes. It currently comes across as a list of fairly minor, generally easily fixed problems or problems that don't matter. I don't mean to say that is the intended point of the document, but is how I read it. Since I'm among those who feel that the situation with NAT is not quite as bad things would have been if we had waited for IPv6, you might expect my prejudices to make me read it the other way. Instead of appearing to be a complete list of problem and their complete and easy solutions, the document needs to have more words in each section saying that the sublist of problems is probably incomplete. The shortcomings of solutions to the problems should be belabored instead of glossed over. Seeing that the problems are significant must not require any technical sophistication in the reader. For example, most people who should read this document will see nothing but some opaque acronyms whose problems surely don't matter in Section 5. Why should anyone care that IPCEC doesn't work with NAT? Vernon Schryver[EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
By the way, just out of interest, don't the tops of your knees get kind of bruised every time to you see the word "NAT", or have you learned to scoot back from your desk in time? Looks to me like knees are getting bruised all around. RGF Robert G. Ferrell, CISSP Information Systems Security Officer National Business Center, US DoI [EMAIL PROTECTED] Nothing I have ever said should be construed as even vaguely representing an official statement by the NBC or DoI.
Re: draft-ietf-nat-protocol-complications-02.txt
Oh, goody, another round of wasted time and energy arguing about IPv6 and NAT boxes on the IETF list So it seems. Too bad you couldn't just leave it at that without adding another dose of gasoline to the mix. Meanwhile, those of us who believe IPv6 is the best and most promising way out of this mess will continue to work on actually making it happen. Of course, if someone has a better idea, I'd surely love to read the draft. Thomas
Re: draft-ietf-nat-protocol-complications-02.txt
From: Jeffrey Altman [EMAIL PROTECTED] I am not a IPv6 proponent other than Well, I'm not exactly a big fan of NAT boxes either. Disgusting kludges. However, I've generally found that it's not really very useful to go around saying "it's not really raining, it's not really raining" while I'm walking in a thunderstorm. NAT's are with us, like them or not, and the sooner we accept it, and try to start working to fix things up to work with them, the better... (E.g. fixing IPSEC to work through them, to use one example mentioned here - although some people would no doubt point to things like SSL, which already work through NAT boxes, and ask why we need IPSEC anyway - but I'm *not* going to get into that! :-) the extended address space that everyone needs without breaking the end to end model of IP. Well, I think we can regain the "end-end model", even with NAT boxes, if we accept that those 32-bit things are irrevocably destined to become just forwarding tags with only local scope. There's a need, and a place, for things with only local scope - e.g. the network layer header in front of the internet header, the hop count in the internet header, etc, etc. The IPv4 address will have to be added to that list - and for things which need an end-end name, we'll have to migrate to using something else. This still leaves us with the architectural problem of having mapping state in the border boxes (another impingement on the fatesharing principle - i.e. that all state relevant to an end-end connection be kept only at the ends), but that can be looked at. It's not like there's *no* state in the network, without which the connection won't work - routing table entries may seem like they're handed down on stone tablets, but they are critical state too. Then there's how it's installed (wiretapping DNS - eccch, another disgusting kludge); definitely need to do something better there. But it will have to be an incremental approach back to goodness, I fear... Noel
RE: IP over Bluetooth, Cellular Handoff to WLAN
Anybody interested in chatting about macro-cellular to WLAN/PAN handovers? I've been thinking of this quite a bit since probably jan. I'm really interested in the potential of dynamic routing over bluetooth, possibly without the handover... (Needless to say, ATT Wireless, my current employer, is not taking sides). Your bluetooth (BT) computer to my BT palm pilot to that car's BT cdplayer to the next vehicle's BT ... - R/db ( [EMAIL PROTECTED], 425/580-7275 ) Architecture/Emerging Technologies Group The Moon is Waning Gibbous (96% of Full)
FWD: IP over Bluetooth, Cellular Handoff to WLAN
Phil, A proposal for IP over Bluetooth BOF is under preparation. We are in the process of soliciting approvals from the IETF area directors and the Bluetooth SIG. I'll post an announcement to the IETF mailing list as soon as all approvals are in place. -*- Pravin -*- === Pravin Bhagwat http://www.research.ibm.com/people/p/pravin Folks, Where(what is the mail list) is the discussion group for IP over Bluetooth? I heard about the Pittsburgh BOF but I can't find a mail list. Anybody interested in chatting about macro-cellular to WLAN/PAN handovers? Thanks, Phil
