- Test - lists.nanog.org

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Joe, I firmly believe that an undergraduate degree is essential. If you have to go part-time, then do that. Don't wimp out and take a BA. Get the BS, take the science and math courses. You might wonder what mechanics and chemistry have to do with networks or software development. Two words: Scientific Method . We need to train you, the student, to THINK. Not just that you need to think, we need to train you HOW to think. Math is more directly applicable. ----- Original Message ----- From: joe <jk(a)wnonline.net> To: Dana Hudes <dhudes(a)panix.com> Cc: <nanog(a)merit.edu> Sent: Tuesday, August 24, 1999 1:09 PM Subject: Re: Training the next generation: > > I am also interested in this, for I am fairly young and VERY interested in > building/maintaining/upgrading networks, etc. I would like to know the > very things that some of you guys complain about all the time when you try > to work with companies. Do any of you know of schools out there (besides > cisco ;P) that can offer the valued training to get people like myself > into this ever-changing field. I have taken the route of working my way > through ISP's, what other ways have some of you done? Do you think > working in a good environment and being trained onsite, being trained > onsite and going to school or just going to school would come out to be > the best idea for getting into this field. Please reply publically or > privately :> > > I apologize if this seems NON-OPERATIONAL to you, but it is to me, because > once you guys are off and gone, who will be left? > > Thanks for your time, > > joe > > ======================================================================= > joe kamm jk(a)wnonline.net > network operations > worldnet communications http://www.wnonline.net > > On Tue, 24 Aug 1999, Dana Hudes wrote: > > > Date: Tue, 24 Aug 1999 00:12:41 -0400 > > From: Dana Hudes <dhudes(a)cncdsl.com> > > Reply-To: Dana Hudes <dhudes(a)panix.com> > > To: nanog(a)merit.edu > > Subject: Training the next generation: > > > > Hi ! > > I'm teaching networking this year at CUNY Hunter College here in Manhattan. I would like your input as industry members what skills would have value to you in a new graduate computer science major (the students are seniors). > > Fall course is "Telecomputing"; the syllabus I created for the course uses Tannenbaum's _Computer Networks_ and tries to cover a range of things. Course project will likely be design and implement a bridge, possibly including source-route and certainly including spanning tree. Early on, coverage of WAN include project with PCM and such. > > A syllabus is posted at http://harmony.hudes.org/Telecomputing.html > > Students will have a broad base in a variety of networking topics. Focus on Ethernet in the LAN and PPP and ATM in the WAN. > > > > > > Spring is a "special topics" course. I've some flexibility here. I'm weighing two alternatives, and want some feedback. > > Of all possible things, the acting chair and I narrowed to two possible courses: > > 1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his syllabus from Purdue as a starting point. > > No time in this course for any physical layer or data link stuff beyond a cursory overview of Ethernet as we move at high speed to the network layer and IP forwarding. Comer's graduate course has students build a router but this is probably too much for undergraduates. Instead an OSPF implementation, including all the options (especially NSSA) . A cursory introduction to sockets programming with the course focus on routing algorithms (i.e. RIP, OSPF, and BGP4). > > Can this one course (my fall course hasn't sufficient registration to make the 2 semester sequence in networking we'd hoped; maybe next year). > > > > 2. Network application programming. Java clients, Perl and Apache server side (or perhaps Java servlets). Hunter students know C++ fairly well by their senior year; Java is an easy transition. The entire class would divide into teams with assignments that comprise various parts of the client and server portions. The project would be a turn-based simulation game (I used to play these and have a number of appropriate games with play-by-mail options, game rule design and/or game theory is not part of the course). While this won't teach them to be router engineers -- or developers, it should have some industry relevance. > > > > > > Most Hunter graduates stay in the Greater NYC metropolitan area. Given this, which of these options is better for the industry? who is in shorter supply? > > > > Prompt feedback greatly appreciated. Registrar is asking for the course description ASAP or sooner. > > > > Thanks! > > Dana Hudes > > CUNY Hunter Computer Science > > former ISP > > > >

