- Test - lists.nanog.org

send info
by Allwyn Crichlow 20 Jul '95

20 Jul '95

send info

1 0

broken glue in .net domain
by Michael Dillon 19 Jul '95

19 Jul '95

We are attempting to get the Internic to change our secondary nameserver for the junction.net domain but not having much luck. Our change requests for in-addr.arpa went through in a few days. But the Internic rejected the first request saying we needed to use a new form. So we resubmitted but it is now almost two weeks ago. What is the point of a new form if we cannot get things updated any faster? Then we noticed that DNS to our new secondary nameserver ns2.bc.net was acting wierd. So we dug into the .net domain and discovered several A records with the WRONG IP ADDRESS. I don't know whether it was a typing error at the Internic or whether somebody at BC.NET screwed up, but why do changes like this take so long if nobody even verifies such a simple and obvious thing? You can see this by trying the whois command on sno.net, infoserve.net or concordpacific.net Compare the IP address for ns2.bc.net with the one given by nslookup when talking to an authoratative server for the domain like jade.bc.net In addition there is at least one glue record for ns1.bc.net which erroneously reports its IP address to be 128.198.4.1 which is also wrong since ns1 is the same as jade.bc.net Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com michael(a)junction.net

1 0

Re: Call for Mbone reflectors
by rsingleton＠hai-net.com 16 Jul '95

16 Jul '95

Hi my name is Rickie Singleton from Arlington VA. I would like to become an active participant on the Mbone and I would like to set up a reflector. I will be using an SGI extreme 2. Can anyone point me in the right direction to get a reflector setup. I am hoping the mrouted 3.x will fix my mbone problem and I am currently running CUSEEME on my mac. Now comes the task of setting up a reflector on the SGI. Would appreciate any comments. thx Rickie ______________________________ Reply Separator _________________________________ Subject: Call for Mbone reflectors Author: bmanning(a)ISI.EDU at internet Date: 7/12/95 12:06 PM > > Bill, > > We have the mbone slot reserved for ISN. I will post this note to teachers > today and begin doing what I can to get them involved. What needs to be > done to push providers to get reflectors set up? > > Thanks, > J > =-=-=-=-NOTE TO POST TO ED LISTS-=-=-=-= > To all Educators able to use CU-SeeMe this summer! > > The Internet School Networking (ISN) group of the Internet Engineering > Task Force (IETF) will be broadcasting its thrice-yearly meeting over the > mbone on Monday, July 17. The meeting will be held in Stockholm, Sweden, > from 9:30 to 11:30 a.m. local time. > > If you would like to participate, please notify me as soon as possible! > > Thanks, > Jennifer Sellers > ISN Co-chair > > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > sellers(a)quest.arc.nasa.gov NASA's K-12 Internet Initiative > gopher quest.arc.nasa.gov Sterling Software > http://quest.arc.nasa.gov 700 13th Street, NW > phone: 202-434-8954 Suite 950 > fax: 202-434-4599 Washington, DC 20005 > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > > =-=-=-=-END OF NOTE TO ED LISTS-=-=-=-= > Hi all, If we are actually going to have real teachers participate in the ISN - WG remotely, there should be an identified reflector net setup, since most of the target audience has access to CUSeeMe and not traditional mbone tools. (Odd, traditional & mbone linked together.. :) It should be possible to identify where on the Mbone topology current reflectors sit, and then we will have a better idea where new reflectors need to be. What I really want to avoid is a reflector hosted at the IETF site and all that CUSeeMe traffic converging on that machine.. :) Any clues/assistance etc. would be helpful. -- --bill

1 0

Re: New Reflector info (fwd)
by bmanning＠ISI.EDU 12 Jul '95

12 Jul '95

> We have a version of the new reflector code up on the Cornell > reflector at 132.236.91.204 now. However, it only tracks for new versions > of the desktop app, the Mac version of which will go to alpha testers today > maybe. We're trying to update the reflector so it will also track (more > crudely) the old versions of the app. As this will be the first version of > the reflector to be released in binary only (except to source licensees), > we're co-ordinating with White Pine to get it compiled for all the popular > platforms and binaries posted. We may have updates out several times in > the next couple weeks as the bw management algorithms get tuned. > If all goes well, we should have both Mac and Windows apps out as > beta versions by the time of IETF. > Some thought on best way to configure reflectors for IETF is > probably a good idea. In general, a feed from a reflector at IETF to the > mbone, picked up by other reflectors in useful places might be a good > approach. > > Cheers, -Dick > > >Bill Manning from ISI is trying to set up and MBONE/CU-SeeMem > >transmission of some IETF sessions from Sweden in 2 weeks. He > >wanted to know when the nex reflector software with the > >better bandwidth management will be released - and if not before > >IETF, is there a way to push the release day up.. > > > >martyne > > --bill

