North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: netblazer Was: baiting
- From: Hannigan, Martin
- Date: Mon Jan 17 10:16:15 2005
"You win. I give. Uncle."
(And I was serious, not sarcastic, about the 'blazer. YMMV,)
From: email@example.com <firstname.lastname@example.org>
To: North American Network Operators Group <email@example.com>
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
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" <firstname.lastname@example.org>
Date: Mon, 17 Jan 2005 00:50:46 -0500
Why isn't this on NANOG where it started?
PS: I used the netblazer in 93 and it was a POS.
From: Eric Brunner-Williams in Portland Maine <email@example.com>
To: Hannigan, Martin <firstname.lastname@example.org>
Date: Sun Jan 16 16:57:52 2005
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.
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.
Notification and approval are required by the process.
The weaker condition is simply notification, already asserted lacking
by the controlling authority, the registrant.
Therefore, it was proven to be circumvented. QED.
Xfr w/o notice is the result, but not the condition, so yes, QED.
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.
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.
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.
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32