1 0

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Surely the definitive work on IS-IS is Radia Perlman's _Interconnections_? Bridging and the spanning tree are covered there quite nicely as well. The original problem we had with IS-IS was that nobody had a CIDRized version. I think that's why. Maybe the split is earlier? I'm not sure. Huitema doesn't say anything in his book. Dana ----- Original Message ----- From: Jeff Parker <jparker(a)nexabit.com> To: Dana Hudes <dhudes(a)panix.com> Sent: Tuesday, August 24, 1999 11:23 AM Subject: RE: Training the next generation: > > > It may be a bit late to suggest this, but please keep in > > > mind for the > > > future an alternative text, entitled "An Engineering > > > Approach to Computer > > > Networking", by Keshav. > > An excellent book. A bit hard to fit your course around it, > but it gives a very different take on the subject. > > > Interesting that you put ISIS as an emerging rather than past > > protocol. > > I work on ISIS here - it is seeing new life as a routing protocol > that is much simpler, but as powerful as, OSPF. > > - jeff parker >

1 0

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Jeff, thanks for the input. Comer has a volume 3 that uses Winsock instead of BSD sockets. Stevens UNIX network programming 3rd edition added XTI, I don't know why. Market -- always a problem to have a pool of eligible students but its a hot topic. A co-requisite of our Operating Systems course, which is required, isn't too limiting -- gives a pool of about 60 students (the 30 taking the fall, the 30 taking the spring; not too many who took it last spring will be around next spring). I can't take more than 30, would rather have 20. Hunter is big on C++ but I found out that they don't teach methodology despite calling the courses software engineering. Its really the same course as it was when they used Pascal, only now they use C++. If I get up in front of class and start drawing use-case diagrams, nobody will know what I'm talking about. so much for a class-wide project in the large. I'm going for the Comer vol. 1 course, plus sockets. Thanks again, Dana ----- Original Message ----- From: Jeff Parker <jparker(a)nexabit.com> To: Dana Hudes <dhudes(a)panix.com> Sent: Tuesday, August 24, 1999 9:47 AM Subject: RE: Training the next generation: > Dana - > I teach a course here at the Harvard Extension school > similar in aims to your 2nd course here. I've been using > Steven's Unix Network Programming plus lecture notes that cover > some of the Internet Protocols (ARP, BootP, ... RPC, NFS, AFS, ...) > > I don't cover much about TCP - other than a lecture that > includes MTU discovery and Slow Start. Some of this is that our > first semester course covers sliding window, etc. However, ours > is a very market-driven course (that is, I don't have a natural market, > so I can't scare folks off with prereqs) I cannot assume too much. > > Lately, I've been finding that our students don't know > enough about Unix and Unix System Programming to deal with Stevens: > I've switch the language from C to Java, and I'm using a Java > text to teach sockets programming, as well as using Stevens > TCP/IP Illustrated to teach the protocols. > > The project has always been a client/server system: we > start with a simple name server with 3 operations: Insert, > Delete, and GetNext, and deal with issues such as packet loss > (I give them a "flakey sendto" that drops 2 packets out of 5, > and introduces duplicate packets) and transactions (to deal > with a "rename" (delete and insert) encountering a getNet walk. > > Depending upon the background, the setup (how does their > bridge send/rcv packets, what they have to observe traffic - sniffer?) > I would think that your bridge assignment would be challenging. > > I'd be interested to chat about your course: here is a link > to last semester's website. > > http://www.fas.harvard.edu/~adm119/cs258/ > > - jeff parker > > > 2. Network application programming. Java clients, Perl and > > Apache server side (or perhaps Java servlets). Hunter > > students know C++ fairly well by their senior year; Java is > > an easy transition. The entire class would divide into teams > > with assignments that comprise various parts of the client > > and server portions. The project would be a turn-based > > simulation game (I used to play these and have a number of > > appropriate games with play-by-mail options, game rule design > > and/or game theory is not part of the course). While this > > won't teach them to be router engineers -- or developers, it > > should have some industry relevance. > > > > > > Most Hunter graduates stay in the Greater NYC metropolitan > > area. Given this, which of these options is better for the > > industry? who is in shorter supply? > > > > Prompt feedback greatly appreciated. Registrar is asking for > > the course description ASAP or sooner. > > > > Thanks! > > Dana Hudes > > CUNY Hunter Computer Science > > former ISP > > >

