"You win. I give. Uncle." (And I was serious, not sarcastic, about the 'blazer. YMMV,) -M --- Martin Hannigan hannigan@verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog@merit.edu <owner-nanog@merit.edu> To: North American Network Operators Group <nanog@merit.edu> Sent: Mon Jan 17 06:56:11 2005 Subject: Re: Association of Trustworthy Roots? [I first met Eric when I was a consultant helping put together the NetBlazer for Telebit. With my ISP hat on, we used NetBlazers for many years, very stable. I only wish that BellSouth had been as stable. We eventually switched to PortMasters for the improved diagnostics of BellSouth's continually flapping lines. However, we continued to use the old NetBlazers for internal routing up until a year or so ago. They worked well, and supported AppleTalk, too.] At Martin's insistence, and with Eric's kind permission: Eric Brunner-Williams in Portland Maine wrote:
I didn't point out to him what he already knew. That he wrote me Sunday morning (Sun, 16 Jan 2005 07:05:42 EST), a reply off-list to my note to Perry before going to bed around midnight. "What did I miss? Why would they call MIT's attorney?", and that I called his cell and office about a half-dozen times until I got him around 8am, and after 10 or so minutes of exchanges of observations on the situation, punctuated periodically by "I'm sure you understand there is nothing we can do", and "I don't work on the GRS side of Verisign", I concluded with "I have a message for Chuck Gomes, tell him that liability minimization (doing nothing until ICANN process authorized) is the wrong choice. This is a stability of the internet issue."
Seems to me that Eric worked pretty hard on this at no recompense to himself. And remember he was a voice of reason, cautioning this list to treat everyone as human beings. Martin may have finally gotten the job done, and it may have been beyond his formal job description, but I wish he'd remember to treat the rest of us as human beings, too. =------- Original Message -------- From: "Hannigan, Martin" <hannigan@verisign.com> Date: Mon, 17 Jan 2005 00:50:46 -0500 Why isn't this on NANOG where it started? -M PS: I used the netblazer in 93 and it was a POS. --- Martin Hannigan hannigan@verisign.com Verisign, Inc. =----Original Message----- From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> To: Hannigan, Martin <hannigan@verisign.com> Date: Sun Jan 16 16:57:52 2005 Martin, Bill and I worked together on the first demand-dialup router, the NetBlazer. That was in 1991. Scott may have a different opinion, and arguably RRP registrar/registry is semantically distinguishable from EPP registrar/registry semantics (but I wrote an I-D that contained just such a comparison to show functional equivalence), but having spent 1999 - 2003 focused on provisioning and registrar/registry semantics, I have an opinion on the correctness of the events of yesterday and today. Earlier today I wrote off-list this: Just to be formal and clear however, we had an incoherent dns, and caching resolver operators introduced the incoherency to correct for an error published by the authoritative resolver operator. As one of the EPP authors, I see provisioning and publication as two distinct functions. How state change in the registry database was provisioned -- the registrar error, is not controlling on what the registry publishes as a zonefile. VGRS erred in publication of bad data, and its error persisted for at least 12 hours, if not 24 or more, after notice. Everything else is just policy. Your milage obviously varies. VGRS's publication of the authoritative panix.com data was incorrect. Bill wrote: The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. I'd have used a different gramatical construct, and not distinguished between panix the registrant and panix the isp, and I've no private knowledge of Dotster's having made an affirmative response, but the registrant's claim of non-receipt of transfer is sufficient. Bill wrote: Notification and approval are required by the process. The weaker condition is simply notification, already asserted lacking by the controlling authority, the registrant. Bill wrote: Therefore, it was proven to be circumvented. QED. Xfr w/o notice is the result, but not the condition, so yes, QED. Bill wrote: Now, as to the actual mechanism of circumvention, that has not yet been revealed here. Knowlege is partial, however, unless VGRS makes the complete transactional history public, it can't make a defense that any claim is invalid based upon a claim that the knowledge is partial. Bill wrote: All we know is that a registry *supervisor* stopped the workers from finishing their investigation. I don't know how Bill knows that, but I know that I don't know the complete transactional history from VGRS, and the reason for non-disclosure of the state of the database is policy, and policy originates in supervisorial VGRS staff, not operations staff. Bill wrote: Clearly, this .com registry operator is not trustworthy. I think everyone in the DNSSEC community holds this view, and we're all attempting to work towards trust in the DNS. It may not be possible for the .com zone, for reasons that frankly appear to be policy based rather than mechanism based, but as things stand, the .com registry operator is not trustworthy. There are registry operators to who's operational art even less trust can be associated, e.g., NeuStar, my former employeer, and registry operators to who's operational art more trust can be associated, e.g., SWITCH. I'm sorry you felt that citing Martians was responsive to Bill's comments. I don't think they were. I'm rather fond of Martians. Bogons too. Eric -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
(And I was serious, not sarcastic, about the 'blazer. YMMV,)
Martin, That's OK, I never got work for a router vendor after that, a solution that I've now completeley generalized, having discovered a trivial but obscure and beautiful technique, as any good mathematician must. However, since I was most of the QA for the NetBlazer, and whiled away my paid hours with making tcl/tk scripts to irritate units under test, which was somewhat novel in 1991, silly stuff like bringing up and tearing down a connection all night long to prove the existance of a memory leak, and networks to prove the function of rip, I'm curious what part of the NetBlazer was a piece of shit? In this period of time, the White Knights built the InterOp shownets and we had comparative access to quite a lot of vendor product, and know that the red buttons on Wellfleets were correctly positioned on the front, for easy access. We used NetBlazers for dial-up outbound (we were topologically quite diverse by '91, our last show in the San Jose facility) and I don't recall anything ... resembling the behavior that I could characterize as POS like function. Data please, but off-list. Bill will be interested too I expect. Eric
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> writes:
In this period of time, the White Knights built the InterOp shownets and we had comparative access to quite a lot of vendor product, and know that the red buttons on Wellfleets were correctly positioned on the front, for easy access. We used NetBlazers for dial-up outbound (we were topologically quite diverse by '91, our last show in the San Jose facility) and I don't recall anything ... resembling the behavior that I could characterize as POS like function.
My recollection of that show was "T-1 to BARRnet", not bonded-Netblazer-dialout, but I didn't "work the show" until the following spring, so my recollection could be at fault. I wouldn't characterize Netblazers as being particularly cruddy compared to other options available at the time. Remember that this was the era of the Cisco ASM, the Encore/Xylogics Annex (Wellfleet hadn't changed their name to Bay yet, much less bought the Annex product line), some nasty 3com terminal server of which my memory has thankfully purged most details and the gone but not lamented Cisco TRouter. The Netblazers worked pretty darned well when plugged into Telebit modems. Third party modems, well, there were a lot of knobs you could twist, and not the best in the way of documentation on what to do with 'em. Based on my experience with them, I'm quite sure they were fabulous devices capable of being configured in the field to do just about anything, if you had the level of familiarity with their internals that someone who worked QA for them would have had. ---Rob
My recollection of that show was "T-1 to BARRnet", not bonded-Netblazer-dialout, but I didn't "work the show" until the following spring, so my recollection could be at fault.
Hey Robert, Correct, but we stuck in the NB because the funtional principle (demand dial and route) was distinct. The T-1 to BARNet was the fastpath (but providing it didn't entitle the provider to one of my tee shirts). Fun. Before the greedbots went non-linear on the rising edge of the bubble. Eric
Netblazers were fine except the Telebit lied about the SYN35 card being usable with a T-1. Bad terminal servers? How about overpriced ones like the USR Total Control Hubs. ----- Original Message ----- From: "Robert E.Seastrom" <rs@seastrom.com> To: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net> Cc: "Hannigan, Martin" <hannigan@verisign.com>; <wsimpson@greendragon.com>; <nanog@merit.edu> Sent: Tuesday, January 18, 2005 10:10 Subject: Re: netblazer Was: baiting
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> writes:
In this period of time, the White Knights built the InterOp shownets and we had comparative access to quite a lot of vendor product, and know
that
the red buttons on Wellfleets were correctly positioned on the front, for easy access. We used NetBlazers for dial-up outbound (we were topologically quite diverse by '91, our last show in the San Jose facility) and I don't recall anything ... resembling the behavior that I could characterize as POS like function.
My recollection of that show was "T-1 to BARRnet", not bonded-Netblazer-dialout, but I didn't "work the show" until the following spring, so my recollection could be at fault.
I wouldn't characterize Netblazers as being particularly cruddy compared to other options available at the time. Remember that this was the era of the Cisco ASM, the Encore/Xylogics Annex (Wellfleet hadn't changed their name to Bay yet, much less bought the Annex product line), some nasty 3com terminal server of which my memory has thankfully purged most details and the gone but not lamented Cisco TRouter. The Netblazers worked pretty darned well when plugged into Telebit modems. Third party modems, well, there were a lot of knobs you could twist, and not the best in the way of documentation on what to do with 'em.
Based on my experience with them, I'm quite sure they were fabulous devices capable of being configured in the field to do just about anything, if you had the level of familiarity with their internals that someone who worked QA for them would have had.
---Rob
Netblazers were fine except the Telebit lied about the SYN35 card being usable with a T-1.
uh, the test lab used T-0 (56kb) for the syn interface, so integers greater than 0 would be ... creative on someone's part, and TB mktg could be just as creative as the rest of the XX mktg golf pros.
participants (4)
-
Eric Brunner-Williams in Portland Maine -
Hannigan, Martin -
John Palmer -
Robert E.Seastrom