Owen DeLong wrote:
> Then why is IPv6 deployment happening faster in the internet core than
> at the edge?
> The real world seems to defy your claims.
Which world, are you talking about? Martian?
> This has been experimental with no forward progress since 2001.
Obviously because it is a new pr
> Good morning Randy -
it is late afternoon
> Are you indicating that RPKI services should be offered without any
> RPA (and/or CPS) at all, or that these agreements should legally
> adhere without explicit agreement? There is an statement expressing
> that CPS or RPA might benefit from
Sean Harlow wrote:
> None of these options are impacted by being behind a NAT as long
> as they have the ability to open a port via UPnP or equivalent,
> so if in an ideal world all client software understood SRV
> records this particular negative of NAT would be of minimal impact.
My point is th
On Sep 7, 2012, at 7:31 AM, Randy Bush
wrote:
>> If a relying party's use of PKI infrastructure legally equated to
>> acceptance of the relying party agreement (RPA), then having an
>> explicit record of acceptance of the RPA would not be necessary.
>>
>> Alas, it does not appear possible t
This has been experimental with no forward progress since 2001.
Any sane person would conclude that the experiment failed to garner any
meaningful support.
Is there any continuing active work on this experiment?
Any running code?
Didn't think so.
Owen
On Sep 6, 2012, at 23:23 , Masataka Ohta
On Sep 6, 2012, at 23:30 , Masataka Ohta
wrote:
> Andrew Sullivan wrote:
>
>>> the DNS and won't discover anything about the DNS that can't be had
>>> via getaddrinfo() until long after its too late redefine the protocol
>>> in terms of seeking SRV records.
>>
>> Oh, sure, I get that. One of
On Sep 6, 2012, at 22:31 , Sean Harlow wrote:
> On Sep 6, 2012, at 23:44, valdis.kletni...@vt.edu wrote:
>
>> However, Joe Sixpack doesn't really have that option. And
>> unless you figure out a scalable and universal way for Joe Sixpack's Xbox or
>> PS3 or
>> whatever to request an SRV entry
Andrew Sullivan wrote:
>> the DNS and won't discover anything about the DNS that can't be had
>> via getaddrinfo() until long after its too late redefine the protocol
>> in terms of seeking SRV records.
>
> Oh, sure, I get that. One of the problems I've had with the "end to
> end NAT" argument i
> If a relying party's use of PKI infrastructure legally equated to
> acceptance of the relying party agreement (RPA), then having an
> explicit record of acceptance of the RPA would not be necessary.
>
> Alas, it does not appear possible to equate use of PKI certificates
> with agreement to
Oliver wrote:
>> All that necessary is local changes on end systems of those who
>> want the end to end transparency.
>>
>> There is no changes on the Internet.
>
> You're basically redefining the term "end-to-end transparency" to suit your
> own
Already in RFC3102, which restrict port number r
In message <108454.1346989...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
writes:
> --==_Exmh_1346989445_1993P
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said:
> > In message <85250.1346959...@turing-police.cc.vt.edu>,
> > valdis.klet
On Sep 6, 2012, at 23:44, valdis.kletni...@vt.edu wrote:
> However, Joe Sixpack doesn't really have that option. And
> unless you figure out a scalable and universal way for Joe Sixpack's Xbox or
> PS3 or
> whatever to request an SRV entry saying that the PS3 wants to do service
> "foobar" on po
On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said:
> In message <85250.1346959...@turing-police.cc.vt.edu>,
> valdis.kletni...@vt.edu writes:
> > My PS3 may want to talk to the world, but I have no control over Comcast's
> > DNS.
>
> What point are you trying to make? Comcast's servers suppo
On Thu, Sep 06, 2012 at 02:33:35PM -0400, chris wrote:
> Also would be an added plus if they supported MLPPP as the client mentioned
> they were concerned with the lower speeds of DSL, so we would love to do
> two circuits with MLPPP if possible
I can second the recommendation of Teksavvy (http://
Hello,
We have been working on refreshing the data and algorithms behind
CAIDA's as-rank project. We have published AS-relationships and
AS-rankings computed for June 2012. We are currently seeking further
validation of our rankings and relationship inferences.
http://as-rank.caida.org/
T
In message <85250.1346959...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
writes:
> --==_Exmh_1346959671_1993P
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said:
>
> > Despite my scepticism of the overall project, I find the above cla
It would be really nice if people making statements about the end to end
principle would talk about the end to end principle.
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
The abstract of the paper states the principle:
This paper presents a design principle that helps g
On Thu, Sep 6, 2012 at 2:12 PM, Will Orton wrote:
> . I suppose they were all built
> directly on the fiber (maybe with WDM but no layer1.5-2 muxing) and the
> provider was always the one who handled protection switching?
or protection at the optical layer isn't as predictable for all
aspects as
On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said:
> Despite my scepticism of the overall project, I find the above claim a
> little hard to accept. RFC 2052, which defined SRV in an
> experiment, came out in 1996. SRV was moved to the standards track in
> 2000. I've never heard an argum
I recommend TekSavvy (www.teksavvy.com) as a DSL reseller pretty much
anywhere in Ontario (and any other provinces they can get service in).
Not sure why they're not on that CLEC list, but they're a pretty big
(and awesome) provider up here. For bonus points, if you have to call
their support
Hello,
I have a client in the ottawa ontario canada area who is looking at DSL for
a secondary connection. I am pretty unfamiliar with the state of telecom
industry in Canada, I googled around and found this rather lengthy list of
CLEC's.
http://support.crtc.gc.ca/tlcmlsts/default.aspx?indx=33&la
On Sep 6, 2012, at 08:14 , Andrew Sullivan wrote:
> On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote:
>>
>> Never mind the fact that all the hosts trying to reach you have no
>> way to know what port to use.
>
> Despite my scepticism of the overall project, I find the above claim a
On Thu, Sep 06, 2012 at 06:00:37PM +0100, Nick Hilliard wrote:
> Not sure if I see the problem here. Show them the bill for an OC3 service,
> and then show them the bill for the equivalent ethernet service. This
> usually works for me. If they want to pay for OC3 when there's no
> compelling rea
On Thu, Sep 6, 2012 at 1:00 PM, Nick Hilliard wrote:
> On 06/09/2012 17:38, Will Orton wrote:
>> The customer has a location in the relative middle of nowhere that they are
>> trying to build a protected OC3 to.
>
> Not sure if I see the problem here. Show them the bill for an OC3 service,
> and
On Thu, Sep 06, 2012 at 01:49:06PM -0400, William Herrin wrote:
> the DNS and won't discover anything about the DNS that can't be had
> via getaddrinfo() until long after its too late redefine the protocol
> in terms of seeking SRV records.
Oh, sure, I get that. One of the problems I've had with
On Thu, Sep 6, 2012 at 11:14 AM, Andrew Sullivan wrote:
> RFC 2052, which defined SRV in an
> experiment, came out in 1996. SRV was moved to the standards track in
> 2000. I've never heard an argument why it won't work, and we know
> that SRV records are sometimes in use. Why couldn't that mech
On 06/09/2012 17:38, Will Orton wrote:
> The customer has a location in the relative middle of nowhere that they are
> trying to build a protected OC3 to.
Not sure if I see the problem here. Show them the bill for an OC3 service,
and then show them the bill for the equivalent ethernet service.
On the surface this makes me want to cry. I could be missing something as
well.
On Thu, Sep 6, 2012 at 12:38 PM, Will Orton wrote:
> We've run into an issue with a customer that has been confounding us for a
> few
> months as we try to design what they need.
>
> The customer has a location in t
We've run into an issue with a customer that has been confounding us for a few
months as we try to design what they need.
The customer has a location in the relative middle of nowhere that they are
trying to build a protected OC3 to. Ultimately, their traffic on it will be
packet data (IP/ether
On Thu, Sep 6, 2012 at 7:55 AM, wrote:
> A while back we had a customer colocated vpn router (2911) come in and we put
> it
> on our main vlan for initial set up and testing. Once that was done, I
> created a
> separate VLAN for them and a dot1q subinterface on an older, somewhat
> overloaded
On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote:
>
> Never mind the fact that all the hosts trying to reach you have no
> way to know what port to use.
Despite my scepticism of the overall project, I find the above claim a
little hard to accept. RFC 2052, which defined SRV in an
expe
A while back we had a customer colocated vpn router (2911) come in and we put it
on our main vlan for initial set up and testing. Once that was done, I created
a
separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded
2811. I set up the IPSec Tunnel, a /30 for each end t
On Thu, Sep 6, 2012 at 5:37 AM, John Curran wrote:
> If a relying party's use of PKI infrastructure legally equated to
> acceptance of the relying party agreement (RPA), then having an
> explicit record of acceptance of the RPA would not be necessary.
>
> Alas, it does not appear possible to equat
On Thursday 06 September 2012 14:01:50 Masataka Ohta wrote:
> All that necessary is local changes on end systems of those who
> want the end to end transparency.
>
> There is no changes on the Internet.
You're basically redefining the term "end-to-end transparency" to suit your own
agenda. Globa
On Sep 5, 2012, at 8:24 PM, Christopher Morrow wrote:
>
> " In order to access the
> production RPKI TAL, you will first have to agree to ARIN's Relying
> Party Agreement before the TAL will be emailed to you. To request the
> TAL after the production release, follow this link:
> http://www.arin.
> I'd wager what ARIN is going to do in said "Relying Party Agreement"
> is tell RPs (i.e., *relying* parties) that they ought not rely to much
> on the data for routing, and if they do and something gets hosed,
> ARIN's not at fault -- but I'll wait to read the actual agreement
> before speculatin
>My idealistic preference would be the ISP allows outbound port 25,
>but are highly responsive to abuse complaints;
My idealistic preference is that ISPs not let their botted customers
fill everyone's inbox with garbage.
Why do you think that blocking port 25 precludes logging what they
block, a
37 matches
Mail list logo