1 0

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Dan, thanks for the input. IP routing research is a subject near and dear to my heart. I have wanted, for a long time, to do some work on traffic engineering using flow optimization algorithms from the literature applied to BGP policy. Do you think this is sufficiently interesting and useful to InterNAP that they could come up with funding ? In our business not too many PhDs with operational experience so a fellow with the operational experience and a Master's (me) might suffice. As for the coursework: ----- Original Message ----- From: Dan Cohn <dan(a)internap.com> To: Dana Hudes <dhudes(a)panix.com> Sent: Tuesday, August 24, 1999 2:02 AM Subject: Re: Training the next generation: > > > I think you are right on approaching the computer networking industry. We > are always short talented engineers, and spend a great deal of time > seeking the few that are available. > I was a 1st line manager with hiring responsibility for 2 years; while working for Bay Networks Consulting I interviewed candidates there as well. Very hard to find anyone with a clue and analytical skills. So I'm out to make some. > > Fall course is "Telecomputing"; the syllabus I created for the course > > uses Tannenbaum's _Computer Networks_ and tries to cover a range of things. > > It may be a bit late to suggest this, but please keep in mind for the > future an alternative text, entitled "An Engineering Approach to Computer > Networking", by Keshav. Interesting. I shall have to quickly check it out. >While Tannenbaum has long been recognized as a > solid foundations book, Keshav's material is much less esoteric, more up > to date, and replaces complex statistical mathematics of little use to the > common network engineer You think Tannenbaum is bad, look at Grodzinsky. I about fell off my chair when their network simulation exercise involves MathCAD! The introductory exercise involves a bit of FFT using Maple. I know neither of these programs, but I've seen that they are now used in undergraduate mathematics education extensively (when I took calculus and D.E. etc. it was the same as always had been -- lecture + recitation + homework with pencil and paper). Nonetheless Grodzinsky has some good projects for students to implement various network aspects so I chose it as 2nd text for the class. >with practical examples from real-world production > networks. I believe you will find the Keshav course material is as > comprehensive as the Tannenbaum book, but much more fun to read. Sounds great. Wish I'd had this information four weeks ago when I chose the book for the course. Class starts Monday. > > >Course project will likely be design and implement a bridge, possibly > >including source-route and certainly including spanning tree. > > Unfortunately, the term 'bridge' has not been used actively in computer > networking for a number of years, and when it has it generally refers to > either a concept or support for a legacy environment. Spanning tree is a > very important protocol, and can form the conceptual base for many > protocols which followed it, but may not deserve more than a few days > coverage, especially in an introductory class designed to prepare students > for current and future technologies. 'design and implement a bridge' is > slightly troubling to me, as bridges are fairly passive devices which are > generally avoided in current practice.. Unless you intend to have the > students actually write an implementation of spanning tree, this task > should involve little more than plugging two devices into a hub. When I say build a bridge, I mean write one in software. Complete with spanning tree implementation, BPDUs etc. A LAN switch acts like a multiport bridge. It just has hardware assist to move frames around. BTW, I build bridging in to use the facility in a WAN switch rather than let it do IP forwarding. Remote city dialup (multiple chassis, each 2xDS-3 dial trunks) comes to ATM switch Ethernet interface and is bridged to remote router which has an ATM PVC configured for ATM Half Bridge. No spanning tree. Only the remote ATM switch knows its bridging, the central switch just pushes the ATM cells to the router. > > Source route bridging, on the other hand, while slightly more complex, is > also considered a legacy protocol, and efforts are being made wherever > possible to replace SRB networks with scalable, routable alternatives. SNA will never die completely. Wish it would. Keeps coming up. > Again, in my own teachings, this is a topic which usually gets a few hours > in passing, as a legacy protocol which hopefully no student will > encounter.. and when they do encounter it, it will most certainly be for > the purpose of finding a migration strategy to something more scalable, be > it SNA over DLSW, or a full migration to IP. I agree that SRB first of all is an extra complexity students don't need and is of lesser importance. I will introduce the real nasty, translational bridging real quick and explain why we don't do such things. > > > Early on, coverage of WAN include project with PCM and such. > > A syllabus is posted at http://harmony.hudes.org/Telecomputing.html > > Students will have a broad base in a variety of networking topics. > > Focus on Ethernet in the LAN and PPP and ATM in the WAN. > > Excellent material. Be mindful of the order at which you bring in > discussion of ATM, as it does not strictly conform to the OSI model, which > should be well understood before ATM is discussed, IMO. A good segue into > ATM is Frame Relay, which is still rather prolific in the industry. Tannenbaum doesn't try to cover ATM all at once. He splits up the coverage according to the OSI layers. Notably, in this 3rd edition layers 5 and 6 are just about gone. That's fine for router engineers but ironically things like XBR are presentation layer and important to client/server programmers. I suppose one can shove XBR into application layer. > > > Spring is a "special topics" course. I've some flexibility here. I'm weighing > > two alternatives, and want some feedback. Of all possible things, the > > acting chair and I narrowed to two possible courses: > > 1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his > > syllabus from Purdue as a starting point. No time in this course for any > > physical layer or data link stuff beyond a cursory overview of Ethernet > > as we move at high speed to the network layer and IP forwarding. > > This is a good text, and you are likely correct about the timeframe. I > encourage you to also delve into some projects from Network Programming by > Stevens, if your students are expected to have a certain degree of > competency with programming for Unix in C, as this tends to really cement > the learning process. Good projects include having students write an > implementation of nslookup, talk, or ftp from scratch, using the RFCs as a > resource. Interesting project idea instead of having them work on routing protocols. But, source to all the things you mention is readily available. OSPF source isn't quite so easy to find. > > > Comer's graduate course has students build a router but this is probably > > too much for undergraduates. > > Quite true.. routers are complex things. This is a project for people who > not only are already extremely comfortable with the network layer > protocols they are implementing towards, but also who have a good grasp on > multiprocessing, have a fairly good understanding of routing protocols, > and have significant experience writing network code. Even a simple router is pretty complicated. But if I use UNIX (or NT) as a base, we skip ahead to routing protocols and don't have to implement IP forwarding. Multiprocessing they get from the OS course. > > >Instead an OSPF implementation, including all the options (especially > > NSSA) . A cursory introduction to sockets programming with the course > > focus on routing algorithms (i.e. RIP, OSPF, and BGP4). > > Can this one course (my fall course hasn't sufficient registration > > to make the 2 semester sequence in networking we'd hoped; maybe next > > year). > > Please, please include ISIS and some discussion of emerging multicast > standards in this discussion. Students familiar with emerging dominant > technologies are much more marketable and useful than those who know what > everyone else has already learned from experience. Much too little > emphasis is placed on ISIS and multicast considering the likelihood for > their relative abundance in the future. Interesting that you put ISIS as an emerging rather than past protocol. Multicast is on my agenda somewhere. They're in good shape to deal with such things given the heavy data structures background they bring to the course (discrete structures is 1 semester, then 3 semesters of algorithms + data structures; all in C++). Certainly I shall include it somewhere in the Telecomputing course; the spring also should have something about it but not sure yet where and how. > > > > > 2. Network application programming. Java clients, Perl and Apache > > server side (or perhaps Java servlets). Hunter students know C++ fairly > > well by their senior year; Java is an easy transition. The entire class > > would divide into teams with assignments that comprise various parts of > > the client and server portions. The project would be a turn-based > > simulation game (I used to play these and have a number of appropriate > > games with play-by-mail options, game rule design and/or game theory is > > not part of the course). While this won't teach them to be router > > engineers -- or developers, it should have some industry relevance. > > > > By the time a student reaches their senior year, they should be very well > capable of writing the entire gaming system on their own, including client > and server components. Systems like this generally do not involve very > much network code, and dividing it up too much would be a shame. Please > also consider having your students do some of this work with CORBA, and > implement different components in a few different languages. Again, make > your students useful because they have done what other people are starting > to do or thinking about doing, not because they have done a little bit of > what everyone in the industry already knows very well how to do. > The gaming system is bigger than you think. Consider GUI client. There is the question of the application protocol for communicating moves etc. . The trouble is that there is a considerable amount of non-network related design and implementation (e.g. the economic system, combat system etc.). It really is a fine line between such a project and distributed systems. After all, the user should not see the network in such a game. > > Most Hunter graduates stay in the Greater NYC metropolitan area. > >Given this, which of these options is better for the industry? > > Presently, people who understand network engineering from a routing, > design, and troubleshooting point of view are in extremely high demand. > People who can write some network enabled code are in relatively small > demand. Salaries for the former in NYC start at abt $70k, salaries for > the latter start at $35-40k. Concentrate on IP routing, emerging > technologies in IP routing, and coding to solidify that understanding, is > my advice. Thanks. But, this isn't an operations course. Rather, to prepare them to work for Lucent/Ascend, cisco, Bay, etc. in building the stable products network architects require. Network architecture, properly done, involves traffic engineering. Where exactly do you want the traffic to flow. Rather than optimize at the AS level, a computer can create a policy to optimize at the prefix level (you are, after all, already doing per-prefix filtering if you're careful). Regardless of the goals and constraints. So many of the folks configuring routers *can't program*. Not a bit. They're former electrical engineers. In fact, I've had agencies tell me I'm not qualified for the position of network engineer because my degrees are computer science not electrical engineering. Who do they think builds routers, EEs alone? Eek. Musicians write better code than most EEs I've seen. > > Feel free to call on me if I can be of any assistance in your planning or > during the instruction of your course, Well, any of you folks who happen to have any old (or new, you manufacturer folks here's a chance to get your new toys in front of the next generation) network equipment you can donate or loan to Hunter to build up our network student lab we would appreciate it. I don't take such directly, but please contact me if you can help and I will make the introductions all around to make it happen. Thanks very much to all for the feedback. It sounds like both my courses are needed but the IP course is better. That's somewhat expected from this crowd. Dana Hudes > > Thanks, > > Daniel Cohn > Senior Network Development Engineer > InterNAP Network Services > Seattle, WA > >

