Re: 6tsch BoF
Dave Crocker d...@dcrocker.net wrote: On 8/1/2013 10:50 AM, Ralph Droms wrote: In particular, the effect of humming versus show of hands was pretty obvious. The fact that the results were so profoundly different should get our attention, enough to get us to consider specifying how to measure consensus. From the data you cited, it appears that raising hands carries some sort of social onus, at least for some people some times, that raising hands does not. Unless I missed something, it was not clear how much of the effect was due to hands vs. hum, and how much of it was due to people being asked a second time after they'd already seen (err, heard) the sense of the room when it was asked just previously. -- Cos
Re: The case of dotless domains
What this brings to mind is that we used to have implicit DNS domain search in the early days of DNS. When edu.com accidentally hijacked a huge chunk of the Internet, most of the net very quickly got rid of implicit search, and we got the explicit DNS search feature that many people are discussing now. Yes. Can you (or Ofer) define how you're using the terms explicit and implicit in terms of DNS search, and what their relevance is to the topic of dotless domains? And no, I'm not being snarky, I think part of the problem here is a fundamental misunderstanding of how the vast majority of hosts are configured currently. You're not being snarky, but that indicates that you seem to have missed my point, which is not about the technical details of how domain search got changed after the edu.com disaster. My point is not to make a direct parallel between how domain search changed, and dotless domains, and you seem to be looking at it in that light. What this brings to mind is that we had a DNS system that was vulnerable to the addition of something to the DNS that people had expected nobody would make the mistake of doing, but it happened and caused damage, and the net reacted by altering how DNS software works in order to protect against that damage. At the time, the obvious defensive change was don't do implicit domain search. If dotless domains cause damage as many people here predict, what I'm saying is that I think we'll react similarly, and that I guess the defensive change people will widely deploy is to reject A//MX records at the top level. You really do not need to drill into the specifics of the change from implicit to explicit domain search in reaction to edu.com, in this context. So it sounds to me like you have something quite different in mind. I don't know what you think I was trying to say - it's not anything I said explicitly, so perhaps you think I was trying to subtly say something between the lines. To be clear: I wasn't. -- Cos
Re: IAB Statement on Dotless Domains
Reading some of this discussion leaves me puzzled because I can't tell which things that some people are saying are intended to be about dotless use of domains, or are intended to be about the expansion of top level domains in general. The IAB's statement does not seem to be about whether or not new TLDs should be issued, or what good or bad effects that will have; the IAB statement rather seems to assume as a given that new TLDs will come. Yet a significant portion of the debate on this thread seems to be about that. In theory, any of the classic TLDs could've been used in a dotless fashion, but they haven't been. What the IAB statement is about is to urge that none of the new TLDs be used dotlessly either. That's a separate matter from whether they should come into being in the first place. What this brings to mind is that we used to have implicit DNS domain search in the early days of DNS. When edu.com accidentally hijacked a huge chunk of the Internet, most of the net very quickly got rid of implicit search, and we got the explicit DNS search feature that many people are discussing now. If some new TLD gets used in a dotless fashion in a way that truly does cause major trouble, I expect we'll see sites all over the net quickly deploying DNS resolvers that discard A, , or MX records at the top level, to protect their users. -- Cos
Re: Hugh Daniel has passed away
Paul Wouters p...@cypherpunks.ca wrote: Hugh Daniel passed away on June 3rd after what appears to have been a heart attack. Whoah. I had completely lost track of him in the past decade, but he was one of the most memorable people I ever met through the IETF. We met first at IETF 37 I think, in San Jose, and kept reconnecting at meetings for the next few years, and sharing music and book recommendations in between. At IETF 40 he joined me and a few friends on a trip out of town to a concert. I wish I remembered more of the stories he told - I remember re-telling them to other people often, back in the 1990s, but only remember a few now. If I recall correctly, in addition to his leadership in promoting encryption on the Internet, he also had a mission to make Internet access available all over the western US, and started a number of local and regional ISPs in the 90s in pursuit of this goal. -- Cos
Re: IETF 95 Date Change Proposal - Round 2
lizhong@zte.com.cn wrote: 1-3 April 2016 will be holiday in China. If the time is 3-8 April, then many Chinese attendees have to give up the holiday. Would you propose another time? Thank you. I think there's probably always either a major holiday somewhere or another conference that the IETF wants to avoid conflicting with, so avoiding significant holidays in all parts of the world is not a practical pursuit. The goal of this date change proposal seems to be to avoid holding an IETF when there is a major travel disruption, or days when travel and other public services are shut down, in the place where the IETF meeting is to be held. IETF 95 lists target location: Europe, and holding a meeting in Europe overlapping with Easter would probably cause challenges. However, I do wonder how major a holiday this is? While there are parts of the world where it would not be challenging to hold an IETF meeting over Christmas, international organizations with major US+Europe participation seem to avoid doing so nonetheless. Is this one a special case of similar magnitude? Searching the web suggests that it may be: https://en.wikipedia.org/wiki/Qingming_Festival Since I'm not planning to attend in person, I'll keep my comments general. -- Cos
Re: Proposed IETF 95 Date Change
Glen Zorn glenz...@gmail.com wrote: On Sat, 2012-07-21 at 13:25 -0700, Martin Thomson wrote: On 21 July 2012 06:55, Yoav Nir y...@checkpoint.com wrote: This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped. But moving it to the southern hemisphere would have. How? By cutting the sunrise-to-sunset fasting period of the day to a much shorter period. -- Cos
Re: RFC 2119 terms, ALL CAPS vs lower case
As a reader of RFCs, I've come to expect that 2119 words are always capitalized, and that when the same words appear in lowercase or mixed case they're not being used in the 2119 sense. This seems to be a de facto standard, even though 2119 doesn't require it. I'm in favor of continuing with this standard since I think most readers of RFCs have grown to expect it, but there doesn't seem to be a need to make any change. Two things I like: - Randy's new suggested boilerplate - Avoiding using 2119-like words in lowercase when other wording would work equally well, at the author's discretion. That seems like a reasonable practice, but trying to define and enforce it would be far too much trouble and have silly unintended consequences. So perhaps if Randy's new suggested boilerplate could be added as an erratum to 2119, clearly labeled an optional suggestion, I think that might be useful. But don't change the rules. 2119 works well as is IMO. -- Cos
Re: IETF posting delays
Fred Baker f...@cisco.com wrote: Question, did the IETF list setup disable the non-member email notifications? Spam reduction. We apply the rule to all of our mailing lists, and it is very helpful. I don't think that's what Hector asked. The question isn't do we block email from non-members; the question seems to be we used to reply to the sender with a notification that their message was blocked due to not being a list member, with options to wait or cancel; did we disable those notifications? At least that's how I read it. -- Cos
Re: 'Geek' image scares women away from tech industry ? The Register
This PBS interview with Harvey Mudd president Maria Klawe, on the subject of why fewer women go into tech engineering fields, is worth watching: http://www.pbs.org/newshour/extra/video/blog/2012/04/college_president_discusses_wo.html -- Cos
Re: ITC copped out on UTC again
If the main problem with leap seconds is their future unpredictability, isn't there a compromise option between the status quo and no more leap seconds? Couldn't they come up with a fixed schedule for leap seconds for many centuries at a time, based on current predictions of approximately how many will be needed each century? That should be good enough to prevent real human-noticeable drift between UTC and perceived day/night time. If a correction is needed because current predictions turn out to be wrong, it seems that could be done very rarely, with centuries of lead time in changes to the schedule. Was anything like this considered at the international level? [ I know this is not something the IETF can decide, of course ] -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
I've never been able to get first level tech support at my ISP to understand latency or packet loss. They only understand can you load a web page? This does not mean their ISP doesn't provide packet loss and latency, standard with their service :) More to the point, when I've been at hotels or conference centers or similar places and found that I could connect to their wireless network but not get an IP, it's been rare for their tech support to recognize the term DHCP, know what an auto-configured IP looks like, or even understand the distinction between getting on the local wireless and having routability to the Internet. Yet their systems clearly provide and depend on these things, and always have. Their lack of clue says nothing about the level of support for things like basic IP routing, or DHCP, in hotel and conference center networks. I wouldn't take what first level support has heard of to be a systematic indication of anything other than that company's hiring and training practices for first level support. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote: I'm a fan of reducing down to 2 levels, too. But it has nothing to do with how overblown the effort to get to Proposed is. (Well, I feel like we already have a 2-level system. What's the practical difference between Proposed and full Standard? It may take a lot of effort to make that jump, but what difference does it make outside of the fact that the document now has a new label? Who notices or cares about the distinction? Does it affect anything real? These aren't rhetorical questions. I feel like there's no practical effect, but I may be wrong, and I'm asking. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Phillip Hallam-Baker hal...@gmail.com wrote: Since the one legacy protocol that has a dependency on IP address constancy is FTP, it would seem to me to be much easier to upgrade FTP to remove the dependency than to try to control the network. There are other protocols hiding out there. MATIP, RFC2351 (not from the IETF, obviously), allows either endpoint to send a session-open setting some paramaters for the session, and to confirm the session-open from the other side. So if both sides send session-open, they're both supposed to ignore the session opened by the endpoint with the lower-numbered IP. In practice, what this seems to mean is that sometimes when you set up new links, MATIP doesn't work, you get on the phone with the admins at the other side, and you agree which one of you will send the session open. Then you configure one endpoint never to send it. The RFC was published in 1998, though I don't know when they actually came up with the protocol. Its use is, I think, still increasing, as more airline industry links are set up over TCP/IP networks. I wouldn't have known about MATIP if I hadn't gotten a job related to airline industry networking, and I'm sure there are other naive protocols out there, designed by people or groups who were not that familiar with the way of the Internet and do protocols their own ways. [MATIP has a host of other problems that I won't mention :) ] -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Marshall Eubanks t...@americafree.tv wrote: On Sep 2, 2010, at 8:45 PM, Phillip Hallam-Baker wrote: So in my view the problem here is that when I pay for an X Mb/sec connection at the moment I have no real way of knowing whether that is really X Mb/sec all the time or X/n Mb/sec when I am using a service that competes with my carrier. This sounds like there is potential for crowd sourcing here. In my case, I would be willing to pay a bit more to get rid of the 250G bandwidth cap, but not only won't my provider offer that, there's no other provider available which will offer service to my house that is comparable at all. I have nowhere else to go, and I think that is the typical situation for most households in the US. Even if the industry manages to get it together in terms of making clear what level of service they offer, I don't know that there's any way out of this conundrun other than legislation. P.S. My neighborhood is about as far from being a tech backwater as it is possible to be in the world. Yet I still have only one viable option for high speed Internet. It's a business law problem, not a technology problem. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Brian E Carpenter brian.e.carpen...@gmail.com wrote: The major problem with the story is that it confounds IANA runout (objectively predicted for 2011) with when ISPs run out of IPv4 space (which is not so easy to predict, but 2015 is a popular estimate). The rest is pretty good for a story in the non-technical media, IMHO. More generally - and this is not a problem I have with the CNN article, just in general with IPv4 depletion conversations - I've been hearing about imminent IPv4 address depletion for 15 years or maybe 20 by now. - We were going to run out of Class C's, but then we converted to CIDR so were no longer bound by the rigid old classes and got to allocate addresses much more efficiently, buying many years. - We were going to run out of blocks to allocate even with CIDR, but lots of institutions adopted NAT so that places that would've needed large blocks started being able to make do with /25s or similar sizes for their few public IPs. - We were going to run low on public IPs despite NAT due to the rapid growth of web servers, but we got name based virtual hosting which let lots of web servers share the same IP. ... what's next? Carrier-based NAT? Virtual-hosting encrypted http? Actually using IPv6 en masse? Something else? It seems like the limits we're running up against aren't really a matter of growing demand vs. dwinding supply; for more than that, the limits are based on our cleverness in coming up with new ideas to conserve or use our IPv4 address supply more efficiently. We've had several large shifts of this sort and each time we buy years of time. Each such shift also has a cost, though it varies - name based virtual web hosting has relatively little cost and is a big win; CIDR was a hard transition but once done it's all win and no lose; Heavy use of NAT causes lots of problems and will continue to. But when it comes to we're 1-2 years away and need to buy more time! we always seem to end up with another one of these clever new ideas instead. Will there come a time when the least-cost clever new idea is an actual transition to IPv6? Probably, but I don't know when and I don't know that it makes sense to assume that is the next one, or to estimate which year it'll be. You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/. I can find a link to his talk on that site, but each time I click on that link I get a quickly-broken TCP connection. Overloaded, perhaps? -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
YAO Jiankang ya...@cnnic.cn wrote: HUANG, JERRY (ATTLABS) zh1...@att.com wrote: What I am not so sure about is the sweeping statement that Americans would likely have difficulties with the '-mm-dd' format. I walked around the office and polled seven of my co-workers who happen to be around (all engineers by trade, five 'natives'), all seven (eight including me) _know_ what it means. Good test. but you tested it only in your office which, I think , is located in USA. So the conclusion derived from your office test may apply only to most offices in USA. Have you tested it in U.K., France, ASIA countries such as Japan, China of different culture and background? He was specifically reacting to the statement that *Americans* would be more likely to have difficulties with this format. I found that claim strange myself, since I live in the US and I've never met anyone who has difficulties with that format. [ I believe that China uses -MM-DD anyway, and Wikipedia agrees: http://en.wikipedia.org/wiki/Date_and_time_notation_by_country#Greater_China ] HUANG, JERRY (ATTLABS) zh1...@att.com wrote: Perhaps this really is a non-issue after all? That's about what I said in my other email on this thread: Other than the email that started this thread, which mentioned a single individual who found 2010-01-02 ambiguous, I have *NEVER* heard of anyone finding that format ambiguous. As I said in that email, I think we'd need some evidence that there's an actual problem before it'd be worth discussion a solution. As far as I can tell, there's no such evidence, and no problem here. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Your favorite network faults
On Apr 10, 2009, at 12:48 PM, Henning Schulzrinne wrote: As part of a research project, we are working on automated diagnostics of network-related faults in residential, SOHO, conference/special event, hotel and similar networks. If you have observed errors that were hard for a lay person to diagnose, whether due to end system problems, NATs, LAN or Internet issues, please send me a brief description. (Also, contacts in tech support for I'm not sure if this is the kind of fault you're looking for. In residential networks, often the DSL or Cable modem has a misfeature that caches the MAC address of the first device it sees, and won't talk to any others. Often it will only forget the cached MAC address if it's been powered off for a significant time (15 minutes, or an hour). When the ISP's tech sets up a new home, sometimes they come with Windows based software. If the customer doesn't use Windows, the tech will connect their own laptop to run the setup software. Or, the ISP person wants to connect directly rather than through the wireless router. Then the customer tries to use it and it doesn't work, but since the ISP's tech had no problems and reported the Internet connection working, they blame the customer's computer or wireless router. In my experience, I've found that ISP setup people rarely know about this, and often don't understand what caching the MAC address means even if you try to explain it to them, to ask if their equipment does it. I think a lot of customers who experience this never figure it out before the problem mysteriously disappears eventually, when they happen to have the thing powered off for a while because they thought it wasn't working. I've also encountered this at other people's homes, where they don't have wireless, and one person's computer gets Internet but the other's doesn't most of the times they try - I've solved this problem for other people several times, merely by explaining that they have to power off the dsl/cable box for a certain number of minutes when switching computers (they can figure out how long by experimenting), or by connecting one laptop and sharing its connection to the other via wireless. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Does being an RFC mean anything?
There are, it appears, many types of IETF RFCs, some which are intended to be called Internet standards and others which bear other embedded labels and descriptions in their boilerplate text that are merely experimental or informational or perhaps simply proposed standard. One contributor here described the RFC series as a repository of technical information [that] will be around when I am no longer around. I was also under the impression that a lot of RFCs are *not* IETF RFCs, since the RFC editor will publish certain types of RFCs without them having gone through an IETF process. RFC as a document series is not the same thing as the IETF's publications; the IETF publishes its final products as RFCs, and so do some others, including individuals. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
Michael Dillon wavetos...@googlemail.com wrote: With the text above, don't be surprised when people learn that they can become bona fide IETF members by subscribing to the IETF discussion list and the new subscription volume swells exponentially. Given the contents of many of the letters received on the patent issue, I would expect the majority of those people to be willing, and capable of, subscribing to the IETF list in order to submit a comment. Also, don't be surprised when the next time this issue arises, the FSF encourages people to join the IETF WG discussing the next patent-encumbered draft. Those would be positive steps. I don't think we object to hearing what people have to say about any topic simply because they happen to be FSF members. What we object to is a bunch of me too comments that present no new points, and are clearly coming from people who a) aren't also receiving them, and b) aren't participating in discussion. I do like that the IETF list allows non-subscribers to post, even though it makes these annoyances possible. However, if we do something that causes the FSF to encourage people to subscribe if they wish to comment, rather than encouraging people to do the sort of drive-by we've seen, we'd be happier and they'd be happier. Those people who don't feel like putting much time into it wouldn't subscribe; those people who do feel like putting some of their time into it would be more engaged; the number of substantively identical messages would be much more self-limiting if a significant proportion of the would-be activists were subscribed. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ideological opposition to patents
Powers Chuck-RXCP20 chuck.pow...@motorola.com wrote: If the technology in the document to be standardized is unencumbered, then the fact that _some_ uses of that technology may run into encumbered territory is irrelevant, except to those who hate patents in general. I think software patents are a bad idea, and would prefer that there be none of them. I think software is like music, and patenting software is like patenting chords or melodies. Patents are the wrong legal tool for software, and they undermine the purpose of IPR (which is to promote progress of the useful arts). Nevertheless, I see no reason to oppose standardizing a protocol that is unencumbered by patents, simply because some uses of that protocol (even if they may be common) are encumbered. I think such opposition requires more than mere opposition to software patents, or to patents in general. At the very least, it also requires that one not think through the logical consequences of one's strategy. In practice, however, I believe most of the people who sent us drive-by mailings were simply misinformed or mistaken about the facts. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: how to contact the IETF
Alex Loret de Mola edgarver...@gmail.com wrote: Dear Carsten: (And others who feel upset at the recent development) As someone who's been a (mostly silent, but frequently reading) member of this mailing list, I can understand your concern. However, can you propose a better way for them to contact members of the IETF? This stems from a misunderstanding of IETF process. What they're doing is indeed contacting the IETF to express an opinion, as if we're a political lobby. IETF decisions don't get made by counting votes, as you know. There's no value in having lots and lots of people write to say essentially the same thing - it just annoys list members, but doesn't actually contribute to the discussion. If people want to *participate in discussion* they can *subscribe*. If people want to *raise new points to be discussed* then a well thought out message raising those new points would be called for. It does not need to be repeated 50 times. Two or three is enough :) -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 only Plenary Makes the News
Subject: IPv6 only Plenary Makes the News Isn't that just a press release from ISOC, being distributed by wire services online? -- Cos ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OT] Internet / DNS Timeline (The History of the Internet DNS)
On Thu, Jul 19, 2007 at 10:10:28AM -0400, Joe Baptista [EMAIL PROTECTED] wrote: Now this is an interesting little giggle. I made it into a DNS timeline. Incredible. http://www.inaic.com/index.php?p=internet-dns-timeline ... a timeline of the DNS that documents the teeniest details, but leaves out the edu.com disaster? Huh. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
New RR problem not evidence that DNS needs to be replaced (was Re: SRV records considered dubious)
Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] No. It just means that the people spreading FUD have succeeded. [ ... ] I really don't know why we are arguing about this anymore. Adding new RR's has not been a real issue this millenia. Because during MARID we looked at the actual tests and discovered that there was a real problem. The last server edition of Windows is Windows 2003. The RFC was published 2003. It is not suprising therefore that Windows 2003 server is not compliant with RFC 3597. Microsoft's development cycles for its server products are long and features have to be proposed several years in advance. This thread started with the assertion that DNS is a failure and needs to be replaced with a new, better protocol; adding new RRs was part of the evidence. Mark Andrews said that the new RR problem is not valid evidence, because it has been solved. Phillip says no, it hasn't been. But in the original context, Phillip is supporting Mark's point. If the reason the new RR problem hasn't been solved is that the solution is so recent (3 years old) that Microsoft hasn't implemented it yet, obviously this doesn't constitute evidence that we need to solve the problem again by developing a new protocol. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] OSI is a beautiful dream, and TCP/IP is living it! -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
DNS RMX RR draft
I just saw this recently submitted draft and don't recall it being discussed in the recent spam thread, so thought I'd point it out in case people hadn't noticed it: http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-01.txt (Note: I am stating no opinion about its applicability or effectiveness) -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] http://cos.polyamory.org/ OSI is a beautiful dream, and TCP/IP is living it! -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992
Re: namedroppers, continued
[EMAIL PROTECTED] wrote: Does anybody have a reference on an authorization scheme that doesn't imply any authentication? From:-line based email filters. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] http://cos.polyamory.org/ -- WBRS (100.1 FM) -- [EMAIL PROTECTED] http://www.wbrs.org/ OSI is a beautiful dream, and TCP/IP is living it! -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992
Re: I-D archives available anywhere?
Vernon Schryver [EMAIL PROTECTED] wrote: ... And *NO*, this is *NOT* a 'we need to use XML/HTML/etc' - we haven't waited the requisite 6 months before re-starting that flame war. ;) Let's keep our flame wars straight. This is the scheduled start of the latest episode of I-D's Should Not Be Expired. Anyone for an FYI RFC, IETF mailing list flame war glossary and schedule ? -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] http://cos.polyamory.org/ -- Exodus Communications -- [EMAIL PROTECTED] http://www.exodus.net/ We all misuse the net for personal gain, one way or another. -- Larry Wall [EMAIL PROTECTED]
closing list posting won't help us much
A lot of the unwanted, off topic postings we get on the ietf list, seem to be specifically directed at us. For example, the political diatribes from kysi feryl (did I spell that right?). People who want to advertise to or spam on the ietf list specifically, will obviously not be turned away by any requirement to pre-register your From: line before posting. Closed posting is fine for small private lists that want to stay private, but this list is too large, public, and visible for it to be appropriate or useful here. -- -- Cos [EMAIL PROTECTED]-- accessline: 781-273-2380 -- (Ofer Inbar) [EMAIL PROTECTED]-- pager: 800-351-9387
Re: NAT natural example
Ed Gerck [EMAIL PROTECTED] wrote: Steve Deering wrote: At 3:41 PM -0800 2/15/01, Ed Gerck wrote: You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. They also do it without removing the original destination address and replacing it with another one -- the original envelope arrives at the house with the destination address still saying "The Tulip", i.e., it has not been translated, and thus is not analogous to NAT. I think you got the example addresses reversed. In the case I mention, "The Tulip" is the global address and (for the sake of example) suppose now that "545 Abbey St." is the local physical address known to the post office. Thus, when the mailman delivers an envelope addressed to "The Tulip" at "545 Abbey St.", that mailman is doing address translation -- and he may even have written "545 Abbey St." on the envelope as a reminder. So, when the original envelope arrives at the destination address it did so not because it had "The Tulip" written on it but because the post office was able to do address translation to the *current* location which is "545 Abbey St." That still doesn't sound like NAT. A complete address which specifies your town and house name, is global, and has a one to one mapping with your house. Your house can both initiate communication and receive communication initiated by others, at that address, and no other house uses that address. No rewriting of envelopes is done, and no disruption of the "end to end" nature of addressing is involved. The fact that your address actually has to be silently translated to another address by the post office, at the local hop only, and *invisibly* from you and your correspondents, makes this a natural example of protocol layers, not of address translation. It's as if "1234 Foo Street" is your MAC address, and "Tulip, BarBurgh, Scotland" is your IP address. The local post office, and *only* the local post office, needs to keep a mapping between street addresses and house names, for their town (aka segment or LAN). You only know your own street address and your own house name. And you never (need) use your street name in any communication, only in communication management (i.e. telling the postal system that you've moved). Layering most certainly *does* occur naturally in communication. That's why the best tutorials that try to explain protocol stacks and layers to non-technical people, usually make analogies to things like postal mail, or to bosses who communicate via secretaries who can freely change between fax or mail without changing the content of the messages exchanged by their bosses. NAT, as far as I can tell, is pretty much always a kludge, whether it's natural or not. It doesn't make people happy unless obscurity and reduced communication is what they're explicitly seeking. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- Exodus Professional Services -- http://www.exodus.net/ "OSI is a beautiful dream, and TCP/IP is living it!" -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992
Re: Not developing protocols
Thought for the day: "If farmers can be paid not to grow wheat, why can't IETF WGs be paid not to develop protocols?" We can. Just go work for a company that is willing to send you to IETF on their time money, and wants you to disrupt certain IETF protocol work. I'm sure many of us have witnessed this in action, and we've probably missed some of the more subtle and skilled efforts. It most assuredly does happen. My epiphany on this subject came during a session of the HTML 3.0 working group, circa 1994. I don't think it's an accident that that WG effort did not produce a standard, although of course I can't prove anything about anyone's intent at the time. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- Exodus Professional Services -- http://www.exodus.net/ "We all misuse the net for personal gain, one way or another." -- Larry Wall [EMAIL PROTECTED]
Re: Not developing protocols
Vernon Schryver [EMAIL PROTECTED] wrote: From: Ofer Inbar [EMAIL PROTECTED] "If farmers can be paid not to grow wheat, why can't IETF WGs be paid not to develop protocols?" We can. Just go work for a company that is willing to send you to IETF on their time money, and wants you to disrupt certain IETF protocol work. I'm sure many of us have witnessed this in action, and we've probably missed some of the more subtle and skilled efforts. It most assuredly does happen. My epiphany on this subject came during a session of the HTML 3.0 working group, circa 1994. I don't think it's an accident that that WG effort did not produce a standard, although of course I can't prove anything about anyone's intent at the time. The official dogma of every Standards Process is that the Process has failed if it does not produce a document. In real life, no document is more often a success a failure. On the other side of the coin, a committee document is more often a failure than a success. This side is trivially proven for the IETF by referring to the RFC index. I don't disagree with you, but note that I was careful not to say "produce a document", but "produce a standard". Many working groups produce documents that don't end up being widely applied, or useful, or standards. Sure. But I don't think you'd argue that the HTML 3 working group of the mid-90s was a success, or that their lack of results was a boon to interoperability. Also, the question of whether or not failure to produce a document is a good thing in particular cases, is beside the point. It doesn't change the fact that people *are* paid to prevent working groups from developing protocols (whether they produce documents or not). Saying that this may not be necessarily bad is not the same as saying it doesn't happen. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- Exodus Professional Services -- http://www.exodus.net/ "OSI is a beautiful dream, and TCP/IP is living it!" -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992
Re: Welcoming newcomers
I'm not a newcomer, but I don't go to meetings very often. I joined the IETF list in 1990 and have participated in some WGs on and off since then, but in that whole time I think I've attended only 5 IETF meetings. So, in the stats the secretariat keeps, I don't know if I show up as a repeat, especially considering that I've only registered twice under the same employer, thanks to the plethora of mergers in our industry :) When I do attend a meeting, I take the opportunity to visit other WG sessions I'm interested in. Often these are topics that I've participated in in the past, but have had to drop due to limited time, so I read drafts occasionally and I visit WG sessions when I'm there, just to keep up and maybe be able to plug back in more easily at some point in the future when I have time. I think one of the main benefits of going to an IETF meeting, as opposed to WG mailing lists or interim meetings, is exactly that. Being aware of what's going on around our own narrow WG interests gives it all a useful context. And more than once I've been able to speak up at a session of a WG I wasn't participating in, and say "hey, are you aware of similar project X being done in WG Z that seems to relate to what we're discussing here?" Because I attend so infrequently, outside of whatever WG I happen to be participating in at the time, few people recognize me. So even though I'm not a newbie, people have no way of knowing that. I've found that the IETF is one of the easiest organizations for a new and unconnected person to be accepted in and taken serious. Perhaps *the* easiest. I often find myself in hallway conversation with chairs and ADs and protocol authors, who don't seem to think of themselves as any different from any other IETF attendees, and who will speak with anyone who has an interesting point to make, whether they know the person or not. Sure, there are some barriers, when some people know each other and other's don't. But in the IETF, the barriers are at their weakest. As with all such situations, a lot of the perceived barrier is likely in the perceiver's head, and in this case, I think that's more true than in most. If you *think* there's an old-boy network, and treat people accordingly, and hesitate to talk, that can be self-fulfilling. It's easy to percieve a clique where there isn't one, if you're expecting a clique. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- Exodus Professional Services -- http://www.exodus.net/ "We all misuse the net for personal gain, one way or another." -- Larry Wall [EMAIL PROTECTED]
