Re: Routing at the Edges of the Internet
On 8/26/11 08:04 , Worley, Dale R (Dale) wrote: >> From: Adam Novak [interf...@gmail.com] >> >> "Say I wanted to send data to my friend in the flat next to mine. It is >> idiotic that nowadays, I would use the bottleneck subscriber line to >> my upstream ISP and my crippled upload speed and push it all the way >> across their infrastructure to my neighbors ISP and back to the Wifi >> router in reach of mine." there are other ways for devices with proximity to discover each other and establish a relationship than via existing networks. > This is a valid point, but it's also rather rare that one wants to > send large amounts of data directly to a friend in a neighboring flat > but one has not manually adjusting the local routing to take that into > account. > >> If each home or mobile device was essentially [its] own autonomous >> system, what would this do to routing table size? To ASN space >> utilization? > > There must be at least a few hundred million mobile phones with data > capability, and a similar number of homes and small businesses with > WiFi systems. So we can estimate that a large fraction of a billion > entries would be added to the routing tables. How would that work? putting device mobility into the DFZ is just dumb. it was a fairly bad idea when boeing did it and at any kind of scale it would be still more obvious. > Dale > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/28/11 11:31 , Joel jaeggli wrote: > On 8/26/11 14:00 , Doug Barton wrote: >> Joel, > > "it doesn't" means that the mailing list archives do not require the use > of https, if the entry point urls point to the https server that bad in > this case... To be still more specific the mailman archives do not. the ibin archive does. > If one has forgotten to renew a certificate before it expires, it takes > time to get a new one issued. as an operational pratice is is necessary > to track the issue and expiration dates of such resources. > >> I don't know what "It doesn't" is supposed to mean, but visiting >> https://www.ietf.org/* today with firefox it is still reporting that the >> certificate expired yesterday. >> >> Given the volume of discussion about the topic starting yesterday when >> the problem started one could easily make a case for "it's still broken" >> being a significant "issue." >> >> cc'ing the address listed as "Report Website Errors" on the home page. >> >> >> Doug >> >> >> On 08/26/2011 07:44, Joel jaeggli wrote: >>> It doesn't... >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html >>> >>> On 8/26/11 00:18 , t.petch wrote: Why does the IETF website consider it necessary to use TLS to access the mailing list archives, when they all appeared without it, or any other security, in the first place? Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >>> >>> ___ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> >> >> > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Routing at the Edges of the Internet
On 8/26/11 14:08 , Doug Barton wrote: > On 08/26/2011 13:57, Adam Novak wrote: >> On Fri, Aug 26, 2011 at 3:49 PM, Doug Barton wrote: >>> >>> I have a related-but-different example of how end nodes being able to >>> know/discover direct paths to one another could be useful. Imagine a >>> busy server network with some web servers over here, some sql servers >>> over there, etc. All of these systems are on the same network, same >>> switch fabric, and have the same gateway address. In an ideal world I >>> would like them to be able to know that they can speak directly to one >>> another without having to go through the gateway (and without my having >>> to manually inject static routes on the hosts, which of course is both >>> painful and un-scale'y. >> >> Shouldn't that be covered by the subnet mask? > > Mostly, yes of course, but I'm dramatically simplifying my example for > dramatic effect. :) > >> As long as they know >> they're on the same subnet (and ARP broadcasts will reach everyone) >> they should just ARP for each other and not involve the router at all. >> >> If they are on different IP subnets, but the same Ethernet, > > Yes, this is more often the case that I'm dealing with. (Working on > fixing a problem I inherited for a new client, so per your comment below > "don't number that way" may be the right answer.) overlayed subnets are pretty straight-forward with ipv6 RA. > Doug > > >> then we >> can either come up with a new way to do routing, or tell people not to >> number things that way. Perhaps a subnet mask or CIDR prefix is not >> expressive enough? > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/26/11 14:00 , Doug Barton wrote: > Joel, "it doesn't" means that the mailing list archives do not require the use of https, if the entry point urls point to the https server that bad in this case... If one has forgotten to renew a certificate before it expires, it takes time to get a new one issued. as an operational pratice is is necessary to track the issue and expiration dates of such resources. > I don't know what "It doesn't" is supposed to mean, but visiting > https://www.ietf.org/* today with firefox it is still reporting that the > certificate expired yesterday. > > Given the volume of discussion about the topic starting yesterday when > the problem started one could easily make a case for "it's still broken" > being a significant "issue." > > cc'ing the address listed as "Report Website Errors" on the home page. > > > Doug > > > On 08/26/2011 07:44, Joel jaeggli wrote: >> It doesn't... >> >> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html >> >> On 8/26/11 00:18 , t.petch wrote: >>> Why does the IETF website consider it necessary to use TLS to access the >>> mailing >>> list archives, when they all appeared without it, or any other security, in >>> the >>> first place? >>> >>> Besides all the usual hassle of TLS, today the certificate is reported by >>> IE as >>> expired, which sort of sums it up. >>> >>> Tom Petch >>> >>> ___ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 8/27/11 11:22 , Cullen Jennings wrote: > > Thanks Marshall, I had suspect the process was something like that. I > had not realized how much the pre picking the dates reduced the > options. It does, it also decreased your leverage in a negotiation because you do not have the luxury of shifting the event timewise and hotels know that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
> On 8/27/2011 4:12 PM, t.petch wrote: > > Glen > > > > Me again. > > > > Just after I posted my last message, I received a post on the ietf-ssh list, > > hosted by netbsd.org, and looking through the 'Received: from' headers, as > > one > > does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, > > used to > > submit the message to the server, so even spammers have caught on that TLS > > should be used everywhere. End to end? As a side note, the reason spammers use TLS to submit mail is obvious: It's required by many submission servers so they really don't have a choice. (The reason it's required is to protect the authentication exchange, not because there's any real expectation that it provides useful privacy protection for the submitted email itself.) > Apparently, from the POV of the spammer & his SMTP server. Email is a > store & forward system. In any case, my original question was not about > the definition of end-to-end, it was about Ned usage of the term "hop". I used the term "hop" in a very generic sense to refer to moving the data around. > Upon further analysis, however, it seems clear that he was referring to > the email archives as if they are something other than simple files (as > betrayed by his statement that "Don't pretend a transfer protection > mechanism covering exactly one hop provides real object security, > because it doesn't."); thus, the retrieval of the archived data would be > the last "hop" in the email system. And that's incorrect. For one thing, I often retrieve material from web sites and save it rather than looking at it right there on the screen. So the transfer of the material from the web server is in no way, shape, or form the final hop the information takes before it is consumed. As as Keith points out, I and many others am often forced to do such access through corporate-mandated proxies of various sorts - another hop. > There seem to be two problems with > this statement: one is taking the file transfer mechanism as if it was > part of the email system itself, Nobody is making any such claim. > which it obviously is not (downloading > an archived message is no different than downloading an RFC from a Web > site); the other being that someone, somewhere was pretending that TLS > does something that it was never designed to do (a straw man of, AFAICT, > Ned's invention -- I don't recall anybody making such a claim on this > thread, I was responding to the justification given for the use of https in this context. The exact words used were: > > The mail archives (and the minutes of the physical meetings) > > are the official record of the Working Groups, IETF, etc. > > Those archives should be available with a reasonably high > > level of integrity and authenticity. Nor was I the only, or even the first, to suggest that object security is needed for this sort of protection. > nor for that matter saying they _wanted_ "real object security" > applied to the archives, merely that it's not really a bad idea for a > person retrieving them to have some assurance that they came from the > IETF server and that they weren't modified in transit). And once again, nobody is saying that TLS doesn't give some very limited assurance along these lines - the notion that there are claims to the contrary is your own strawman. What we are saying is that there are also significant costs, those costs appear to be greater than the benefits in this case, and if there is real concern about archive integrity there are better ways to secure them. Anyway, this discussion is now well past it's sell-by date, so this will be my final response on the topic. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Sat, Aug 27, 2011 at 10:05 PM, Glen Zorn wrote: > On 8/27/2011 10:30 PM, Eric Rescorla wrote: > >> On Sat, Aug 27, 2011 at 7:57 AM, Dave CROCKER wrote: >>> >>> >>> On 8/27/2011 7:48 AM, Cullen Jennings wrote: What I have heard is that the community would prefer going to locations that were easy to travel to over "interesting". >>> >>> >>> How do you reconcile this assertion against the clearly positive group >>> reactions to Prague and Quebec? >>> >>> FYI, in relative terms, even Minneapolis is second-tier. >> >> I have no idea what the "community" wants--and I'm not convinced that >> the data we >> have available lets us assess that, for the usual reasons about the >> difficulty of doing >> accurate surveying--but speaking solely for myself, I'm at IETF to >> work, so my priorities >> center around the things that make it easy to get work done. This >> basically boils down >> to cost and convenience. > > Good to hear. Getting rid of cookies can save a _lot_ of money & since > you're "at IETF to work" I'm sure you wouldn't mind if the conditions > more closely approximated those of the typical office; no office I've > ever worked in has provided free cookies & beverages twice a day... I'm not sure that getting rid of food at breaks would save a lot of money. Do you know what the actual numbers are as a percentage of the overall cost? With that said, it's actually quite common for workplaces to offer free snacks and/or beverages, not only twice a day but 24/7. Maybe you should consider a different class of employers. >> Within these general parameters, my priorities are something like: >> 1. Cost: >> - Travel >> - Hotel >> >> Rationale: airfare tends to not be that flexible, but it's generally >> possible to find a cheaper >> hotel if you try (as several people have observed). However, if the >> conference hotel >> is $300/night, then this is probably going to trickle down some into >> cheaper hotels so >> it's not like hotel doesn't matter. >> >> >> 2. Convenience: >> - Length of trip. >> - Local services >> >> Rationale: travel time is time I'm not working (yeah, we all try, but >> I'm not that effective >> and I suspect most people are not.) Lack of local services means less >> time meeting >> and more time rushing around trying to find lunch before the next >> meeting, walking to >> and from the hotel, etc. > > So, do you live in your office? Next door to the building? Across the > street from the office park? If not, why are you applying criteria to > the IETF "workplace" that you don't to everyday employment? Funny you should mention that, since I work from home most of the time in part to minimize commute time. > For that > matter, for one whose (not primary, but _only_) purpose is work, Strawman alert > finding > lunch is a non-problem: you simply eat whatever is closest, quickest, > most efficient, without any regard to taste or surroundings (e.g., the > company cafeteria, analogous in this case to the hotel restaurant(s)). Maybe you've noticed that the hotel restaurants are (a) expensive and (b) tend to fill up quickly, which often makes it hard for people to actually get in and out in the relevant time. This would of course be far worse if there were no reasonable restaurants in the area. > WRT walking to and from the hotel, I know that I, at least, am not paid > to type (if I was, my clients would be getting a really bad deal ;-). I > get paid to think, and I'm pretty sure that you are, too. I don't know > you very well, but I think it's a sure bet that you can think & walk at > the same time :-). I find that I work more effectively when I have computer and Internet available, neither of which is the situation when I'm walking to and from the conference center. Your mileage may vary. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questionnaire to survey opinion concerning a possible redefinition of UTC
On the one hand, abolishing leap seconds would help us with the problem of conversion from the UTC-based NTP timescale and the TAI-based IEEE-1588 and GPS timescales. On the other hand, it will require updating all software that computes local sunrise and sunset times (e.g., for radio propagation). However, the real problem is not related to communications or software. The real problem is that local time is based on UTC since it needs to be astronomically meaningful. If leap seconds are abolished and local time starts drifting away from "earth time" then in a few hundred years we will accumulate an hour of error, and in a few thousand years it will be dark during much of the working day. This is similar to the draft of the months of the Islamic calendar, where a particular month may appear in the winter or summer. I know that most of us don't worry about what is going to happen hundreds of years hence, but think of the Y2K-like fixes that will have to be made for leap-hours ! Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephane Bortzmeyer Sent: Thursday, August 25, 2011 13:24 To: ietf@ietf.org Subject: Questionnaire to survey opinion concerning a possible redefinition of UTC Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905, etc), this questionnaire may be of interest for some persons [the Web page mentions two articles, if you are in a hurry, the first one is the PRO and the second one the CON]. One more week to comment. http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire QUESTIONNAIRE TO SURVEY OPINION CONCERNING A POSSIBLE REDEFINITION OF UTC Universal Time, the conventional measure of Earth rotation is the traditional basis for civil timekeeping. Clocks worldwide are synchronized via Coordinated Universal Time (UTC), an atomic time scale recommended by the Radiocommunications Sector of the International Telecommunications Union (ITU-R) and calculated by the Bureau International des Poids et Mesures (BIPM) on the basis of atomic clock data from around the world. UTC is computed from TAI by the introduction of leap seconds such that UTC is maintained within 1 second of UT1. Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months. Since 1 January 2009, 0:00 UTC, UTC-TAI= -34s. After years of discussions within the scientific community, a proposal to fundamentally redefine UTC will come to a conclusive vote in January 2012 at the ITU-R in Geneva. If this proposal is approved, it would be effective five years later. It would halt the intercalary adjustments known as leap seconds that maintain UTC as a form of Universal Time. Then, UTC would not keep pace with Earth rotation and the value of DUT1 would become unconstrained.Therefore UTC would no longer be directly useful for various technical applications which rely on it being less than 1 second from UT1. Such applications would require a separate access to UT1, such as through the publication of DUT1 by other means. The objective of the survey is to find out the strength of opinion for maintaining or changing the present system. Your response is appreciated before 31 August 2011 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