1 0

Re: Power outage in Vienna, Virginia and other things
by Sean Donelan 24 Aug '99

24 Aug '99

SEAN(a)dra.COM (Sean Donelan) writes: >While checking on Vienna, I also found I had problems reaching sites >in Boston, MA. Both Tufts University and Boston University are off-net. >I haven't heard of anything happening in the Boston area. I know Tufts >switch providers, but I don't know about BU. So the information in the >RADB may not give good information for reaching the correct upstream >provider. The sites have come back up, and it appears the former nearnet lost more customers than I knew about. Because the new provider doesn't include information in an public RADB-like database, I didn't realize all the sites went through the same place. I was looking for and asking the wrong provider. UUNET had announced on their maintenance page they are replacing routers in Boston, MA this morning. The router maintenance affected the sites I was using to check for problems: computerworld.com, tufts.edu, and bu.edu. I guess its time to look for new beacons. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Power outage in Vienna, Virginia and other things
by Sean Donelan 24 Aug '99

24 Aug '99

There is a power outage in the Vienna, VA area which appears to be affecting a few co-location facilities in the area. Some web sites I know hosted in the area are down. MAE-East is currently up. While checking on Vienna, I also found I had problems reaching sites in Boston, MA. Both Tufts University and Boston University are off-net. I haven't heard of anything happening in the Boston area. I know Tufts switch providers, but I don't know about BU. So the information in the RADB may not give good information for reaching the correct upstream provider. And there is a DS3 cable problem in Alameda, CA. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Hi ! I'm teaching networking this year at CUNY Hunter College here in Manhattan. I would like your input as industry members what skills would have value to you in a new graduate computer science major (the students are seniors). Fall course is "Telecomputing"; the syllabus I created for the course uses Tannenbaum's _Computer Networks_ and tries to cover a range of things. Course project will likely be design and implement a bridge, possibly including source-route and certainly including spanning tree. Early on, coverage of WAN include project with PCM and such. A syllabus is posted at http://harmony.hudes.org/Telecomputing.html Students will have a broad base in a variety of networking topics. Focus on Ethernet in the LAN and PPP and ATM in the WAN. Spring is a "special topics" course. I've some flexibility here. I'm weighing two alternatives, and want some feedback. Of all possible things, the acting chair and I narrowed to two possible courses: 1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his syllabus from Purdue as a starting point. No time in this course for any physical layer or data link stuff beyond a cursory overview of Ethernet as we move at high speed to the network layer and IP forwarding. Comer's graduate course has students build a router but this is probably too much for undergraduates. Instead an OSPF implementation, including all the options (especially NSSA) . A cursory introduction to sockets programming with the course focus on routing algorithms (i.e. RIP, OSPF, and BGP4). Can this one course (my fall course hasn't sufficient registration to make the 2 semester sequence in networking we'd hoped; maybe next year). 2. Network application programming. Java clients, Perl and Apache server side (or perhaps Java servlets). Hunter students know C++ fairly well by their senior year; Java is an easy transition. The entire class would divide into teams with assignments that comprise various parts of the client and server portions. The project would be a turn-based simulation game (I used to play these and have a number of appropriate games with play-by-mail options, game rule design and/or game theory is not part of the course). While this won't teach them to be router engineers -- or developers, it should have some industry relevance. Most Hunter graduates stay in the Greater NYC metropolitan area. Given this, which of these options is better for the industry? who is in shorter supply? Prompt feedback greatly appreciated. Registrar is asking for the course description ASAP or sooner. Thanks! Dana Hudes CUNY Hunter Computer Science former ISP

