Peering problem with NSP

From: (Brian Dickson)
I do wish you'd feel free to ask us these sorts of questions directly.
We're more
than happy to provide you with an explanation, and an honest answer based
on the facts
will go a lot farther towards providing you with a solution, than open
speculation on a
mailing list.

You cut off his excellent rationale, which was (Quoting Matt Harrop):

# before I start butting heads with their
# management, I want to be sure of the technical issues.

Now, here is exactly what you ought to desire -- an informed customer.
Yet, you publically castigate him for asking a mailing list which deals
with _exactly_ these technical issues.

Frankly, it is this sort of unenlightened, baseless opinion that gives
Usenet its deserved reputation. It certainly doesn't reflect the level of
professionalism that a reputable NSP should display, on this list
in particular.

This rather surprises me, since I don't believe that this is a Usenet
distributed list.

My personal reaction was also, "they want you as a captive customer".

You say:

... Transit ASes
cannot be
provided to you at this time on a guarenteed basis. If you use us as
default, this is not a problem....


The reason we cannot
guarantee transit AS connectivity is a direct result of not being your default
connection. If you select us as default, we can guarantee transit access. The
particulars behind that are technical;

I surely don't understand what default routing (which would only be
outgoing) has to do with your advertisements to other ASs (which would
provide him incoming reachability).

So, perhaps you can enlighten this technical mailing list?

To conclude, this person states that he is a "service provider".
Providers _should_ be multiply homed. This is encouraged!
          Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2