1 0

Call for Mbone reflectors
by bmanning＠ISI.EDU 12 Jul '95

12 Jul '95

> > Bill, > > We have the mbone slot reserved for ISN. I will post this note to teachers > today and begin doing what I can to get them involved. What needs to be > done to push providers to get reflectors set up? > > Thanks, > J > =-=-=-=-NOTE TO POST TO ED LISTS-=-=-=-= > To all Educators able to use CU-SeeMe this summer! > > The Internet School Networking (ISN) group of the Internet Engineering > Task Force (IETF) will be broadcasting its thrice-yearly meeting over the > mbone on Monday, July 17. The meeting will be held in Stockholm, Sweden, > from 9:30 to 11:30 a.m. local time. > > If you would like to participate, please notify me as soon as possible! > > Thanks, > Jennifer Sellers > ISN Co-chair > > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > sellers(a)quest.arc.nasa.gov NASA's K-12 Internet Initiative > gopher quest.arc.nasa.gov Sterling Software > http://quest.arc.nasa.gov 700 13th Street, NW > phone: 202-434-8954 Suite 950 > fax: 202-434-4599 Washington, DC 20005 > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > > =-=-=-=-END OF NOTE TO ED LISTS-=-=-=-= > Hi all, If we are actually going to have real teachers participate in the ISN - WG remotely, there should be an identified reflector net setup, since most of the target audience has access to CUSeeMe and not traditional mbone tools. (Odd, traditional & mbone linked together.. :) It should be possible to identify where on the Mbone topology current reflectors sit, and then we will have a better idea where new reflectors need to be. What I really want to avoid is a reflector hosted at the IETF site and all that CUSeeMe traffic converging on that machine.. :) Any clues/assistance etc. would be helpful. -- --bill

1 0

MAE policies?
by Andras Salamon 11 Jul '95

11 Jul '95

There is an initiative here in South Africa to set up equivalents of MAE-East and MAE-West to achieve local connectivity between the separate ISP networks. Does anyone have documentation on the MAEs, especially policy? Pointers to ftp or web sites would be great. -- Andras Salamon andras(a)is.co.za

1 0

RSdv5.1
by bmanning＠ISI.EDU 10 Jul '95

10 Jul '95

Release 5.1 of the Route Server deamon is now available from: http://www.isi.edu:80/div7/ra/source.html --bill

5 8

NANOG Meeting
by Pam Ciesla 10 Jul '95

10 Jul '95

The next NANOG Meeting will be in Pittsburgh, PA, September 11 & 12. Directions, hotels and other info will follow at a later date. Pam Ciesla

1 0

auto-dbm outage
by Jake Khuon 07 Jul '95

07 Jul '95

There was a failure in the auto-dbm mechanism sometime between tuesday and thursday night. Any objects submitted during that time failed acceptance. The problem has been corrected and Merit is attempting to resubmit objects from the mail logs. This will take some time. However, if you feel that your objects did not make it into the database, please resubmit it to auto-dbm(a)ra.net for auto-parsing. We are sorry for any inconveniences the outage has caused and are taking steps to see that problems such as this do not crop up again. Thank your patience. -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 763-4907 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +======[ Suite C, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105 ]======*/

1 0

Re: Last Call: IPSEC drafts -> Proposed Standards
by bmanning＠ISI.EDU 05 Jul '95

05 Jul '95

> > > bmanning(a)isi.edu writes: > > I think that a significant point is not that MD5 is "weak" but that it is > > slow, by almost any standard. RFC 1810 discusses this problem in depth. > > If we, as a community are willing to live with reduced speed networks, then > > the use of MD5 is indicated. If we, as a community require 100Mbps and > > greater services, then MD5 is -NOT- a viable solution and requiring its > > deployment is as bad or worse than no security at all, since people will > > turn it off to get the performance that they have today. > > > > People are generally not willing to sacrifice performance for security. > > Use of MD5 is not required. Implementation of the MD5 transform for > interoperability is required. There is no requirement to run any > security at all at any time unless you like. > then we get the 99% problem indicated earlier. slow protocols are available now, through the use of IP options. Although there, almost no-one uses them due to the processing constraints. This is yet one more case of selecting the least common demoninator, which almost noone will use. Louie, why doesn't your employer use IPsecurity today? It's available via IP options. (Perhaps we should ask operations types if they are willing to accept a security model which robs them of throughput on todays networks and prevents them from using faster transports in the future.) (Note to the NANOG community. Please review the proposed IP Security docs and RFC 1810. Perhaps the IESG would be willing to take input from an operations perspective here.) As for other transforms... Please contact Dr. Joe Touch (touch(a)isi.edu) for a writeup of his efforts in this area. -- --bill

3 2