2 1

Paul A Vixie: BIND 8.2.2 (T3B; RC0) is available for general testing
by Paul A Vixie 24 Aug '99

24 Aug '99

fyi ------- Forwarded Message To: bind-announce(a)isc.org Subject: BIND 8.2.2 (T3B; RC0) is available for general testing Date: Tue, 24 Aug 1999 00:01:59 -0700 From: Paul A Vixie <vixie(a)bb.rc.vix.com> Confidence: moderate. This is running on part of F.ROOT-SERVERS.NET and on all of our local production servers. The only reasons it's not a full release candidate are that IXFR is still disabled and we're still tinkering with the NT support. Highlights vs. BIND 8.2.1: Preliminary support for Windows/NT (thanks to BayNetworks). More fixes, especially to DNSSEC, TSIG, IXFR, and selective forwarding. More portability improvements and lint removal (A/UX 3.1.1, SCO 5.0). Better NOTIFY behaviour, especially with large update volume. Better UPDATE handling, including SRV RR support and RFC compliance. Fix for "ndc reload ZONENAME" (specific zone reload) problems. Fix for round robin when multiple CNAMEs are in use. New "min-roots" (MINROOTS) and "serial-queries" (MAXQSERIAL) options. Log files are no longer auto-rotated every time the server starts up. New "ndc reconfig" command only finds new/deleted zones, no stat()ing. New global options for "update-source" and "also-notify". $GENERATE now supports more record types, and options. the distribution files are: ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-src.tar.gz ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-doc.tar.gz ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-contrib.tar.gz the pgp signature files are: ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-src.tar.gz.asc ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-doc.tar.gz.asc ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-contrib.tar.gz.asc the md5 checksums are: 0abf1631852beb1d989b4d41759641bf bind-contrib.tar.gz d82f381d0904ee236b5262abb9ac1484 bind-contrib.tar.gz.asc 4e51a75f0dd42327daa6f922b4fd4fab bind-doc.tar.gz c417a461f329abce517ade68c735f154 bind-doc.tar.gz.asc feb88267cd52196fcf0097b2ef6f04c1 bind-src.tar.gz 38446afd2df7b62af88facf35191ca03 bind-src.tar.gz.asc top of CHANGES says: --- 8.2.2-T3B released --- 783. [support] make res_send() more friendly to the java scheduler. 782. [support] dangling cnames aren't errors, stop logging them. 781. [support] add -n option to ndc command, to run nonstandard named. 780. [bug] UPDATE did not support the AAAA RR. 779. [bug] miscellaneous IXFR fixes. 778. [support] don't complain to syslog about negative caching RRs. --- 8.2.2-T2B released --- 777. [bug] getword() didn't increment lineno at EOF. 776. [bug] the NOERROR_NODATA cookie overlapped a valid rcode. 775. [protocol] we weren't sending properly formated FORMERR responses. 774. [bug] UPDATE did not support the SRV RR. 773. [bug] named-xfer was calling inet_ntoa in one printf. 772. [typo] Typo in ns_parser.y on maybe_zero_port: line. 771. [lint] UNLINK performs a INIT_LINK so explicit INIT_LINK's are nolonger needed after UNLINK. 770. [protocol] dynamic update prerequisites were inappropiately matching wildcards, at variance with RFC 2136. 769. [bug] ordering of CNAMES was driven by original query type. 768. [support] MINROOTS is now a configuration option "min-roots". 767. [clarity] adjust XFR log messages to be more clear about cause. 766. [support] add "serial-queries" option to dynamify MAXQSERIAL. 765. [feature] added evInitID() and evTestID() for NOTIFY work. 764. [bug] DNSSEC changed the semantics of match() without changing all the call sites that cared about it. 763. [bug] NOTIFY events caused by dynamic update weren't being deferred, and multiple NOTIFY events weren't being coalesced. 762. [support] don't rotate log file versions on server startup. 761. [port] named-xfer's openlog() was unconditionally using the LOG_CONS option. now it does what named does. --- 8.2.2-T1A released --- 760. [port] preliminary win/nt from baynetworks (thanks!) 759. [support] new compile time option BIND_IXFR, defaults to "off", since our testing has shown up some problems with it. 758. [feature] new "ndc reconfig" command only finds new/gone zones, doesn't stat() master files or qserial() slave SOA's. 757. [support] FORCED_RELOAD is no longer optional. 756. [support] fixed output format of hmac keys; removed DST chaff. 755. [feature] "also-notify" is now a global option. 754. [bug] the control socket was not checked for event lib compatability. 753. [feature] "ndc help" now returns one line command summaries. 752. [feature] "ndc trace" now takes an optional "level" argument. 751. [support] debugging output could segfault in ns_print.c::addstr. 750. [port] A/UX 3.1.1. 749. [port] #9 has now been done for all Makefiles. 748. [feature] "transfer-source" is now a global option. 747. [support] SORT_RESPONSE is no longer a compile time option, since the behaviour can be turned off at runtime with the "rrset_order fixed;" option. 746. [bug] don't bother rescanning the interfaces if setuid!=root. 745. [protocol] IXFR transmission was just plain wrong in some cases. 744. [support] allow the calling location of strings to be recorded. 743. [feature] $GENERATE now supports more record types, and options. 742. [port] port/sco50 was using /usr/local/etc for its ndc socket. 741. [port] HPUX needed __BIND_RES_TEXT. 740. [bug] #634 had the unfortunate side effect of disabling IXFR. 739. [port] probe for IPv6 structures, solaris openbsd freebsd 738. [bug] invalidate pointers back into linked list when element is removed. 737. [port] solaris: expr is sensitive to LC_COLLATE 736. [bug] potential single file descriptor leak opening /dev/random. 735. [bug] memory leak: having rrset-order set and reconfiguring the server results in a memory leak. 734. [port] linux only fills in as many entries as will fill the buffer with SIOCGIFCONF. 733. [bug] RD is not being set on first message to first forwarder resulting in false "Lame Server" reports and degraded service. 732. [bug] errors reading keys from master files could cause the the server to drop core. 731. [bug] highestFD was not reflecting the highest value the library could cope with. 730. [port] rand() does not modify the LSB on BSD based systems. 729. [bug] allow-query responses were dependent upon cache contents. 728. [bug] it wasn't possible to specify the flags of trusted keys in hex, which was inconvenient since dig prints hex. 727. [bug] TSIG keys weren't properly shared with named-xfer if the zone named contained a slash (/). 726. [bug] TSIG keys weren't reloaded correctly with 'ndc reload'. 725. [bug] only the first key in an acl was matched correctly. 724. [bug] "ndc restart" needed a short delay before checking for the health of a newly started name server. 723. [bug] TSIG signed zone transfer failed on especially large zones. 722. [doc] the example named.conf file had invalid TSIG usage. 721. [bug] duplicate records were tripping the cname-and-otherdata test, which wasn't necessary since they'll be ignored. 720. [port] solaris doesn't have gethostid() the way we build. 719. [lint] lots of lint fixed by bob and paul. 718. [bug] multiple CNAME support was not cycling the cnames in an RRset properly. 717. [bug] wrong /bin/ps flags in solaris prand_conf.h. minor tweak to ports/prand_conf/prand_conf.c to ensure proper flags in future ports. 716. [bug] log files are now closed/reopened on a size basis. 715. [clarity] root servers don't need to be primed. 714. [typo] extra "q" in a message in ns_maint.c. --- 8.2.1 released --- ... ------- End of Forwarded Message

