netblazer Was: baiting

Hannigan, Martin hannigan at verisign.com
Mon Jan 17 15:14:24 UTC 2005



"You win. I give. Uncle."  

(And I was serious, not sarcastic, about the 'blazer. YMMV,)

-M


---
Martin Hannigan
hannigan at verisign.com
Verisign, Inc.


-----Original Message-----
From: owner-nanog at merit.edu <owner-nanog at merit.edu>
To: North American Network Operators Group <nanog at 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 at 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 at verisign.com
Verisign, Inc.


=----Original Message-----
From: Eric Brunner-Williams in Portland Maine <brunner at nic-naa.net>
To: Hannigan, Martin <hannigan at 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



More information about the NANOG mailing list