1 0

Re: "Engineer" (Was: Tech contact for Qwest?)
by Vadim Antonov 24 Aug '99

24 Aug '99

J.D. Falk <jdfalk(a)cybernothing.org> wrote: > Yeah, but at least they have a code of ethics. Where'd ours > go? Having to have a written code of ethics is usually a very sure sign that there are problems in this respect. Every time i hear about anything like that i'm reminded of the Moral Code of Bulider of Communism (yes, there was a poster with that text in virtually every classroom in the ussr). That one was a lot more comprehensive, too. Well, the early Internet types have unwritten ethics - and it is a hell lot different from the corporate ethics of the Professional Engineers (tm). Clashes between these two often provide spectacular fireworks :) --vadim

3 2

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Darin, thanks for the feedback. All the bridging issues you mention are covered in Tannenbaum. Packet captures for examples is a good thought. These students are already familiar with the spanning tree algorithm from a previous course, they just don't know that it is good for bridging. I don't have complete details by section but the book details are at http://www.phptr.com/ptrbooks/ptr_0133499456.html for Tannenbaum and http://www.phptr.com/ptrbooks/esm_0130117021.html for the project book by Grodzinsky IP addressing is covered in Tannenbaum, as are routing algorithms. Obviously Tannenbaum doesn't cover OSPF to the same depth as Comer or John Moy's OSPF book. The URL for my syllabus for CSCI 415 Telecomputing is in my original post. A syllabus for a TCP/IP course is posted by Comer at http://www.cs.purdue.edu/~comer/courses.html . What I'm most concerned for is the special topics course. There is no time for bridging and other L1/L2 stuff (or ATM wherever layer you stick it). That is in Telecomputing. ----- Original Message ----- From: Darin Divinia <ddivinia(a)broadcast.com> To: Dana Hudes <dhudes(a)panix.com> Sent: Monday, August 23, 1999 11:48 PM Subject: Re: Training the next generation: > I would include some basic stuff on IP addressing. > Some fundamentals of routing protocols (what makes ones routable) > Difference between a routing and routable protocol. > Sniffer traces of protocols. > Bridging, specifically how a MAC table works and what a port off a bridge > should see Same for a bridge for that fact. > > Do you have the details of what you are going to teach by section? That > would help me see what is missing. > > D. > > > At 12:12 AM 8/24/99 -0400, you wrote: > >Hi ! > > I'm teaching networking this year at CUNY Hunter College here in Manhattan. > >I would like your input as industry members what skills would have value to > >you in a new graduate computer science major (the students are seniors). > >Fall course is "Telecomputing"; the syllabus I created for the course uses > >Tannenbaum's _Computer Networks_ and tries to cover a range of things. > >Course project will likely be design and implement a bridge, possibly > >including source-route and certainly including spanning tree. Early on, > >coverage of WAN include project with PCM and such. > >A syllabus is posted at http://harmony.hudes.org/Telecomputing.html > >Students will have a broad base in a variety of networking topics. Focus on > >Ethernet in the LAN and PPP and ATM in the WAN. > > > > > >Spring is a "special topics" course. I've some flexibility here. I'm > >weighing two alternatives, and want some feedback. > >Of all possible things, the acting chair and I narrowed to two possible > >courses: > >1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his > >syllabus from Purdue as a starting point. > >No time in this course for any physical layer or data link stuff beyond a > >cursory overview of Ethernet as we move at high speed to the network layer > >and IP forwarding. Comer's graduate course has students build a router but > >this is probably too much for undergraduates. Instead an OSPF > >implementation, including all the options (especially NSSA) . A cursory > >introduction to sockets programming with the course focus on routing > >algorithms (i.e. RIP, OSPF, and BGP4). > >Can this one course (my fall course hasn't sufficient registration to make > >the 2 semester sequence in networking we'd hoped; maybe next year). > > > >2. Network application programming. Java clients, Perl and Apache server > >side (or perhaps Java servlets). Hunter students know C++ fairly well by > >their senior year; Java is an easy transition. The entire class would divide > >into teams with assignments that comprise various parts of the client and > >server portions. The project would be a turn-based simulation game (I used > >to play these and have a number of appropriate games with play-by-mail > >options, game rule design and/or game theory is not part of the course). > >While this won't teach them to be router engineers -- or developers, it > >should have some industry relevance. > > > > > >Most Hunter graduates stay in the Greater NYC metropolitan area. Given this, > >which of these options is better for the industry? who is in shorter supply? > > > >Prompt feedback greatly appreciated. Registrar is asking for the course > >description ASAP or sooner. > > > >Thanks! > >Dana Hudes > >CUNY Hunter Computer Science > >former ISP > >

1 0