Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sep 6, 2013, at 8:07 AM, Eliot Lear l...@cisco.com wrote: On 9/6/13 3:04 PM, Martin Sustrik wrote: So, what if an NSA guys comes in and proposes backdoor to be added to a protocol? Is it even a valid interest? Does IETF as an organisation have anything to say about that or does it remain strictly neutral? It's happened before and we as a community have said no. See RFC 2804. What if they didn't say they were NSA guys, but just discretely worked a weakness into a protocol? What if they were a trusted senior member of the community? That way lies madness -- but it is a madness we must contemplate. Broader REAL consensus, rather than apathetic agreement with a single contributor's assertions is probably the right way to go. That means an increasing thrust on educating IETFers, broadly, about security issues. Not just the math, but the whole op-sec envelope. -- Dean
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sep 6, 2013, at 9:55 AM, Dave Crocker d...@dcrocker.net wrote: In other words, the IETF needs to assume that we don't know what will work for end users and we need to therefore focus more on processing by end /systems/ rather than end /users/. But we are also end users. I recall being laughed at 6 or 7 years ago when I suggested that email security implementations would get better if the IETF insisted on using them for our email. My proposal at the time was, that since we thought S/MIME was the cat's whiskers, we should set up a CA and issue free end-user certs to all participants. Messages to IETF lists would require signing with said certs to be considered valid. This would make it easy to eliminate most of our SPAM. So, we could eat our own dogfood, with whatever anti-surveillance mechanisms we specify. I am positive that would make things more end-user usable, over time. -- Dean
Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
This is bigger than the perpass list. I suggested that the surveillance/broken crypto challenge represents damage to the Internet. I'm not the only one thinking that way. I'd like to share the challenge raised by Bruce Schneier in: http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying To quote: --- We need to know how exactly how the NSA and other agencies are subverting routers, switches, the internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do. Two, we can design. We need to figure out how to re-engineer the internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information. We can make surveillance expensive again. In particular, we need open protocols, open implementations, open systems – these will be harder for the NSA to subvert. The Internet Engineering Task Force, the group that defines the standards that make the internet run, has a meeting planned for early November in Vancouver. This group needs dedicate its next meeting to this task. This is an emergency, and demands an emergency response. The gauntlet is in our face. What are we going to do about it? -- Dean Willis
External link to article on trends in anti-surveillance design
Some of you may recall me ranting several years ago about the importance of including anti-surveillance features as mandatory aspects of our protocols. I seem to recall getting (mostly) politely laughed at ... Anyhow, there's an article on the topic in Wired right now that hints at the commercial reasons why service companies MUST build anti-surveillance into their products in order to maintain market viability -- because their competitors are going to do it and draw away the users. The same can apply to our protocol designs. http://www.wired.com/opinion/2013/08/stop-clumping-tech-companies-in-with-government-in-the-surveillance-scandals-they-may-be-at-war/ he point I'd like to make is that not only should our protocols be designed so as to reduce their surveilability, they should also be design to help other protocols do the same. Encryption, random ports, random packet sizes, random interpacket timings, multipath, and peer-to-peer with relay support. Think about it.
Re: Sufficient email authentication requirements for IPv6
On Mar 30, 2013, at 10:43 AM, John C Klensin john-i...@jck.com wrote: It sometimes feels as if anti-spam efforts are trending in the direction of its being acceptable to accidentally discard a few dozen legitimate messages if doing so allows blocking a few thousand unsolicited/undesired ones. I hope we never consider that a good tradeoff but, if we do, the decisions should at least be made openly and with some degree of community consensus. The trend in the market (meaning young people) is that it seems to be preferable to discard ALL email messages just to avoid getting a few SPAM. That's a large part of why they use closed-group systems like Facebook and Twitter in preference to email. Subsequent filtering/blocking and automatic mailing lists (like the list of everybody who is interested in me and that I haven't explicitly blocked) and the other big part of the appeal of closed-group systems. I've tried to imagine using Facebook-like system for IETF work, and it is strangely compelling ... -- Dean
Thinking about text production and the Draft word processor
I stumbled on a link to a rather interesting word processor called Draft: https://draftin.com/ The main claim to fame here is support for collaborative writing and review with better incremental/history management than certain other browser-centric document production tools. It also uses a wiki-like inline markup language for formatting, which it translates to HTML markup for display. This raises some thoughts: 1) Something like Draft might make a simpler tool for I-D collaboration than github (which I used recently for a large I-D project). An author team could make use of it as-is. 2) Perhaps a wiki-like formatting language could be adapted to I-D writing; it could be made to generate XML2RFC output instead of HTML. If we had a Draft that generated XML2RFC (particularly with a bi-directional transform) and a closely-mated issue tracker, the combination might be very cool. -- Dean Willis
Re: The RFC Acknowledgement
On Feb 10, 2013, at 3:02 PM, Michael StJohns mstjo...@comcast.net wrote: I have been told anecdotally that some companies or organizations provide bonuses or bounties of different values for employees that get their names on a ID or RFC as document editor, author, co-author or contributor (in the acknowledgements section). I'm not sure of the reality with respect to this anecdote, but I'd hate to find some sort of mandatory thank you being required which might result in additional comments that add little or nothing to the process simply so someone can get a bonus. It's simply not the IETF way. I agree with everything you've said, and would happily prepare a cover page with both our names so that I can share in the credit for having said so. Seriously, commenting on drafts is just a part of the work process, a part of the social contract of the IETF. People making minor comments on a draft shouldn't expect to be acknowledged in the draft for that contribution to the draft, any more than the pigeons unloading on a park statue should get acknowledged on the plaque for their contribution to the sculpture. There are plenty of RFCs out there for which I've made large investments of time (say, over 10 hours, perhaps as many as 200 hours) that don't mention me. That's OK. Usually, if I have to work that hard on a draft, it was so bad that I really don't want my name on the final product anyhow ;-). After all, the purpose of having a name on top of the draft is to know who to blame for the content, which helps in predicting the value of their future contributions. Anonymity can actually boost one's credibility in such circumstances. -- Dean Willis
Re: A modest proposal
On Mon, Jan 21, 2013 at 10:57 PM, William Jordan wjordan...@gmail.com wrote: Whoever thought it was a good idea to allow multiple ways of doing the same exact thing would hopefully be deterred by actually writing code to do it. I think a suitable punishment for those people would be to write each way of writing a from header on a blackboard 100 times... this would actually be less of the pain they've cause by making each writer of a SIP stack handle each possible way of doing things. I know this because I chaired the meetings for the RFC 2543 to RFC 3261 re-write. It's even worse than you think; half of the participants were hard-core coders, each of whom had done an implementation (or two). The other half were philosophy or art students, who wanted the spec to be beautiful and meaningful and true and formally correct and all those good things. And EVERYBODY had a conflicting understanding for what they wrote, mostly based on fondling a different part of the elephant. I was just lazy and tried to keep from having to rewrite too much code due to spec changes, except of course for that parts that were totally bogus (like strict routing). It's called a committee for a reason. That's where one gets two-headed llamas and the US federal budget. Oh wait, we don't have a budget yet, going on three years. -- Dean
Re: A modest proposal
On Tue, Jan 22, 2013 at 4:11 AM, William Jordan wjordan...@gmail.com wrote: Continuing my discussion about how badly SIP is designed, I'm gonna talk about the via line. First of all each via line can be expressed as via: OR v: OR you can have multiple via entries on the same line separated by a comma where random whitespaces are allowed. Hey, we stole that stuff from HTTP. We're not smart enough to invent something that broken. I think HTTP stole it from RFC 822. Additionally, I can't understand why each line is terminated with CRLF, why use two characters when one will do. Microsoft-OS text editors. Seriously. People wanted to be able to write correct SIP messages using text editors, and there were more Microsoft users than Linux users on the list. And we agreed because that's the way it works in HTTP, which got it from RFC 822 (there's a reference in the spec, so we KNOW where that came from!) I could also go into a design argument about how the same specification is used for udp as for tcp and why the idea for a stateless SIP proxy wasn't thrown out completely when writing the draft, but I'll wait on those. Yeah, keeping both UDP and TCP was stupid. We should've just specified TLS, but there were all these 8-bit processors out there ... and countries where TLS was illegal. In fact, we couldn't export a TLS stack from the US at the time without special paperwork. So, allowing for both protocols got us exportable product, and passing the IESG security police at the same time. Stateless proxies were seen as key performance enablers. Our high-end super-performant proxy running on a $40,000 quad-core Sun box could only get like 8 transactions a second, so every CPU optimization was sacred. But hey, live and learn ...
Re: Making RFC2119 key language easier to Protocol Readers
On Jan 5, 2013, at 3:13 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sat, 5 Jan 2013, Abdussalam Baryun wrote: Hi Mikael Also what it means following things in it that is not RFC2119 language. It will mean, you should understand me/english/ietf/procedure even if I don't have to explain, and you need to understand English well even if you are a great implementor or great programming language speaker. The problem here is that I want them to pay back some of the money (or take back the equipment totally and give back all money) for breach of contract, when I discover that they haven't correctly (as in intention and interop) implemented the RFC they said they said they were compliant in supporting. Ianal, but it feels that it should easier to do this if there are MUST and SHOULD in there and I asked them to document all deviations from these. What about when the MUST and SHOULD are in the context of Alice MUST send a request message to Bob and you don't have users named Alice or Bob? Seriously -- at what point does replacing all action verbs with 2119 language make the protocol spec LESS useful for compliance certification? -- Dean
Re: Making RFC2119 key language easier to Protocol Readers
On Jan 5, 2013, at 10:03 AM, John C Klensin john-i...@jck.com wrote: And, again, that is further complicated by the observation that IETF Standards are used for procurement and even for litigation about product quality. We either need to accept that fact and, where necessary, adjust our specification style to match or we run the risk of bodies springing up who will profile our Standards, write procurement-quality conformance statements for their profiles, and become, de facto, the real standards-setter for the marketplace (and obviously do so without any element of IETF consensus). I'm not sure that's not a good thing. Witness for example the work SIP Forum has done with the SIPConnect standards, which have made it MUCH easier to order a box that will work with a SIP Trunking service. -- Dean
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
On Jan 7, 2013, at 4:53 AM, Stewart Bryant stbry...@cisco.com wrote: Speaking as both a reviewer and an author, I would like to ground this thread to some form of reality. Can anyone point to specific cases where absence or over use of an RFC2119 key word caused an interoperability failure, or excessive development time? I'm anecdotally familiar with some early pre-RFC 2543 SIP implementations where the implementors ignored everything that didn't say MUST and got something that didn't work. At all. But it was apparently really easy to develop, as the spec only had a few dozen MUST clauses, and the developers didn't include-by-reference any of the cited specs, such as SDP. When we were trying to decide whether to make RFC 3261 (the replacement of RFC 2543) a draft standards instead of a proposed standard, I recall Robert Sparks and some others attempting to define a fully interoperable implementation test that tabulated all of the RFC 2119 invocations that had sprouted in FC 3261. They then immediately gave up the idea as impractical, we recycled at proposed, and gave up on every making full. The testing methodology has greatly improved since then, and it makes lithe use of RFC 2119 language for test definition or construction. -- Dean
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
On Jan 8, 2013, at 12:57 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: but the question of error in process is; does the RFC lack communication requirement with the community? Sorry if not clear. I mean that as some participant are requesting a scientific approach to struggling with 2119 (i.e. thread-subject), does that mean in some RFCs the use or not use (i.e. we see that participant use different approaches to follow the 2119) that it may add communication confuse with some of community? I'm absolutely certain that some of our community is confused about something related to this thread. Given the absence of information that would help in a decision, might preference would be just to pick one, and provide a stick for hitting those who do it the other way. -- Dean
Re: travel guide for the next IETF...
On Jan 4, 2013, at 4:14 PM, Yoav Nir y...@checkpoint.com wrote: Looking in Google Earth, you'll still need a car. Even with those hotels that are within walking distance, there are big stretches of road without any sidewalks. Having a car won't do any good. There is, as far as I can tell, no place to park it but the hotel valet. Staying somewhere else doesn't sound like much of an option, either due to the park-and-ride situation. This may be a new record in really awkward location; it could top the Dublin golf course (which was saved only by a shuttle bus to reality). -- Dean
Re: I'm struggling with 2219 language again
Well, I've learned some things here, and shall attempt to summarize: 1) First. the 1 key is really close to the 2 key, and my spell-checker doesn't care. Apparently, I'm not alone in this problem. 2) We're all over the map in our use of 2119 language, and it is creating many headaches beyond my own. 3) The majority of respondents feel that 2119 language should be used as stated in 2119 -- sparingly, and free that MUST is not a substitute for does. But some people feel we need a more formal specification language that goes beyond key point compliance or requirements definition, and some are using 2119 words in that role and like it. I'm torn as to what to do with the draft in question. I picked up an editorial role after the authors fatigued in response to some 100+ AD comments (with several DISCUSSes) and a gen-art review that proposed adding several hundred 2119 invocations (and that was backed up with a DISCUSS demeaning that the gen-art comments be dealt with). My co-editor, who is doing most of the key-stroking, favors lots of 2119 language. And I think it turns the draft into unreadable felrgercarb. But there's nothing hard we can point to and say This is the guideline, because usage has softened the guidelines in 2119 itself. It's rather like those rules in one's Home Owner's Association handbooks that can no longer be enforced because widespread violations have already been approved. There appears to be interest in clarification, but nobody really wants to revise the immortal words of RFC 2119, although there is a proposal to add a few more words, like IF and THEN to the vocabulary (I'm hoping for GOTO, myself; perhaps we can make 2119 a Turing-complete language.) -- Dean
I'm struggling with 2219 language again
I've always held to the idea that RFC 2119 language is for defining levels of compliance to requirements, and is best used very sparingly (as recommended in RFC 2119 itself). To me, RFC 2119 language doesn't make behavior normative -- rather, it describes the implications of doing something different than the defined behavior, from will break the protocol if you change it to we have reason to think that there might be a reason we don't want to describe here that might influence you not to do this to here are some reasons that would cause you to do something different and on to doing something different might offend the sensibilities of the protocol author, but probably won't hurt anything else. But I'm ghost-editing a document right now whose gen-art review suggested replacing the vast majority of is does and are prose with MUST. The comments seem to indicate that protocol-defining text not using RFC 2119 language (specifically MUST) is not normative. This makes me cringe. But my co-editor likes it a lot. And I see smart people like Ole also echoing the though that RFC 2119 language is what makes text normative. For example, the protocol under discussion uses TLS or DTLS for a plethora of security reasons. So, every time the draft discusses sending a response to a request, we would say the node MUST send a response, and this response MUST be constructed by (insert some concatenation procedure here) and MUST be transmitted using TLS or DTLS. Or, a more specific example: For the text: In order to originate a message to a given Node-ID or Resource-ID, a node constructs an appropriate destination list. The Gen-ART comment here is: -First sentence: a node constructs - a node MUST construct We'll literally end up with hundreds of RFC 2119 invocations (mostly MUST) in a protocol specification. Is this a good or bad thing? My co-editor and I disagree -- he likes formalization of the description language, and I like the English prose. But it raises process questions for the IETF as a whole: Are we deliberately evolving our language to use RFC 2119 terms as the principle verbs of a formal specification language? Either way, I'd like to see some consensus. Because my head is throbbing and I want to know if it MUST hurt, SHOULD hurst, or just hurts. But I MUST proceed in accordance with consensus, because to do otherwise would undermine the clarity of our entire specification family. -- Dean
Re: [ietf-privacy] ITU, DPI, and Deliberate Obscurity
On Dec 9, 2012, at 11:46 AM, SM s...@resistor.net wrote: Hi Dean, At 08:55 09-12-2012, Dean Willis wrote: A couple of years back we had some discussion about the need to design IETF protocols to be DPI resistant. One principle that I think should guide our efforts is that not only should each protocol be itself DPI resistant, but it should deliberately assist other protocols in being DPI resistant. I call this intentional mutual obscurity. Is this about security or privacy? Privacy, absolutely. How can you have privacy when your packets are being probed to figure out not only what's in them, but who you're talking to, what applications you are running, and what you're talking about? It's like the inverse of do not track powered by a nuclear reactor. If you're not having kittens about this, you just don't understand the implications ;-). Assume DPI is present, even required, at multiple layers in the network. Do you think we can assure the preservation of privacy by publishing some nambypamby guidelines on what the DPI operators can do with the information they've gleaned? Even when there's no business relationship between the user and the DPI operator and no informed consent? -- Dean ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: Expiring a publication - especially standards track documents which are abandoned
On Sun, Sep 4, 2011 at 9:23 AM, todd glassey tglas...@earthlink.net wrote: To that end I would like to propose the idea that any IETF RFC which is submitted to the Standards Track which has sat unchanged in a NON-STANDARD status for more than 3 years is struck down and removed formally from the Standards Track because of failure to perform on the continued commitment to evolve those standards. That's not a bad idea. At the very least, it clearly illustrates that our process is broken. We have rules that we're not really using. In our quest for better, we've made things too difficult to comply with. It's time to make it easier for a change. Automatic expiry, as you propose, is easy. But given the fact that long-lived PS have essentially become standards, I'd like to make a counter-proposal -- semi-automatic advancement. We set a 3-year life-cycle for Proposed Standard, Draft Standard, and Standard. On the 3rd anniversary of any state, the RFC Editor polls the IESG (which might seek community input). If anybody is actually developing from the document, the document, it advances to the next standards-level or remains a full standard, and the RFC Editor edits in any posted errata and republishes (whether as a new RFC no. or a version of the original RFC number is open). If nobody is using it, it goes to historic. Such a poll should be pretty easy; one post to the IETF list, and a 2-min discussion on the telechat. When I say developing from the document, I don't mean using the protocol specified by the document in a static deployment, but referencing the document in new deployments, or actively trying to revise the protocol therein. I'm guessing FTP would probably qualify as one of the things that would move from standard to historic. And HTTP, although something we're still working on its bis, would be a full standard (which might be revised by a proposed standard replacement as we make more progress on it). -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponsorship (and hence lower costs to the IETF for meeting infrastructure and arrangements) and meetings costs to attendees are made... open enough that the community could give substantive guidance on the subject, guidance that I assume the IAOC would follow if it were coherent and plausible. Quite right. There's more than just the hotel rates. My budget is about $2500 US per IETF meeting. That has to cover airfare, the IETF meeting fee, the hotel, meals, service charges, ground transport, mobile phone roaming, incidentals, etc. $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE FREAKING QUESTION. Having the backup hotel a 10 minute taxi ride away is out of the question -- I can't afford taxis. If I can't walk, I can't go. So guess what? I told the wife last night that I wasn't planning to go to the Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe I'll win the lottery between now and then... I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting worse and worse with every venue. I want the IAOC's heads on a platter (preferably an inexpensive, disposable platter, like maybe the lid off an old pizza box) for signing us up to this venue. And I want a travel budget no larger than mine for the people we send to future meetings. If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE THE MEETING! -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis -- Tying our hands?
On 8/30/11 2:08 PM, Adam Roach wrote: Because the current suggestion -- which turns RFC writing into the game Taboo [1], but with incredibly common English words [2] as the forbidden list -- is ridiculous on its face. Don't use requirements language unless you absolutely have to. Otherwise, explain things in clear prose, describing what happens in normal and error cases, and the logic used in distinguishing them. If you absolutely require RFC 2119 requirements language to make something clear, I suggest the following symbology: ✔: MUST ☂: SHOULD ♥: MAY ✖: MUST NOT ♠: SHOULD NOT ☹: MAY NOT And the fact that the above is garbled for some large percentage of readers explains why we use 7-bit ASCII in drafts, so let's just stop that argument now, ok? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Queen Sirikit National Convention Center
On Aug 9, 2011, at 1:00 AM, Glen Zorn wrote: On 8/8/2011 2:56 PM, Ole Jacobsen wrote: Nothing is a reasonable walk when the average temperature is 32 C. At least not for the average IETF attendee. Just to add a little perspective for the Celsius-challenged ;-), 32C = 89.6F. Warm, but not IMHO life-threatening, even for the sedentary ;-). Y'all come on down to Dallas. It was 39C while I was walking the dog last night, down from the daily peak of about 44C. We're looking forward to October, when the highs should drop to 32C. And the lows to around zero pack a sweater. And yep, I'm probably a flabby, nigh-on-fiftyish average IETF attendee. We're tougher than you think, Ole! On the other hand, 22 hours of air travel is pretty much close to fatal. Whatever happened to bunk beds on planes? Couldn't we just rent a university building in Hawaii? That's sort of a midway point between everything. Classroom chairs can't be any worse than Hilton chairs, and it would be really handy to have built-in white boards for markup. Besides, I've always wanted to have a plenary in a football stadium. With cheerleaders. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 22, 2011, at 4:51 AM, Dave Cridland wrote: 1) There are no SRV records. 2) Therefore browsers do not support them. 3) Therefore you'd need to allow for A-lookup as fallback for the forseeable future. 4) Therefore there's no incentive for browsers to support SRV. That's pretty much where we were when we grafted SRV onto SIP eleven and a half years ago, updating earlier SIP drafts (which lacked SRV support). There was no incentive for SRV support in SIP user agents at the time, either. See: http://tools.ietf.org/html/draft-ietf-sip-srv-00 The first SIP RFC 2543 used SRV, but didn't work very well. RFC 2782 cleaned up the SRV process somewhat, but we required further documentation for SIP to make use of it effectively. It eventually worked itself out as RFC 3263, which also involved NAPTR records and a slew of other DNS kludges. But barring the limitations of DNS (some people still want requester-variant answers), it works pretty well now. But yes, there's more to effective target resolution than just saying Use SRV records. Especially if you have multiple protocol choices, proxies, aliases, and TLS in the mix. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote: I'm sorry I'm late, this thread was in my backlog. We now have an obscurity-inter...@ietf.org list for further discussion if you wish to join us there. On 12.03.2011 19:48, Dean Willis wrote: On a related note, we've developed what we think is a secured mail protocol suite. Yet we don't use it, instead subjecting our list members (and more so the administrators) to having to deal with an endless barrage of spam. We probably don't use our secured mail protocol because it is too cumbersome. Maybe that should be a wake-up call for us to develop a better way to secure mail. What secured mail suite? I have some difficulty in recognizing whether you're talking about SMTP + Submission + DKIM + whatever else or some other messaging system. I agree that current Internet mail, with its one-figure legitimate traffic percentage, is a conspicuous representative of IETF's hall of shame. We have this whole S/MIME thing that nobody uses. We tried to replicate it to real-time communications, like SIP and Instant Messaging. Oddly enough, nobody uses it there either. Maybe that's because it doesn't deploy very well. Most critically, we've recognized that Internet users may have needs for privacy [...] And having recognized these principles, we need to start taking much more aggressive steps in protocol design to assure that they are actually being met in a useful way. I also heartily agree with this, and with all the motivations that inspired this thread. However, I have difficulties resolving my feelings on this point: Freedom activists in my country bring out a whole load of grievances every time Berlusconi attempts to restrict usage of wiretapping. In facts, this tool is a requirement for carrying out investigations at a sustainable cost. I'm not necessarily against wiretapping. I think it's a great way to build a criminal enterprise, if that's your goal. However, I am against explicitly designing exploitable weaknesses into our protocols. I'm even against implicitly designing in exploitable weaknesses by leaving compliance-test requirements for security as SHOULD strength issues, or by writing the specs in such a way that we can expect the security functions to never be implemented or used. I think the IETF must substantiate its position against wiretapping by providing alternative practical means to counter crime. Weak security doesn't counter crime -- it creates it. For example, the US government recently illegally tapped lots and lots of phone calls and Internet traffic at an ATT switching center. Had the traffic been properly secured, this criminal behavior could have been prevented. Do you want to counter crime, or prevent criminals from communicating with each other? One is laudable. The other is prior restraint of freedom of speech. Failing to do so would recast ourselves as proposers of Utopian designs. And, yes, after more than a decade of spam supremacy, email would certainly be a convincing test-bed for our ability at providing such alternative means. We can start by: 1) deprecating the non-secured variant of every core protocol that has both secure and non-secure variants Among SMTP variations, RFC 4409 is the more promising requisite for solving a number of authentication issues. Note that it conflicts with peer-to-peer visions à la mondonet, though. Well, it's better than nothing. It's got my spam load down to a bit less than 98% of my incoming mail. But we can't expect every IETFer to SMTP-auth with the IETF server for every message they send to an IETF list. Nor can we detect whether remote domains used RFC 4409, nor can we filter on that knoweldge. Consequently, our lists get spammed. Perhaps every server-to-server SMTP transmission should be authenticated and authorized. We tried this (authorizing intermediaries) with SIP's Consent model. See RFC 5360. That didn't work either; the genie was already out of the bag, and having too much fun running around in his pajamas. 2) not writing any more protocols with secured and non-secured variants 3) analyzing existing protocols that are fundamentally non-secured and determine which, if any, security enhancements should be made normative While these are certainly correct, ensuring implementation and deployment is also fundamental. I accept and respect the limits of IETF's action, and consider non-enforcement a key feature in the volunteer-oriented design that is being carried out. However, we should pay more attention to the full protocol life cycle. I believe that from a security perspective, the most important part of the protocol life cycle is the development and testing phase. People tend to rush right to deployment once something is basically working. If security is deferred to a follow-on exercise, it just doesn't happen. Consequently, we need to make sure that every protocol we
Redirect to sip-implementors: was( Re: SIP UDP packet loss?)
You'll probably get a million of these replies, but I'll try and head them off: Rather than the lists coped here (which deal with a wide variety of other topics), please try the SIP Implementors List: sip-implement...@lists.cs.columbia.edu Thanks! Sorry to the rest of the folks I'm spamming here. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Privacy, Integrity, Security mailing-list invitation
We've set up a mailing list obscurity-inter...@ietf.org. You can sign up at: https://www.ietf.org/mailman/listinfo/obscurity-interest or the usual way, by sending an email with subscribe in the body to obscurity-interest-requ...@ietf.org We'll be trying to get together in Prague. According to the doodle poll, it's looking like Wed or Thursday morning 0800 is the best bet, with Thursday evening the second best. I've got a room request in to the admins. They'll probably just laugh at me, but we might get a room. Again, what I think are our first-round discussion questions: 1) What is different about this exercise from the ongoing privacy discussion on priv...@iab.org/ietf-priv...@ietf.org? 2) What really NEEDS to be done? 3) What do we think we might actually be able to do? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Mar 14, 2011, at 5:17 AM, Iljitsch van Beijnum wrote: Privacy and obscurity are tools that cut both ways. It can protect legitimate communications from evil regimes, but it can also shield illegal behavior from the law, or privacy violations commited by applications, or services running in a browser from the user. Shielding illegal activity from the law is a prime use case. if we consider that political discourse is an illegal activity under conditions that some authoritarians, supported by violence, call the law. As for a trojan service running on your computer being shielded: Nobody suggested that the applications API-calls to your transport layer have to be encrypted. I personally believe you should have full access to your own computer's innards. And I suspect that a great many trojans also communicate privately today, even though we're still putting our user's data out on public display. It also makes debugging orders of magnitude harder, uses more overhead and engergy and slows down the communication. (Especially in mobile networks where one end is on battery power and the extra round trips required to negotiate encryption and authentication are typically slow.) True, things have consequences. Someone on this thread emailed me a quote from Benjamin Franklin: They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Much can also be said about those who give up essential liberty in order to obtain a bit of convenience or a marginal increase in battery power. Your argument is something akin to requiring people to not lock the doors on their homes, because not having the doors locked might make it easy for emergency services personnel to respond to a reported break-in. As for overhead, someone else was kind enough to send me a link to tcpcrypt, which seems to offer a lighter-weight solution than TLS: http://tools.ietf.org/html/draft-bittau-tcp-crypt-00 As I've said earlier in this thread: if our security tools are too heavy to use, we need to consider the possibility that we need new tools. As such, it would be a very big mistake to start encrypting ALL communication. Whether the applying these mechanisms is sufficiently beneficial to be worth the numerous downsides should be evaluated on a case-by-case basis. It's not the IETF's job to force vendors and users to do something that they would otherwise choose not to do. True, there are certain communications that are truly broadcast in nature and would be disserviced by requiring them to be encrypted. Many of them, however, would do well to be integrity-protected. Consider the harm that a rogue DHCP server can produce. It IS the IETF's job to decide whether IETF protocols will be published with built-in back doors, especially when we know that by default said back doors will be generally left standing wide open and that most developers (and consequently users) will never bother to even try the more-secured front door and see if it works for them. If we don't want security holes, we shouldn't build them into our protocols! You're trying to attack the problem from the wrong side, anyway: you assume using the large infrastractures that are easy to control by states and then try to add a layer of protection. It would be better to work around these infrastructures completely. Why is it that when I email my colleague two meters away, within easy wireless range, that the message goes through the servers of Google somewhere (not even sure in which country those are)? That's also a very good question, and I'm aware and supportive of efforts to make a fundamental change here. One thing that was brought to my attention during this conversation is Mondonet: http://www.mondonet.org Self-organizing models have tremendous potential. Consider how important something like this could be for rescue efforts currently underway in Japan. Imagine how much better the communications could be if every cell phone switched over into a self-organizing ad-hoc mode and relayed messages peer-to-peer both between phones and back to whatever fixed infrastructure survives. But that simple fact of the matter is that TODAY we have this large infrastructure called The Internet and that TODAY it is easily controlled by states and intercepted by criminals , and that TODAY people are using it to organize against abusive states and to carry out their private lives (financial or otherwise), and that TODAY people are being robbed, killed or otherwise suppressed because our infrastructure leaks private data all over the place. So, what are we going to do about today's networks for tomorrow, not for the next millennium? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Doodle poll for Privacy, Integrity, Obscurity ad-hoc in Prague
Several people suggested i throw a Doodle poll together for gauging the best time to get together. I'm not a big Doodle user, but here's a first try: http://www.doodle.com/ikbeihxb2ny539wr And yeah, Doodle is probably leaking ostensibly private information. Sometimes, its worth it; that's called informed consent. -- Dean___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
) Incorporating the principles of Privacy, Integrity, and Obscurity directly into our core mission statement, into the very fabric of our belief system, just as Liberté, égalité, fraternité became the driving motto of the Third Republic of France, ending much of the abuse of Privilege that preceded the revolution. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Mar 11, 2011, at 7:13 PM, Mark Nottingham wrote: I'm also okay with air-dropping satellite terminals and television receivers to their victims, and with beaming high-power wireless signals across their borders in order to speed things up. And how likely are those things to actually happen and have a measurable effect? Seriously. From today's news, Cuba seems to be worried about it: http://www.cnn.com/2011/WORLD/americas/03/12/cuba.alan.gross/index.html?eref=mrss_igoogle_cnn -- Dean___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity,
On Mar 11, 2011, at 11:03 AM, Martin Rex wrote: Phillip Hallam-Baker wrote: 1) WPA/WPA2 is not an end to end protocol by any stretch of imagination. It is link layer security. It is a 100% end-to-end security protocol. I'm reminded of those signs saying Repent! The end is closer than you think! I think we have different ends in mind here. In the real-time community, we usually think of WPA2 as an end to middle security protocol, in that it doesn't protect the entire path from Alice to Bob unless both are running on the same ad-hoc wireless network. It does protect the specific link, say from Alice to her access-point, but does nothing to keep the access point itself from mirroring the cleartext onto another port. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Follow-on to Jasmine call: poll for ad-hoc in Prague
I recently made a call on this list for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity. This generated a lot of interesting discussion, and several people have suggested that we get together informally in Prague. Key points for discussion, I believe, include: 1) What is different about this exercise from the ongoing privacy discussion on priv...@iab.org? 2) What really NEEDS to be done? 3) What do we think we might actually be able to do? I'd like to poll for interest in getting together. We could get together for dinner or a beerish outing, or we might be able to get a break-out room. Feasibility varies with interest level. I'm initially leaning towards something Monday post technical-plenary, but the schedule is still quite fluid. So, please let me know if you're interested in joining up. On a related note, I'm to putting together an interest-group mailing list. This will be announced on ietf@ietf.org when complete. In the interim, if you're interested in participating, please let me know and I can administratively pre-load you on the list. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Mar 10, 2011, at 12:31 PM, Mark Nottingham wrote: This will have the effect of isolating some companies and countries from the Internet. Is that a good outcome? You mean some third-world (or soon to be) junta-dictator might officially and deliberately cut their economy off from the world's communication networks, thereby insuring economic failure, rather than suffer the risk that their citizens might be exposed to external influence or use the Internet to complain about or conspire against their lawful leaders, rather as North Korea has done? I'm OK with that. It helps bring about their failure due to economic collapse rather than requiring outside force to stop their depredations, although it might take a few generations to work. I'm also okay with air-dropping satellite terminals and television receivers to their victims, and with beaming high-power wireless signals across their borders in order to speed things up. -- Dean___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
by the nature of their response. Many will quite reasonably say This is hard to do. I agree; we can't expect immediate perfect answers, just as we know we've never been able to get perfect answers to most any security question, we know we will never produce perfect solutions for these issues. Others will say that these goals are undesirable. I suspect that these individuals are either proprietors of deep-packet-inspection tools, thieves, or accessories to the overbearing governments who employ and enable the afore-mentioned classes of miscreant. Others may agree wholeheartedly, but flinch at the political repercussions. To them, I say: Step up. No good deed goes unpunished, but at least the goal is worthwhile. And it's probably safer than standing in front of a tank or a camel-cavalry charge, although less likely to get you remembered. Yet others may ask why this proposal is made now, rather than the first of next month. To them, I say that timing is everything. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12
This was more a discussion of scope than validity. Of course, having public discourse in a community of experts that disparrages the validity of a claim could bolster invalidation arguments. So I can see how this might be a disavored act in the IEEE community, which seems to be slanted towards rights holders (I speak as a long-term member of IEEE and as a consultant on IPR). Perhaps we'd all be better off if the IEEE were a little more critical of misguided claims? Regular raising of a hue and cry of Bullshit! would go a long way towards reducing the damage caused by unmerited patents. -- Dean Willis --- Original message --- From: Trowbridge, Stephen J (Steve) steve.trowbri...@alcatel-lucent.com Cc: ietf-...@ietf.org, p...@ietf.org, adrian.far...@huawei.com, i...@core3.amsl.com, andrew.g.ma...@verizon.com, stbry...@cisco.com Sent: 14.4.'10, 8:47 Hi all, In IEEE we are admonished to never discuss the essentiality or validity of patent claims. I cannot believe this is considered an appropriate discussion in IETF. Regards, Steve -Original Message- From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Yaakov Stein Sent: Wednesday, April 14, 2010 1:44 AM To: mmor...@cisco.com; lmart...@cisco.com; tom.nad...@bt.com; Aissaoui, Mustapha (Mustapha); david.i.al...@ericsson.com; Busschbach, Peter B (Peter) Cc: i...@core3.amsl.com; Secretariat; p...@ietf.org; adrian.far...@huawei.com; andrew.g.ma...@verizon.com; stbry...@cisco.com Subject: Re: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12 This disclosure (1311) quotes application US20080089227A1: Protecting multi-segment pseudowires which may impact draft-ietf-pwe3-redundancy, and perhaps ICCP, MS-PW architecture, and MS-PW setup. There is no apparent connection with oam-msg-map - in fact the claims stress that the triggers are failures of PSN elements (e.g. S-PEs) and are NOT from the ACs, making any connection untenable. A previous disclosure by the same company (863) refers to 20080285466 : Interworking between MPLS/IP and Ethernet OAM mechanisms which may impact mpls-eth-oam-iwk, but not oam-msg-map, unless one interprets the first claim and its dependents much more broadly than supported by the background and description. Can someone from the company claiming this IPR fix the information in these disclosures ? At very least that company is required to disclose IPR is holds with respect to the appropriate drafts (unless it is willing to risk forfeiting its rights with respect to these ...). However, with respect to oam-msg-map I would like to request that it consider removing inappropriate disclosures. Of course, if after consideration it believes that these disclosures ARE appropriate, I would love to hear the reasoning. Y(J)S -Original Message- From: IETF Secretariat [mailto:ietf-...@ietf.org] Sent: Tuesday, April 13, 2010 18:46 To: mmor...@cisco.com; Yaakov Stein; lmart...@cisco.com; tom.nad...@bt.com; mustapha.aissa...@alcatel-lucent.com; david.i.al...@ericsson.com; busschb...@alcatel-lucent.com Cc: stbry...@cisco.com; adrian.far...@huawei.com; p...@ietf.org; andrew.g.ma...@verizon.com; matthew.bo...@alcatel-lucent.com; ipr-annou...@ietf.org Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12 Dear Monique Morrow, Yaakov Stein, Luca Martini, Thomas Nadeau, Mustapha Aissaoui, David Allan, Peter Busschbach: An IPR disclosure that pertains to your Internet-Draft entitled Pseudowire (PW) OAM Message Mapping (draft-ietf-pwe3-oam-msg-map) was submitted to the IETF Secretariat on 2010-04-07 and has been posted on the IETF Page of Intellectual Property Rights Disclosures (https://datatracker.ietf.org/ipr/1311/). The title of the IPR disclosure is Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12. The IETF Secretariat ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ 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: Public musing on the nature of IETF membership and employment status
On Apr 9, 2010, at 1:21 AM, Hadriel Kaplan wrote: We can all claim our environment doesn’t change our views, but that’s hard to reconcile with human behavior research. Regardless, I think even you’d agree that one’s views on technical issues can easily change if, for example, one were to switch from working for a customer/user to a manufacturer. For example, my company has hired numerous folks for their technical competence or experiences from other sectors of the VoIP industry, who changed some of their views on certain technical issues in SIP or RTP once they learned the issues we have to face on a daily basis. Issues related to interoperability, or hardware vs. software, or scalability and performance – issues that they either didn’t take into consideration or had different assumptions for, when they were “users” running the gear or were working in a different SIP “world”. And working on IETF mechanisms is not only about purely technical arguments – it’s about pragmatism as well, and what one finds pragmatic can easily change based on the environment. That's fair. I would expect somebody to learn new things from their new employer, and they might well change their minds, over time, about positions they once held. Hopefully they'll know why they changed their mind, and be willing to share this rationale. I like to think I'm willing to change my mind (assuming I can find it to somewhere) if I get new information. But to go 180 degrees overnight just because of an affiliation change and instructions from the new boss is not appropriate. Think of it as love versus labor. IETF work is something you just have to love to do well. Going through the motions of love because somebody paid you is labor, We even have a good English word for that sort of labor: prostitution. I might have an affair with a conflicting idea. I might even break off the relationship with my currently-held technical position and elope with the new idea. But I sure hope it's because I've fallen in love with the new idea, not because somebody paid me to cheat on the idea I thought was right. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On Apr 8, 2010, at 7:01 PM, Stephan Wenger wrote: Hi Fred, Would you really expect me not to throw my weight (assuming there were one) behind the proposal I fought teeth and claws before—and damage my relationship with my new employer during the first days on the job? Yep. If you did, most of the people I know around the IETF would never trust you again. Instead, we'd expect you to convert your new employer to your old way of thinking. Either they're hiring because they think you're smart and they want your input, or they're hiring you to shut you up. Are you getting a paycheck from your employer, or are you taking a bribe? They aren't the same thing. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On Apr 6, 2010, at 2:51 PM, Iljitsch van Beijnum wrote: On 6 apr 2010, at 18:16, Mark Atwood wrote: Cisco, IBM, MCI, or Linden Lab are not a members of the IETF. No agency of the US government, or of any other government, is a member of the IETF. No university, non-profit, PIRG, PAC, or other concerned citizens group, is a member of the IETF. Only individual people can be members of the IETF. And membership is mostly defined as who shows up on the mailing list and who shows up at the meetings. True enough, but that's only one side of the equation. Cisco, IBM, etc, etc as a rule don't send their people to the IETF to support the greater Minneapolis area economy or other alturistic reasons: they want their people to get stuff done at the IETF. As such, an IETF participant's affiliations have relevance, and should be clear to all. Considering that, it wouldn't be the worst idea to have everyone post mailing list messages from an employee email address. Then again, I don't need that kind of spam exposure on even more email addresses... And considering the crap that many companies use for email servers, their message-deletion policies and so on, I expect there are a lot of people who wouldn't want that. Flip side: I could see the IETF requiring all participants use ietf.org email addresses hosted on ietf.org servers with ietf.org- issued authentication/signature certificates, and quite possibly (with some exceptions) restricted delivery to/from non-IETF addresses. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On Apr 2, 2010, at 3:56 PM, Ralph Droms wrote: So, with all this discussion, I'm still not clear what to expect. When I walk up to a train ticket kiosk in Schiphol, should I expect to be able to use my US-issued, non-chip credit card (AMEX, VISA - I don't care as long as *one* of them works), or should I have a fistful of Euros handy? My US-issued Visa, Mastercard, Amex, Visa Debit, and Mastercard Debit cards did not work at the automated kiosk in Schiphol last summer. I was able to use the attended desk with a US credit card. I was also able to use a US credit card at the Amsterdam local transit sales counter/ I was also able to withdraw Euros using my ATM (US debit) cards at every location I tried. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On Mar 30, 2010, at 4:55 AM, Robert Kisteleki wrote: On 2010.03.30. 11:41, Iljitsch van Beijnum wrote: I'll prepare information about all of this as soon as I know the transition status during the IETF week. And in any event, there are no early booking / online booking discounts for Dutch train tickets, and buying online with Dutch Railways requires the iDEAL payment system that only Dutch banks use. That reminds me: if you intend to use a credit card in electronic contexts (such as buying train tickets at a machine, etc.), you should make sure you know your PIN code. On the way home from Anaheim I helped some guy who had some problems because he wasn't even aware that his card had a PIN code. Many US cards do not work in point-of-sale applications in Europe even if one knows the PIN code. Last Spring, I had 6 US bank cards and a SwissPost card rejected at the train kiosk in Amsterdam, and I believe the same 6 failed at whatever IETF we last went to in Europe, because I recall borrowing train tickets from Ole. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Make the Internet uncensorable to intermediate nodes
Greg Daley wrote: I would actually not encourage IETF to work on such a technology as this, particularly in the lead-up to IETF Beijing. That would be a serious affront to our hosts. It is quite important to ensure that the IETF particularly is not subject to any external party's agenda in the lead-up to the meeting. How about being subject to an internal agenda, like making the Internet available to people who are suffering under repressive regimes? Obligatoy protest: And given the Google debacle, why are we still going to Beijing? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Motivation to submit an idea in IETF?
On Jan 21, 2010, at 7:51 PM, Greg Daley wrote: I think that whetever the reason, documents submitted to the IETF are less likely to become standards track RFCs if there is critical IPR which must be licensed in order to construct the protocol. As somebody who makes a living explaining patents to people who feel threatened by an infringement suit, the simple fact is that the IETF is appallingly (and blissfully) ignorant of the vast number of patents that are filed relating to our RFCs. In general, we do not discover that there is critical IPR until well after the protocol is published, then we get mad about it. One rational for publishing rather than patenting is cost. If the goal is to assure your rights to use your own invention rather than paying a fee to a patent troll for that use, thorough publication of the invention as early as possible may be a cost-effective solution in countries whose regimes discredit 3rd-party patents of already- published ideas. I've used this technique fairly effectively in patent- busting in the US. I've even used mailing-list records to provide invalidation arguments. Writing an internet-draft describing the invention is cheap. Filing a patent application is expensive. There are documentation fees, legal fees, artwork fees, filing fees, maintenance fees, patent search fees, and the ongoing hassle and expense of examination, re-examination, forced continuations, and so on. You might spend upwards of $50,000 to get a patent (although some do cost much less, especially the do-it- yourself filings). And then you have to enforce the patent, and that's not cheap; you have to look for people who might voluntarily license it and negotiate with them, and you have to look for people who have infringed it and work through a more adversarial negotiation or even an infringement suit. I've seen infringement suits run above half a million dollars. But if you have a patent, don't maintain it, and don't enforce it, it gets weaker or might even completely evaporate. Sure, it serves as strong prior art to keep some other bozo from patenting the exact same thing even if you let the patent go to seed, but all they have to do is tack on one important additional claim that your didn't foresee, and you're back to having to pay the troll. A submitted application is strong prior art. A published paper or internet-draft is pretty good, but not as good. A really clear write- up in mailing-list email can be helpful, especially if the inventor of record (the person whose name is on the patent app) is an active participant on that mailing list. So it all comes down to intent: If your business is a real participant in the industry and you're going to make your money off of building and selling a product that includes the invention, you may get adequate protection for your business by publishing the invention early on. If you're a big fish in the industry, then you probably can benefit from having a pool of patents for cross-licensing with the other big fish, so filing might be useful. And of course, if you're not really participating in the industry but hope to make money off of licensing the invention, then filing is the only way to go, although it's harder to make money off such a patent than you might think. In: A Farewell to Alms: A Brief Economic History of the World. (Princeton, NJ: Princeton University Press, 2007. xii + 420 pp. $30 (cloth), ISBN: 978-0-691-12135-2), the author Gregory Clark cites a number of cases relating to patented inventions in the textile industry, where the inventors who relied on patents for their funding died penniless, but the people who just built things and made product with them experienced economic success. It's a good lesson to us all. Its' a good read as well, and I highly recommend it; my depressing theory, however, is that we're falling off the tail of the success hump and sliding back into a strictly Malthusian model of supply, demand, and starvation. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 11:18 AM, Paul Hoffman wrote: At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark So, are there likely to be problems with paper copies of the magazine at customs? Is it available at English-language newsstands? What other sorts of publications should our attendees leave at home for fear of violating national standards with which me might not be familiar? Are thre likelto be be digital media searches of the sort feared at US and UK customs checkpoints? I suppose DVDs with copies of Pure Heart. Clear Mind episodes would be right out. We wouldn't want to end up like this guy: http://www.amnesty.org/en/appeals-for-action/end-persection-falun-gong-practitioner What other land mines are we likely to step on by accident? Who is going to provide training to the community to keep these sorts of incidents from happening? Sorry, I seem to be just chock full of snarky questions today. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 12:41 PM, John C Klensin wrote: Many of us have been to China multiple times. I am not aware of anyone who has been granted a business or professional visa, and who has gone and behaved professionally, having nearly the problems with entry or exit that have been typical of the US in recent years (even returning US citizens). I've encountered some long lines, bad multilingual signage, and miscellaneous confusion on occasion, but China clearly has no monopoly on those. Thanks, John! I feel very reassured. How about some practical guidance for the folks who haven't been there multiple times, beyond Behave professionally and don't do anything stupid. We have lots of people who don't know they're being stupid because in their world, what they're doing is absolutely normal and they have absolutely no expectation of consequences. These sorts of things can be subtle. A friend's brother was arrested in the UAE last year for possession of melatonin, which is a common over-the-counter sleep therapy in most of the world but is apparently considered a major narcotic in their airport (although you can supposedly buy it OTC in stores in-country). He was very surprised at this, having never even thought it might be an issue. If we were meeting in Dubai, I'd expect medications to be a major problem. But we're not meeting in in Dubai, but China, and China quite likely has equivalent surprises in store. Quite possibly, neither you nor I have ever run afoul of them due to a combination of luck and discretion (which I occasionally DO exercise). But also quite possibly, they'll trip up some of our colleagues. Unlike the US, whose border- liabilities are fairly well understood by IETFers, I'm pretty sure we generally don't know what the likely problems are in China. We need to find out, and we need to educate our community about them. If we (the IETF) can't even figure out what China is doing to Internet traffic, how are we supposed to understand the laws that aren't in our area of expertise? If they think Wired Magazine is dangerous enough that it must be blocked, chances are that they'd find the contents of my home PC appalling (I do too, it runs Windows XP). How about what's on Alice's laptop? For example: As I understand it, one is allowed to bring only one camera and one computer, not two of each. Will this affect camera-and- computer loving IETFers? Possibly, if it's still true. Does the camera in your cell phone count against the quota? How about the one built in a Macbook? I'm much more concerned about the prohibition that goes Printed matter, films, photos, gramophone records, cinematographic films, loaded recording tapes and video- tapes,compact discs (videoaudio), storage media for computers and other articles which are detrimental to the political, economic, cultural and moral interests of China. That's pretty nebulous. It reads to me like leave behind all personal digital media, just in case which is what I generally do. I travel in a fairly sanitized mode, for numerous reasons. Will the average IETFer do this? If not, what, if anything, is likely to surprise them? How many IETFers are going to lose their currency-exchange receipts and consequently be unable to legally turn their excess yuan back into dollars? Or is this still even a problem? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 1:21 PM, Ole Jacobsen wrote: Dean, Get real. When have you EVER had any reading material inspected by ANY authority ANYWHERE in the world? OK, so I am not aware of your particular reading habits and yes, I *can* imagine that *some* material *might* attract the attention of customs officials in any given part of the world, but it would have to be pretty extreme and you would have to literally wave it in front of their faces. WIRED Magazine does NOT in any way fall into the sort of material I am imagining, and I think you know that. That's a pretty naive position, Ole. I've had training manuals confiscated at the Canadian border, had my laptop data searched in a couple of places, had my bags detained for setting off chemical detectors (although returned after secondary searching), had a science- fiction paper-back book confiscated (apparently the cover image was pornographic, although they didn't bother to arrest me, and thankfully, I had already finished the book), and probably quite a few other events over the years. I've even had the sorts of jobs where everything on my person, including papers, got inspected by guards when I was going in and out of the workplace each day. I'm really surprised you haven't had events like this yourself. We should obviously obey the laws of the country in which we have our meeting, but dreaming up worst case scenarios isn't helpful. Really. Sometimes it is hard for outsiders to understand those laws you so blithely say we should obey. Laws can and do catch people by surprise. One of the most effective ways to prevent surprise is by as king what if questions. Do you not think it is reasonable to subject the real- world to the same sort of scenario analysis that we would demand of a transport protocol? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 2:24 PM, Dave CROCKER wrote: Methinks you are implicitly suggesting that the IETF's pages for a site should include some getting along in the site's country guidance as an on-going requirement. Methinks this is an excellent idea. Happily, Doing Business in... types of books are common, as is online information. For example: Chinese Etiquette http://www.goingtochina.com/misc/chinese_etiquette.htm China (especially see the Appearance, Behavior and Communications sections) http://www.cyborlink.com/besite/china.htm Chinese Culture http://chinese-school.netfirms.com/businessculture.html Excellent idea. Specifically, the IETF-type information should be focussed on those things that are likely to impact IETFers, as opposed to conventional business-folks, at a given destination. We aren't average business travelers: We dress more casually, carry much more electronic equipment, often sport unusual haircuts, have a broader array of medical conditions and food issues, have potentially more diverse reading habits, and so on. We're also a lot more likely to form in clusters that engage in loud debates about politically- sensitive topics. And obviously, we aren't ordinary tourists. How many ordinary tourists show up with a backpack full of wireless access points? Is that legal in China? I don't know, but I'm pretty sure one or more of us will do it. And frankly, we're probably more blasé about international travel than well prepared business people might be. The pickpockets in Paris had an absolute field day with IETFers. I'm sure they were quite grateful for our lack of preparedness, relaxed-fit casual pants pockets, richly loaded wallets and expensive cell phones. We seem to have an assumption that every place is pretty much like every other place, they're all happy to see us, and one hotel conference room is the same as all the others. The risks that a typical IETFer might encounter in Beijing are probably different from what you or I or Ole might encounter, given our ages, fairly conservative appearances, and past travel experiences. I think it might be very useful to think through the possibilities and see if we can pre-empt some of them. I did do a quick scan on the references you thoughtfully provided above, and I found the Appearance, Behavior, and Communications) reference especially interesting, because I just can't imagine a pack of IETFers complying with that set of rules. This is starting to sound like it might be a good Wiki project. Who knows, maybe the IETF can collaborate to produce some useful IPR that isn't an RFC ;-)? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
China blocking Wired?
According to this article (links to Wired): http://snurl.com/u1gr0 Wired Magazine was or is being blocked by the Chinese national firewall, and they don't know why. Very interesting, from an IETF-hosting perspective. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
On Jan 5, 2010, at 11:47 AM, Richard Shockey wrote: At this point an audio codec is going to have to save a huge amount ot bandwidth to be worth the hassle, let alone the cost of using encumbered technology. Its not about the bandwidth. Its about the quality of the voice in occasionally lossy networks landline or mobile. Also critically, it's about the latency introduced by the coder/ decoder and by any buffering necessary to account for variable latency in the network. Streaming MP3 might sound really good, but it does so at the expense of lots of buffering that compensates for the variable latency of the network and associated TCP transport. Trying to use it for a phone call would not work so well, unless you're used to making phone calls to someplace well outside lunar orbit. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
On Oct 25, 2009, at 10:49 AM, Sabahattin Gucukoglu wrote: Not in the IPv6 address space, anyway. And if it is, there's something wrong and we should put it right. Just been reading IAB's commentary on IPv6 NAT. It seems to me that we are perpetuating the worst technology in existence *simply* for one feature, network mobility, that is better served by proposing new techniques and technologies and, in particular: we need a simple way to express host relationships inside an organisation that is independent of external homing. I refuse to suffer because of NAT any longer and don't want to accommodate those that prefer it. If IPv6 does ever get wide enough deployment, and I truly hope it does, I might just *give up* things to accommodate the trouble-free life that is no NAT. What do we have right now, first? As I understand it, the folks really pushing for IPv6 NAT are from the US department of defense. Let's consider a battlefield operation. We have a hierarchical organizational structure. At any given level, there are a collection of numbered boxes. For example, consider infantry companies, of which there might be 8 or so in an infantry battalion. Company A has a bunch of networked boxes, A1, A2, A3, and so on. Companies B, C, D, and so on have the like. A1 is configured exactly like B1, C1, D1, and so on, with the same IP addresses, passwords, default routes, everything. The inter-layer boxes use NAT to make everything work, even that we have re-used local addresses at every level of the hierarchy. The battalion command post may also have some spare #1 boxes, #2 boxes, etc. Assume artillery falls on the command posts for Company A and Company B and blows up some of their boxes. Recovery may necessitate combining the networked boxes and command structures of both companies. So, while getting shot at, the network techs are busy running boxes back and forth. Let's make a simple case: Boxes A2, A5, and A7 got hit, so they're replaced by B2, B5, and B7. B3 and B4 are also hit, bringing the B network down completely Meanwhile, the battalion guys are shipping out spare #2, #3, #4, #5, and #7 boxes to company B. The B-boxes need to work instantly when plugged-in as replacements for A boxes. There's no time for manual reconfiguration, probably no time for dynamic topology discovery, or anything else. The techs on the ground don't have the passwords, equipment, or know-how to reconfigure the boxes anyhow -- mostly, they just know to plug wire 1-4 into box 1 port 5. And the same goes when the spare boxes from the battalion level arrive at company B -- they have to plug in and work instantly without renumbering anything. NAT is the glue that makes all this work with minimal reconfiguration, and isolates what manual reconfiguration is needed to a specific set of boxes at interconnect points, for which standardized procedures can be developed that allow topology to be reconfigured on demand under very difficult circumstances. Keep in mind that all this stuff also has to be wrapped in military- grade crypto, resist Tempest-style interception, remote radio data insertion attacks, jamming, and sorts of protocol attacks, so brutal simplicity is the by-word of the day. We can't have a network fall apart just because some enemy sapper managed to clamp a rogue Linksys access point with a DHCP server onto a wire somewhere ... So, if IP applications and protocols worked entirely differently, we could get away without NAT in IPv6. We'd kind of hoped that things like Bonjour and multicast service discovery and P2P would have matured fast enough to plug the gap, but so far they haven't been seen as adequate (and I'm not an expert on why not). Plus, the military mindset is understandably reluctant to change things that work. And since NAT made all this stuff work for IPv4, they're planning to use it for IPv6 too. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
On Oct 2, 2009, at 12:27 PM, John C Klensin wrote: ... Perhaps the latter suggests a way for the IAOC to think about this. Assume that, however unlikely it is, the meeting were called off mid-way and that every IETF participant who attended sued the IASA to recover the costs of leaving China earlier than expected, the prorata costs of unexpectedly attending only part of a meeting, and possibly the value of lost time. Suppose the hotel also tried to recover lost revenue and lost reputation costs as some have suggested in this discussion might be possible. Now consider going out and buying insurance against those risks. There are insurance companies who are happy to do that sort of risk assessment and quote prices (and do it professionally, as if their bottom line depends on it, which it does) and with great skill. If the cost of such insurance is a reasonable add-on to the other costs of holding a meeting in Beijing (or can be passed on to the host), then we go ahead with the meeting. If not, we make another plan. That's the best suggestion for managing the risk side of this equation that I've heard. It's brilliant! Great thinking, John! -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, October 2, 2009 3:55 pm, Noel Chiappa wrote: It's not clear that (self-)censorship is going to be the worst problem from an IETF in the PRC. One of the things I would be most concerned about is the PRC government using this meeting for propoganda purposes (either internal, or external), as happened with the Olympics. Yes, we are very small fry indeed compared to the IOC, but I'm not interested in lending the IETF's good name to any government. Let's be real. Were we offended when, during the Adelaide South Australia meeting, the local government made sure the newspapers knew about us and granted Adelaide some prestige for being involved? Nope. The government of South Australia isn't scary and isn't actively involved in censoring, blocking, and obfuscating the Internet. In fact, the local government rep spoke at our plenary, and asked as many of us as possible to consider moving to Adelaide permanently. No worries, mate! Do find the PRC government somewhat more threatening than the government of South Australia? If so, why, and what should we do about it if anything? Constructive engagement and avoidance are both valid options that have been brought into this debate. The current hosting contact terms have led me to favor the latter, but both positions have merit if we can manage the risks. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 28, 2009, at 8:07 PM, Dave CROCKER wrote: Folks, A number of people have indicated that they believe the draft contract language is standard, and required by the government. It occurs to me that we should try to obtain copies of the exact language used for meetings by other groups like ours. If indeed the language is identical, that probably means something useful. If our draft language is different, that also probably means something useful. Does anyone have access to copies of agreements for other meetings? As the IETF's liaison manager to OMA, and a former member of the OMA board of directors, I checked with OMA's management team, providing them the proposed text from our contract. They have held several large meetings as well as smaller interop events in China in the past. Their general manager does not recall having signed anything as unforgiving as the proposed contract, and suggested that we try to negotiate the terms, especially the financial damages clause, and that we attempt to restrict the right to terminate to just the affected session, not the entire multi-working-group IETF meeting. Clearly the government has the power to terminate whatever they want whenever they want, but OMA management seemed to think that the proposed contract was more generous to the venue than government rules might require. OMA management did caution us to be careful about visas and be prepared for some of our attendees to show up with missing or wrong visas and need help at the time of arrival, and that we may have visa difficulty with attendees from Taiwan. They also had some trouble with equipment in customs, including power supplies and WiFi base stations. Apparently some equipment was disassembled by customs inspectors and required in the field repair with solder and scavenged parts, so we should be prepared to re-assemble things that weren't meant to come apart. Their technical support firm is based in France and ended up shipping some equipment in and out via the French embassy due to transport difficulties. OMA management did note that they consider their meetings in China to have been very successful, and that they had and expected no difficulty with their technical discussions falling afoul of local regulations. OMA, as has been previously pointed out, has considered DRM specification a central piece of their specification family in the past, and encountered no difficulties talking about DRM in China. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning afuturemeeting of the IETF
On Sep 28, 2009, at 2:19 AM, Health wrote: I have enjoy many IETF meetings, I have no discussion viloations of Chinese law. I'm tempted to ask Are you sure? Or have they just not arrested you yet? but that would be far too melodramatic, so I'll let it stand without comment. many IETFers from China are from some government related comanies. do you think that Chinese government will allow the chinese participants to join the IETF meeing which often has the violation of Chinese law? That's actually a very good argument in favor of the point that Ole and Marshall have been making; that the PRC government is very aware of what happens at the IETF and isn't worried about anything we're likely to say or do at an IETF meeting. They know us, they've been there with us, and think we're OK. Thank you for bringing it up. One might counterpoint, however, with a quote from Shakespeare: Keep your friends close, and your enemies closer. It's possible that all those IETF attendees from PRC-government affiliated companies have been there to keep an eye on us and to move IETF technology in a direction favorable to the positions of the PRC government. I suspect (I'm always suspicious) or perhaps even expect that both are true. I believe that the top-level government in China is watching the IETF carefully, doesn't expect any major political issues to come out of a meeting in China, and hopes to influence the IETF's work in a direction favorable to its agenda. This is probably true of the national government in any country hosting an IETF, although I expect the PRC is paying closer attention than most. It's also possible, but I think extremely unlikely, that the whole meeting-in-China thing is just an exercise to set somebody up for some sort making of an example. Really, the PRC government has too much at risk for this sort of thing. What I'm most worried about is involvement by overzealous lower-level of government types, or by hotel management that doesn't understand this relationship between IETF and the government, and that such involvement will cause financial hardship to the IETF. I'm also worried about third parties that might use the opportunity presented by the IETF in China to achieve their own political ends. As I've noted, the IETF (and IETFers in general) are pretty naive about this sort of thing. We'd be easy targets. This might be okay, as long as it doesn't generate substantial financial hardship for the IETF. However, the proposed hotel contract still scares me, as it places essentially no limits on the IETF's liability. This is aggravated by the escalation of liability across national legal boundaries. For example, the IETF could potentially be held liable in a US court for damages suffered by US participants if the meeting is cancelled by action under the hotel contract, under the basic idea that signing such a contract (or allowing the host to do so) is an act of gross negligence on the IETF's part. This could mean that not only would the IETF have to pay the hotel contract for the missed meeting and pay the hotel for any future damages resulting from the cancellation, but they might have to refund the meeting fees and travel expenses of every participant. That's potentially a LOT of money, in the tens of millions of dollars, and would probably bankrupt the IETF. So, maybe the PRC government will sign a second contract whereby they agree to indemnify IETF for losses under the terms of the venue contract? That would go a long way towards ameliorating my concern about this meeting location. Censorship, massive national firewalls, route restriction, web site blocking, deep packet inspection with filtering, massive national firewalls, route restriction, web site blocking are technologies, some are also discussed in IETF. Are you absolutely sure that discussing them in China, perhaps in very heated terms loaded with emotional phrasing, is not illegal? I am sure that these technolgy is not only used by China. True. However, it is the PRC government that is most frequently in the news for their use of such obstruction technologies. And we're discussing meeting in China. If we were discussing meeting in Thailand (as proposed by Glen Zorn), I'm sure we'd have an entirely different set of worry items. Certainly we worry about different things when a US site is proposed; namely visa restrictions, border-crossing searches of computers, warrant-less wiretaps, and crypto exports. No location is worry free, and new locations bring new worries that may need to be thoroughly discussed. ... As we have often said, politics influence technology. It is only fair that technology pushes back where necessary to preserve its own integrity. in IETF history, which technolgy is pushed back by Chinse governement? I have seen none. you forget the running code again. I
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 28, 2009, at 8:44 PM, Tim Bray wrote: On Mon, Sep 28, 2009 at 6:07 PM, Dave CROCKER d...@dcrocker.net wrote: A number of people have indicated that they believe the draft contract language is standard, and required by the government. It occurs to me that we should try to obtain copies of the exact language used for meetings by other groups like ours. I think the exact language is entirely irrelevant. This is after all an authoritarian government that historically just doesn't operate in a rules-based manner. The language we've seen is extremely vague. De facto, if a political threat is perceived, a strong unpleasant reaction is to be expected, and lawyers won't be invited to table to construe the finer meanings of the rules. My impression is that it's highly unlikely that the doings of the IETF will be perceived as politically threatening, but if I'm wrong on that, an appeal to section 3.8.7(a) of the agreement is unlikely to be material. However, if consequences of the language spill over into lawsuits in other domains (for example, US attendees suing IETF to recover meeting fees and trip expenses after IETF screws up and gets the meeting canceled), then the exact wording of the agreement may be significant in deciding IETF's liability (unless the US court just says You KNOW they have no rule of law in China, why did you go there?, which I think we can argue against.) . So Dave's suggestion is very good, even if it doesn't help us with the ground truth in China. OMA held a plenary there in 2006, and an interop summit in Beijing also in 2006. I'll make inquiries with them (as the IETF liaison manager to OMA) and see if they have something they can share. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
Olafur Gudmundsson wrote: I propose an experiment, lets have a meeting if it gets shut down we will never return to China. Unfortunately, if my math is right, if the meeting were shut down and the IETF paid out the damages that such a contract would appear to require, we'd be bankrupt and China would be our last meeting ever. Do you really, really want to run this risk? If so, I suggest we go out with a bang by making sure we say some really important things, things worth remembering and telling our grandkids about should we survive to have any. I'd go to that meeting! -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Ole Jacobsen wrote: On Sat, 26 Sep 2009, Dean Willis wrote: Because China's policy on censoring the Internet sucks, and we have a moral and ethical responsibility to make the Internet available despite that policy. If this requires technology changes, then that technology is within our purview. If it requires operational changes, then those operational changes are within our purview. If it requires political changes, then those changes are within our purview. Governments with policies like the PRC's are the enemy, to be defeated by all means technical, operational, and political. This can lead to some heated statements. Dave beat me to it but: We have a moral and ethical responsibility ? Who is we here. Does it include the several hundred folks from China who regularly participate either in our meetings or online? The IETF, ISOC, and supporters thereof bear this responsibility. And yes, our associates from any nation share in this responsibility if they're participating earnestly and honestly in our work. If not, I suggest they leave now. Does the IETF charter require us to do this? Are we supposed to overthrow governments as part of this? If so, do we have a ranked list, or should we just do it alphabetically? The IETF charter says Mission Statement: The mission of the IETF is (sic) make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Government interference of the sort endorsed by the PRC does not make the Internet work better. Its impact is the opposite; it makes the Internet work worse. This requires a technical response from the IETF to counter. Yet these technical discussions are against the law of the PRC because they are in direct opposition to the intent of the PRC's government. Therefore, we should not be meeting there, or if we are meeting there, we should be focusing on the problem at hand, which is driven by PRC policy. Look, I am not in any way trying to defend the policy in question as something I agree with, but I cannot agree that we as a GROUP should be engaged in the politcal actions you suggest. Should we take a stance on universal health care while we're at it? If we were the Universal Health Care Engineering Group, then that would be in our scope. We aren't, and it isn't. So PRC's other human rights violations, whatever they may or may not be (and I enjoy many fine products manufactured by political prisoners putatively subjected to slave labor in the work camps), are completely out of scope for the IETF. However, the relationship of the policies of PRC relative to the workings of the Internet are clearly directly within our scope and mission. ... Regarding agents I have no way of evaluating that possibility and I am not sure anyone can. This is why we asked you. Having some background in direct political action, I can assure you we'd be juicy targets for agents provacateurs. Heck, I'm on the IETF's side, and even I am tempted to take a whack at it since it's such a big, fat, easy, obvious target that would generate relatively high political yields for not all that much effort. We're like a cash-laden pinata hanging from the ceiling over a hockey rink where EVERBODY has a stick. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a futuremeeting of the IETF
On Sep 27, 2009, at 9:17 PM, Health wrote: - Original Message - From: Dean Willis dean.wil...@softarmor.com To: Ole Jacobsen o...@cisco.com Cc: IETF-Discussion list ietf@ietf.org Sent: Monday, September 28, 2009 2:05 AM Subject: Re: Request for community guidance on issue concerning a futuremeeting of the IETF Ole Jacobsen wrote: On Sat, 26 Sep 2009, Dean Willis wrote: Because China's policy on censoring the Internet sucks, and we have a moral and ethical responsibility to make the Internet available despite that policy. If this requires technology changes, then that technology is within our purview. If it requires operational changes, then those operational changes are within our purview. If it requires political changes, then those changes are within our purview. Governments with policies like the PRC's are the enemy, to be defeated by all means technical, operational, and political. This can lead to some heated statements. Dave beat me to it but: We have a moral and ethical responsibility ? Who is we here. Does it include the several hundred folks from China who regularly participate either in our meetings or online? The IETF, ISOC, and supporters thereof bear this responsibility. And yes, our associates from any nation share in this responsibility if they're participating earnestly and honestly in our work. If not, I suggest they leave now. Since IETF includes Chinese, why can you say that if they're participating earnestly and honestly in our work? Our work means your work? The IETF's work is the IETF's work. Some people are working hard to further it. I suspect some people are just there to take notes. I suspect others are there to find pieces of IPR that can be patented, and are patenting it just ahead of our standardization efforts. I suspect others are government agents, some charged with just reporting back, some with influencing technical directions towards national priorities. There are several of those groups that we could probably do without, and the note takers don't worry me much. Why can you say that If not, I suggest they leave now. Chinese contributing to IETF is a power. you want to deprive it? Many of our colleagues from China, just like those from other locations, are hard-working, serious contributors to the IETF. Others, just like from other countries, probably fall into the groups I think we can do without. It is unfortunate that some of those who are contributing to the IETF's work are arguably opposed by governmental priorities in their home countries. They are, I believe, true heroes in every sense of the word. IETF is intending to include every contributor. Exactly. But is it intended to include those who are working within the IETF framework against the IETF's goals? my question is : Who is IETF? you? who gives you the right to do If not, I suggest they leave now.? IETF is of course all of us who contribute to the IETF, and to the Internet Society that sponsors the IETF. As for who gives me the right to say anything, it's called Free Speech. That's something some localities have, and others do not. This is a centerpoint of the discussion we are having about which venues are aligned with the IETF's goals, and which are opposed to it. Many of the conversations we might have at IETF are against the law in some locations, and not against the law in others. Getting clarity on this massive legal complexity and its implications to the IETF is something we need to do before we have an IETF meeting in any location in which we might find ourselves in violation of local laws. Does the IETF charter require us to do this? Are we supposed to overthrow governments as part of this? If so, do we have a ranked list, or should we just do it alphabetically? The IETF charter says Mission Statement: The mission of the IETF is (sic) make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Government interference of the sort endorsed by the PRC does not make the Internet work better. Its impact is the opposite; it makes the Internet work worse. how do you know that? how do you prove that? Censorship, massive national firewalls, route restriction, web site blocking, deep packet inspection with filtering, arrest and prosecution of people who use the Internet for political speech, capricious policy changes, Green Dam Youth Escort and other politically-driven challenges to the function of the Internet are quite obviously NOT making the Internet work better. Unless of course you see them as valuable evolutionary pressures that force us to make the Internet better in order to make these sorts of governmentally- sponsored denial of service attacks less and less effective. If you take the latter view, then learning to defeat them is obviously within the scope
Re: Request for community guidance on issue concerning a future meeting of the IETF
Ole Jacobsen wrote: On Wed, 23 Sep 2009, Eric Rescorla wrote: So, this isn't really that useful context for the rest of the paragraph. To take the example of encryption, I think people were arguing that it was a topic regarding human rights. With that said, it's not clear to me that saying China's policy of censoring the Internet sucks isn't defamation. I would say that this DOES border on defamation, BUT I am at a loss to understand why such a statement would be a required part of our technical discussion. The statement is an opinion about a topic which there is a lot more that can be said, but like the baby said this isn't the venue. (Let's just say that it isn't well understood in the west). X policy sucks sound like politics and not technology particularly if X is a country. Because China's policy on censoring the Internet sucks, and we have a moral and ethical responsibility to make the Internet available despite that policy. If this requires technology changes, then that technology is within our purview. If it requires operational changes, then those operational changes are within our purview. If it requires political changes, then those changes are within our purview. Governments with policies like the PRC's are the enemy, to be defeated by all means technical, operational, and political. This can lead to some heated statements. The question: does meeting in China do more to further the goal of getting past PRC (and others) deplorable policies than does meeting elsewhere AND LETTING THE WORLD KNOW WHY WE ARE NOT MEETING IN CHINA. That's an open question, I'm not at all certain of the answer, and we have to analyze financial risk of that hotel contract given the situation. We also have to analyze the financial risk with regard to agents who may try to turn an IETF meeting into a political incident. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
On Sep 22, 2009, at 1:10 PM, Adam Roach wrote: On 9/18/09 14:02, Sep 18, Paul Wouters wrote: Pre-emptively excluding countries based on culture, (perceived) bias, or other non-technical and non-organisation arguments is wrong. So if the visa issues are not much worse then for other countries, and an internet connection not hampered by a Great Firewall, I see no reason to single out China. The majority of the conversation so far has related to a clause that we will be forced to accept as a condition of meeting in China. It is not directly related to their culture or (perceived) bias. The conversation would be equally valid (and probably contain many of the same arguments) if we were being asked to make a substantially similar agreement to meet in, say, Ireland. Should the contents of the Group's activities, visual or audio presentations at the conference, or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the Republic of Ireland, or show any disrespect to Irish culture, or violate any laws of the Republic of Ireland or feature any topics regarding human rights or religion without prior approval from the Government of the Republic of Ireland, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. Could you imagine the uproar? Would it be anti-Irish sentiment? Or would it be objecting to an unacceptable policy? We'd say our hosts had been drinking a little too much fine Irish whiskey and either ignore it or just mark it out and send it back. There's no way we'd sign that. It's a human right to argue about human rights! Of course, if one were to defame Ireland in a downtown Dublin pub, one might expect to be asked to step outside, or just get punched in the nose on the spot. After all, being offensive is its own reward. But one still wouldn't expect to see this type of ballast added to a hospitality contract. Why? Because in the free world, defaming the government, disrespecting a culture, discussing human rights, and discussing religion might be rude, or they might be the subjects of perfectly appropriate academic discussions, but they are not illegal. And there's no way we should be holding an IETF meeting in any location where such discourse is illegal. It's against everything we have fought for with the Internet for many, many years. Ole says: I'm sure that's great advise from the lawyers, but you don't typically get to negotiate clauses that are required by national law. We'd obviously love to have it removed or reworded since this would remove any (some?) concern, but as Ray says, it's the law. If you don't like the law, don't enter its jurisdiction. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
On Sep 22, 2009, at 7:03 PM, Ole Jacobsen wrote: You said: Because in the free world, defaming the government, disrespecting a culture, discussing human rights, and discussing religion might be rude, or they might be the subjects of perfectly appropriate academic discussions, but they are not illegal. I agree, but I think you are arguing that such discussions are a normal and required part of our technical work in semi-public fora and I think that's stretching the meaning of the terms you list. Aren't they? I've certainly found discussions on thwarting the government's will to be a central part of a great many security- oriented discussions at IETF. Specifically, we're been concerned with the individuals human rights with respect to security of communications and privacy. We've refused government mandates to require cryptographic back doors time and again. Doesn't IETF regularly host PGP key-signing events in furtherance of this ideology? As for what constitutes defaming a government or disrespecting a culture, who knows what that really means? I assume the conference hotel knows, since they're the ones with the job of deciding and the power to enforce the contract. We know that in Thailand, insulting the King can get you 75 years in jail, and we also know that the King is apparently a lot easier to insult than most Western leaders (or really, that the King himself seems like a pretty reasonable guy, but that lower-echelon folks are easily insulted on his behalf). http://en.wikinews.org/wiki/Thailand_bans_YouTube_over_videos_insulting_king http://www.boston.com/news/world/asia/articles/2009/08/29/activist_gets_prison_sentence_for_insulting_thai_king/ http://www.nytimes.com/2009/01/20/world/asia/20thai.html Now admittedly, PRC is not Thailand. But mysterious phrases in contracts referring to poorly understood crimes and imposing draconian penalties without any kind of review mechanism are still going to worry people. And I think they're right to be worried. If it's a non-issue, why does the hotel contract cede all rights for determining legality or offense to the hotel, and leave us holding nothing but the liability? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
On Sep 22, 2009, at 10:14 PM, Peter Saint-Andre wrote: Disruptive as defined by whom? It seems to me that the contract we might sign cedes the definition of disruptive to a government about whose laws we know very little. Do correct me if I'm wrong, but as far as I know the IETF has never before signed a contract that lets the government of the host country define what is and is not an allowable topic for discussion. No, it cedes the definition to a hotel who might know less about the local law than we do. It's not the big boss that's likely to take offense at IETF; it's the piranha a little lower on the food chain who thinks he has something to prove that is dangerous, or the even-lower ranked person who is just afraid of what the superiors might think and therefore over-reacts. I'd be much less worried if the Ministry of State Security were running the whole show directly and overtly, including providing escorts for every bar-bof and going-to-dinner group, like they did in the bad old days. Although the undertone I'm getting from people who have talked to the organizers seems to hint that MOSS is already actively engaged in the IETF event planning, which is probably a good thing as it means a lot fewer headaches. Perhaps we could get the contract amended so that we'd have a designated government office or official making the pull-the-plug decision instead of of hotel bell-hops, house security, bar managers, housekeepers, or whatever? To my mind, that would lower the perception of financial risk we're taking on. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 20, 2009, at 12:41 PM, Ole Jacobsen wrote: Please try to keep in mind that (various organizations in) China has been wanting to host an IETF meeting since 1997. One organization has finally been given government approval to do so. This is a Big Deal for them. Do you really think the Chinese government is looking for an excuse to make an example of a bunch of geeks meeting in a hotel and embarrass the local host in the process? I don't think so. No, the PRC government at the top level is not trying to make an example of the IETF. They're probably trying very hard to get the IETF to engage with them. But there a re a lot of people in the world who will be looking for ways to make the PRC government over-react against the IETF, resulting in an international incident that is embarrassing or otherwise damaging to the PRC. IETF is a much more visible target than other SDOs that might meet in China (including 3GPP2 and OMA that I have had experience with). Further, it might be easier to trigger a governmental reaction against IETF than those other bodies due to the politically sensitive nature of some of our work. After all, we're the people who made things happen so that Taiwan would have its own country code in the DNS. http://en.wikipedia.org/wiki/Country_code_top-level_domain And there are politcal immune cells that operate at a level below that of the top-level government people that made the decision to allow the IETF. It's hard to say what sort of actions might cause them to activate against us or our people. Another way to ask this question: Are our members who are Falun Gong practitioners going to be persecuted for their beliefs while attending IETF? Are our members who are active in Tibetan or Taiwanese independence movements going to be quietly picked up off the street outside our venue? Are our members who run large-scale porn web sites going to be hassled? Will the IETF be held financially liable for their legal defense? If so, would it not behoove said movements to orchestrate a few arrests in order to gain international attention and force the IETF to financial and politically engage on behalf of the movements? This seems like a golden opportunity for publicity, and I'd bet every dissident with half a clue is currently thinking very hard about how to maximize the opportunity. If they can make it happen by leaking something into the ear of a suspected snitch, they will. If they can make it happen by setting up a WG conversation around a risky topic, they will. If they can make it happen by having someone pretending to be a senior party member threaten the hotel manager, causing the hotel manager to close a working group meeting, they will. If they can make it happen by triggering the political immune system (which they understand far better than we do) in any way, they will. Do we have a large political bullseye painted on our foreheads? Yes, we do. Should we let that stop us from meeting in China? That's the open question. There are risks, we need to understand those risks, and then we can decide whether or not we want to go down that path. We should perhaps note that at least one SIP interoperability event (SIPit 21) was held in China. The hospitality was reported as excellent, no real political problems were reported, and the event was generally considered quite successful. I seem to recall that they did have an issue with network connectivity. However, this is a very small group, and much less attractive as a political target than a meeting of the full IETF would be. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 18, 2009, at 11:24 AM, Ben Campbell wrote: Finally, do you think that, in this group of people, there won't be at least one who cannot resist stating their opinions about some political hot button? Or for that matter, figure out they can DoS the entire IETF by throwing up a controversial slide. Obviously there's some wiggle-room in the within the control of the client clause--but that's the sort of thing that gets worked out in courts later. It's not very helpful when the on-site authorities have already pulled the plug, and I don't expect them to be sympathetic to the idea that the IETF cannot control the behavior of it's participants. You are absolutely right. I might find a little political speech tempting, and can assure you that there would be a number of other people with pithy political comments to make. Perhaps something like Free Tibet and Taiwan, Celebrate Falan Gong, Porn is a Human Right, as a footer on every slide? After all, we have no rules about political speech. If the IETF tried to move to suppress such discourse, we could well be sued back in the States. I can certainly imagine people with agendae using this as an opportunity to score massive publicity by getting the IETF shut down or even better arranging for mass arrests and/or related civil disobedience on a large scale. It might even be a good thing, but it would be better if we weren't caught in the middle of it. Or maybe I'm wrong; perhaps the best service we can give the world is to be made examples of in China. There are other risks as well. It wasn't too long ago that the Mexican government had to send a plane to retrieve many of the Mexican citizens in the country, after PRC health authorities decided to put them all into a rather primitive extended quarantine (read concentration/death camp). Given the IETF's penchant for outbreaks of respiratory diseases (the IETF cold/flu that frequently gets around), I'd not like to have that happen to us. I was doing standards work and we were scheduled to meet in Guangdong during the SARS outbreak, and remember television scenes of hospitals fenced in with barbed wire, with the afflicted being fork-lifted over the fence to die, as all supplies in the hospitals had supposedly been exhausted and water and electricity cut off to prevent spread. Not that any country would do all that well in such a situation, but the People's Republic of China has a proven track record of being rather scary, at least from a western point of view. See: http://news.bbc.co.uk/2/hi/americas/8033089.stm http://online.wsj.com/article/SB124137876507580987.html http://www.salisburypost.com/Lifestyle/082109-quarantined-in-china So all in all, I'd say I'm not comfortable with the idea of an IETF meeting in the PRC at this time. Maybe, in a few years, if they open up their Internet and cut back on the human rights abuses associated with the users of our technology (making bloggers disappear is just NOT acceptable), then we'll be ready to meet there. But not now, not yet. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On Sep 17, 2009, at 8:29 AM, Steve Crocker wrote: There are hundreds of millions of IPv4 computers and perhaps millions of individual IPv4 transport networks, large and small. Here are some useful points along the way from pure IPv4 to pure IPv6. A. Every new computer is able to talk IPv6 B. Every transport is able to talk IPv6, i.e. every network from tier 1 ISPs down through wifi hot spots and every internal corporate network C. Every major service, e.g. Google, CNN, Amazon, is reachable via IPv6 D. Every new computer is not able to talk IPv4 E. A substantial number of transports are unable to talk IPv4 F. A substantial number of major services are not directly accessible via IPv4 (but, of course, will be accessible via gateways) You've missed a couple of key points: * IETF declares IPv4 historical * IETF declares IPv6 a full standard * IETF further reduces focus on IPv4 in new protocol work (perhaps addressing it only through gateways?) * IETF stops referencing IPv4 in new protocol work * ... and probably a few more along these lines These can arguably be done in several orders, and there's an open question as to how they interleave with your points. Remember that the IETF cannot directly influence your checkpoints. The only ones we can really control are the ones that determine how the IETF behaves. To paraphrase my friend who is a psychotherapist: We can't control how the world feels about IPv6. At best, we can control how we feel about it. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
On Sep 13, 2009, at 11:22 PM, Ole Jacobsen wrote: How is any of this relevant to an EXPERIMENT ??? A maxim about experimentation: If the design of and data resulting from any experiment are made available, people may use these results to test hypotheses that were not necessarily envisioned by the experiment designers. In other words, people are likely to do things with the result of the experiment that we don't necessarily have in mind. This is a given, and is not necessarily a bad thing. Indeed, it is how a great many discoveries are made. But the experimenters (and/or their sponsors) are not without liability in today's unfortunately litigious world. By making the results available, we have made some level of express or implied warranty about those results. There may also be some liability toward the experimental subjects (those of us with RFID tags, or those of us interacting with tagged persons). For example, people might use the experimental results in prosecution of patent lawsuits. If there are errors in the data, or if it can be argued that there were flaws in the experiment that were not disclosed to the users of the data, we could potentially be liable for damages. So any collection, retention, and/or release of data has to be protected by explicit disclosure of policy and known limitation. The implicit warranty has to be made explicit, and in our case it most likely had better explicitly say that we're not making any assertions about the validity of the data, the collection method, the names or locations of the participants, or anything else. We should probably also document the data retention policy, which in this case is probably We may dispose of these data at any time and are not obligated to preserve or retain them or to make them available at any future date. Further, we may wish to release the data with some sort of explicit licensing terms that include this explicit non-warranty of the experiment's validity. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
On Sep 14, 2009, at 12:41 PM, Ole Jacobsen wrote: It means that the data will be deleted at the end of the expiriment once the analysis is done. Educated guess: within 30 days of the end of the meeting, I know how busy the folkds running the meeting are. The bluesheets, on the other hand, are retained. There is no need to retain this data once summaries and comparisons are done. That's a reasonably good statement of the retention policy. For today's news about the unintended consequences of the release of experimental data, I refer you to: http://www.foxnews.com/story/0,2933,549941,00.html?loomia_ow=t0:s0:a16:g2:r2:c0.083617:b27702080:z0 In short, 35 year old research maps relating to possible Hawaiian lava flows are being used to deny insurance coverage to homeowners, even though this isn't what the maps were intended for and despite the maps having been declared as hopelessly out-of-date by their producer. You see, the maps are effectively in the public domain. Their use, retention policy, and level of validity were not clearly described in the licensing terms given by the map makers. So the only thing anybody can do about it is make newer, better, maps, which both the homeowners and insurance companies are likely to fight because it would affect somebody's costs or profits. All politics are economical, and all science is political. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
On Sep 12, 2009, at 2:31 PM, Doug Ewell wrote: Ole Jacobsen ole at cisco dot com wrote: I am also not sure what value there is in knowing that 3478273983421 spent 10 minutes in trill and then moved on to behave (pun intended). To amplify, I'm not sure why the security risks of being tracked while attending these meetings are considered so much greater than the risks of posting messages on mailing lists, signed with one's real name, and having those messages archived for years on publicly accessible Web sites. Well, I for one don't want people to know that I'm actually showing up for the first ten minutes of each meeting I chair, replacing myself with an inflatable dummy, and then going off to the bar. It would be revealing that I'm too stupid to remove my RFID tag and attach it to the dummy, and that would be a blow to my professional credibility. Seriously, it does have major implications for intellectual property lawsuits. Let's say JoeBob attends a meeting of the FRILL working group, then goes home to patent a nifty new innovation in FRILL, which is then bought for $1 by a patent troll when JoeBob's company goes broke because his board of directors blew their investment capital on stocking their break room with headcheese. Said patent troll then sues some defendant, whose legal team later notices that said FRILL- enhancement had been discussed at IETF 211 while JoeBob, the inventor, was in the room, thereby invalidating the patent (and making JoeBob look like a doofus). Okay, so that's not an example with too many negatives, unless JoeBob decides to sue us for making him look like a doofus. Now let's presume that some people remember (and that some other people don't remember) JoeBob being in the room during the discussion, but IETFs RFID tracker log shows that JoeBob was hanging out with me in the bar. Does IETF's failure to maintain the record that invalidates the patent make us liable to the defendant? Or worse yet, IETF can't produce the RFID logs in response to a court order, because somebody goofed and deleted them. Was this a conspiracy to protect the patent troll? Who got bribed to make it happen? How many hundreds of thousands of euros we would like to spend on the paperwork related to the various discovery motions we might have to endure? In other words, any retained information increases liability, both for the accuracy of the retained information and for the preservation of the retained information. That's why we must both have a policy about how that information is obtained and preserved, and we must live up to that policy, whatever it says. Of course, the easiest policy is to retain no information. But even that has its consequences. For example, is deliberate ignorance consistent with industry best-practices? How does this interact with the Sarbanes-Oxley requirements of our sponsors? And why would a startup company stock its break room with headcheese anyhow? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On Sep 11, 2009, at 10:24 AM, Iljitsch van Beijnum wrote: Hi, It occurs to me that a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard. But it's not obsolete yet. How can we possibly make something that isn't already obsolete a full standard? Perhaps we should introduce IPv8 as work in progress, declare IPv6 to be the current obsolete standard, deprecate IPv4, and stop referencing IPv4 completely in any new work? We could even require considerations for IPv8 sections in all standards-track drafts, as we know that such a requirement causes forward-thinking in the writing of the draft. -- dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hiroshima room rates (was Re: Non-smoking rooms at the Hiroshima venue?)
On Sep 4, 2009, at 7:47 AM, Andrew Sullivan wrote: On Fri, Sep 04, 2009 at 07:43:15AM -0400, Lou Berger wrote: Yes. I checked Sept 14-18. Try it yourself, I expect you'll get the same results... I don't understand why the rate during another period is relevant to the rate we might get. Remember that hotels, like everyone else, charge more when demand is higher. It's a fair guide as to whether or not the hotel (perhaps with the collusion of the meeting organizers) is putting the thumbscrews to us. For example, if the IETF attendee room rate is higher than the average rate for the hotel, we might be getting taking advantage of. If it's higher than the recorded maximum general-availability rate, then we almost definitely have a problem. If the IETF attendee rate is higher than the general-availability rate for the same time period, then we're absolutely positively being abused. I don't know about you, but when I book a thousand rooms from a hotel (giving them a million dollars revenue), plus spend a half-million dollars or more on meeting rooms over a week, I expect the hotel to be fairly generous about guest rooms. And when I've paid $700 or so for a meeting fee, I don't expect the organizer to pad their budget by having the hotel overcharge me on those rooms. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Censorship and control of the Internet
Phillip Hallam-Baker wrote: From time to time, people in this forum make statements of the form 'we cannot do X because it would enable censorship' and go on to describe a use case that really has no connection to how the Internet is used against repressive regimes. At the same time, we have the Green Dam experiment launching in China: http://www.reuters.com/article/technologyNews/idUSTRE55L0YD20090622 However, we are still letting people with the backing of the Chinese government participate in the development and oversight of Internet protocols. While I wish to cast no aspersions against any particular contributor who just happens to be from the nation in question, there's definitely a potential conflict of interest. It's hard to say no when your government demands support. The history of US telcos assisting with illegal interception (and no, the US government can't retroactively legalize it with an ex-post-facto law no matter what the court says) should prove this assertion. While other governments have their own forms of Internet oppression, probably their own technical agendae, and may well subsidize IETF participants towards questionable ends, Green Dam is a particularly horrifying spectacle. It therefore serves as a reference example for bringing this particular conflict of interest up for examination. Green Dam also serves as a reminder: even end-to-end security isn't good enough when the attacker can mandate an integrity compromize in at least one end. Further, I worry that with the economic decline, only people backed by the financial reserves of oppressive governments will be able to participate in the IETF at the level required for non-com, IESG, etc. It would be a great disappointment to cede control of the Internet to the world's tyrants just because they're the only ones who can be bothered to show up at meetings. Perhaps there is a principle here that should be coded into noncom procedures, althoug I'm not sure how to state it explicitly. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07
On Jun 4, 2009, at 9:24 AM, Cullen Jennings wrote: Thanks for review ... just wanted to respond to one point in this. On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote: C5. User Identity Protection: The location URI MUST NOT contain information that identifies the user or device. Examples include phone extensions, badge numbers, first or last names. Spencer (minor): this is probably a good idea, but I'm not sure it's a 2119 MUST (NOT). How would you recognize this on the wire (do you know what MY badge number is :-)? There is the age old discussion about what 2119 means in a requirement document, but I'm trying to ignore that and just go with how well this conveys the intent of the WG to future readers. I agree we could not really black box test this but I think it does get to the essence of what the requirement is. Even last names might be hard to tell they are a last name, I hear rumor that google thinks Tschofenig is a strong password though I note is is a very common word to find in internet drafts :-) Anyways, I can't think of a better way to write this requirement so unless someone has a concrete proposal, I suspect I will just leave as is. Say WHY it MUST NOT. All 2119 language needs explanation; you MUST NOT include identifying information because if you do, that information will be revealed to attackers, who may exercise it in attacks. Such attacks include but are not limited to social engineering, impersonation, stalking, extortion, and pretending to be an Area Director . . . In other words, when you use 2119 language to explain a requirement, explain the rationale for that requirement; in particular explain what happens (or becomes possible) if the requirement is violated. Unsubstantiated dogma is doggerel. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78 Annoucement
On May 25, 2009, at 4:09 PM, Iljitsch van Beijnum wrote: The Hague, largest room: 2161 (30 min by train from Schiphol + tram or taxi) http://www.worldforumcc.com/wfcc/uk/factsfigures_uk/capaciteitenov_uk.html The Hague is easy to get to. I attended an ISOC meeting there last fall, and the location met all my success criteria. It has excellent support infrastructure, good airport accessibility (an airport shuttle train that is basically door to door) and easy walkability. There is a vast variety of housing. Crime is trivial, the locals are friendly and used to weirdo foreigners, and the beer reasonably priced. While Maastricht may offer some of those optimizations, it's much easier to reach The Hague: any basically unskilled traveller can probably succeed by accident; stumble out of the airport and onto a random train, and you have a 50% chance of being on the right one even if you can't translate the large sign saying Den Haag. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Native-SIP vs. Non-native SIP
Stella Gnepp wrote: Specifically, I am trying to determine whether a call is still considered native-SIP if a call originates as TDM, but is converted from TDM to data before leaving the customer's premises. I am hoping that there is a standard definition that states the point of origination (whether it is at the point of where the call leaves the customer premises, or before then-at the equipment level) for determining whether a call is native-SIP. To the best of my knowledge, IETF documents do not make a distinction between native and non-native modalities as you describe them. On my desk here, I have a Linksys terminal adapter with an analog phone plugged into it. Is that native SIP or not? To a third party observer, there is no apparent difference between this arrangement and a nearby Linksys SIP phone. So at this level, I'd argue that the distinction between native and non-native has no useful meaning. However, IETF does talk about the PSTN-anchored identity problem. For example, if a call originates in TDM space and uses a PSTN telephone number as its source identifier, can we really trust that identifier for use in an RFC 4474 Identity header? Caller-ID is notoriously easy to spoof. In the case you outline above, the customer premises may provide an RFC 4474 authentication server that signs the call after it is converted from TDM to SIP. It's up to them to decide whether they trust their TDM infrastructure well enough to assert strong identity on calls coming from TDM. In my Linksys case, since I know the physical arrangement between my phone handset and my Linksys ATA (I can see the whole cable from here) and believe it to be secure, it would be reasonable for me to assert identity based on the Linksys ATA. If it supported the behavior,m it could act as an RFC 4474 authentication service, or it could use digest authentication to prove identity to an upstream proxy which could in turn add an RFC 4474 Identity header. But if I were to provide a dial-in phone line to that Linksys ATA and configure it as a gateway, there's no good way to support RFC 4474. Certainly the identity of the gateway could be expressed, but we don't have a way to authnticate the calling party on the originating end of the PSTN connection other than caller-ID, and we know that's too weak to rely on. So I think that the problem you're attempting to describe as native and non-native SIP is better expressed in terms of whether or not the originating party can be strongly authenticated. We know this is a problem for PSTN cases, and we don't have a good general answer. -- Dean Willis former SIP WG chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
On Apr 21, 2009, at 2:04 PM, Melinda Shore wrote: You can call it foo for all I care, but much of what's been discussed so far is policy. From the proposed charter: A host connected to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. That's all policy. My shaman once said For God, everything is just a question of policy. But, we need to reduce this problem to a more mortal scope, and I'm not quite certain that the proposed charter text accomplishes this goal. There's a tremendous amount of complexity inherent in the problem. I suspect as worded that it is roughly isomorphic to the peering problem, with all the business-driven policy consideration that entails. Consider that peering policy is often driven by things that are well beyond the scope of protocol. Its potential range of expression is unlimited; in fact driven by a natural-language contract and heuristic operations on underspecified constraints derived from that natural- language contract. The only alternative I can see here is to try and reduce the range of expression. One such approach might be to develop a policy language having the property of an algebra, so that policies can be written and interpreted in a defined manner, and so that the combinations and interactions of multiple policies can be evaluated and applied predictably in automata and simulation. This requires a substantial body of precursor work: What things should the language be able to express? What combinatorial operations are required? What are the relative priorities of linguistic statements? What sorts of fundamental things should the policy describe (we have things like route selection, prefix manipulation, addressing, access rules, name services, name defaults, and so on to consider as options). Even with this sort of model, I am not confident at our ability to achieve success, at least without even more substantive reductions in the scope of the effort. Can we narrow it down some more? -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Does being an RFC mean anything?
On Mar 11, 2009, at 2:22 PM, Lawrence Rosen wrote: The recent threads about draft-housley-tls-authz have taught me something I didn't know about IETF, and I don't like what I've learned. 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. The world is now full of standards organizations that treat their works as more significant than merely technical information. Why do we need IETF for that purpose? If all we need is a repository of technical information, let's just ask Google and Yahoo to build it for us. Maybe our Internet standards should instead be created in an organized body that pays serious attention to the ability of the wide world to implement those standards without patent encumbrances. But even if IETF isn't willing to amend its patent policy that far— and most SDOs still aren't, unfortunately—at the very least we should take our work seriously. When someone proposes a serious RFC, we should demand that the water around that RFC be swept for mines— especially *disclosed* patent mines that any serious sailor would want to understand first. If IETF isn't willing to be that serious, maybe we should recommend that our work go to standards organizations that do care? As far as my time to volunteer for a better Internet, there are far better ways to do it than listening here to proposals that are merely technical information. At the very least, separate that into a different list than IETF.org so I know what to ignore! By the way, many of the same companies and individuals who are involved here in IETF are also active participants in W3C, OASIS, and the new Open Web Foundation, all of which organizations pay more attention to patents and the concept of open standards than what IETF seems to be doing here. So let's not be disingenuous, please. Almost everyone here has previous experience doing this the right way. I work in VoIP. My current day job is consulting on IPR, primarily on patent litigation defense. There are tens of thousands of patents in this area in the US alone. I can think of few things I've seen in the last few years that aren't covered by some kind of patent when they are brought into IETF, and most of those acquire some kind of patent not long after. Many of the things I've seen I can't discuss for NDA reasons, but I can say that I accidentally found one patent that might possibly apply to an RFC I edited, for which I submitted a 3rd party IPR disclosure to test the process. Even if we applied the entire administrative capacity of the IETF to filing and processing IPR disclosures, we couldn't possibly keep up with the applicable US patents applying to VoIP, much less the tens of thousands of patents on other protocols and in other jurisdictions. I haven't looked, but I'm willing to bet that the same reality applies to every other SDO. So get real. The ONLY thing that an SDO's IPR disclosure process helps with is the submarine patent held by an active participant in the SDO -- and look where that got us with FTC vs. Rambus in the long run. To the extent that the SDO disclosure policies apply, they apply equally to Standard, Informational, Experimental, and even Historical track RFCs. That's it -- if an IETF participant fails to disclose, they run risk of litigation around applying a patent against a standard, and the outcome is not a sure thing. This is especially poignant in that the IETF does not have corporate membership. Rather, it has voluntary individual participation. So for example, if Employee A (who does not participate in the IETF) at company X files an patent on Idea #12 but doesn't tell Employee B (who works on Idea #12 in the IETF), then it's arguable that Company X has no disclosure liability here. For example, in the case I mentioned above where I filed the 3rd party notice, none of the participants from the IPR-owning company that I spoke to had been previously aware of the IPRs existence. Some attorney back in the home-country filed it based on a disclosure from somebody who probably wasn't even aware there was a need for a standard related to the idea. Now, if you want to lobby for requiring corporate membership in IETF, feel free, but prepare for the throwing of a lot of stones. In the meantime, get over it. Trying to require IETF to do a patent search on every aspect of every RFC would just shut the organization down. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
On Mar 4, 2009, at 3:43 AM, Dearlove, Christopher (UK) wrote: Putting aside whether I could buy such a machine, and assuming taking it out of the US would be OK policy-wise (that I'd have to check, I suspect it's within the letter but not the spirit of the policy) as soon as it's outside the US it's a company machine I couldn't take back in. Puchasing a laptop per trip is not very economic. Although many consider the UK to be verging on a socialist state (don't worry, the US is gaining on you), I wasn't aware that simply arriving in the country with personal property automatically assigned such personal property to one's employer. That's pretty scary! Is this a big enough problem to justify setting up a Netbook Rental Desk near IETF checkin? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
On Mar 2, 2009, at 12:51 PM, Samuel Weiler wrote: Also consider used laptops: I just picked up a used Dell Latitude for about the same price as a netbook (and half the price of IETF registration), and I'm delighted. Given that sometimes the border goons use some aggressive data recovery approaches, used laptops are somewhat interesting. Are you SURE that some erased sector doesn't contain a vestigial image of something embarassing? If it does, can you prove it wasn't you that left it there? Note that some of the secure facilities I've worked in dispose of used drives by software erasing, beating them with a sledgehammer, degaussing, baking in a ceramics kiln, degaussing again, and then beating with a sledgehammer again. Worried about what might be recoverable from those drives? -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
On Mar 2, 2009, at 1:52 PM, Joel Jaeggli wrote: Dearlove, Christopher (UK) wrote: But now, if I come to IETF74, I won't have a laptop with me. Corporate policy, based on recent US legal decisions, is that I may not take a laptop (or PDA etc.) into the USA. This is not subject to modification. Obviously even a machine in the terminal room would be a very poor second, but it seems even that is out. I don't know about you but I wouldn't trust a public terminal no matter how well maintained for the applications which I carry a laptop. Depending on your bent, either a personal laptop (with no corporate data on it) or a mobile phone with the appropriate email conduit but no pre-existing configuration might be a more desirable (and secure) way to go. The worry is not that the border goons will expose confidential information on one's device, but that they'll CLAIM they did (even if they have to insert it themselves), and there's no way to disprove this when the device is writable. Hence the need to carry no writable devices across the border, not even a USB memory stick or a camera. Or a modern cellphone, for that matter. Of course, that doesn't keep them from claiming that you had a writable device in your possession, then planting one there. Given sufficient paranoia in one's threat model, there's just no way to justify waking up in the morning. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
On Jan 21, 2009, at 12:16 PM, Bob Braden wrote: At 11:58 PM 1/20/2009, Dean Willis wrote: Given that we've historically weeded out the contributor-list on a document to four or less, even if there were really dozens of contributors at the alleged insistence of the RFC Editor, I don't see how any older document or even a majority of new documents-in- progress could be adapted to the new rules. Whoa! This contains several errors of fact and implication. The number authors named on the front page of an RFC are generally limited to 5 (there are occasional exceptions for good cause). This rule was arrived at after discussions in the IETF and it has enjoyed general community support; it was not at the insistence of the RFC Editor. The RFC Editor 's role was to alert the community to a tendency towards ballooning of author lists when every telecomm vendor wanted their name on the RFC, and perhaps it is true that the magic number 5 (which could have been 4 or 6 or ) was chosen and documented by the RFC Editor. Otherwise, it was a community consensus. At the time that the 5 limit was put in place, a new Contributors section was added to RFCs to contain the overflow authors/contributors. Yes, 5 is the number I should have said, and I'll accept your description of the history involved. Note my use of the term alleged in ascribing the origin to RFCEd; it is what I recall my AD telling me at the time. As the judge might say, this is hearsay, and inadmissible in court ;-). It is my personal opinion, based on this history, that for IPR purposes we ought to treat those listed in the Contributors sections as having equal copyrights to those named on the front page. (Maybe the Contributors section ought to come early in the RFC, rather than late. but that would be another discussion.) OTOH, the RFC Editor recoils from the idea that those in the Contributors section should logically be included in the AUTH48 process; let's not!. I concur that Contributors need to be considered from a copyright/IPR perspective. The problem is that every RFC I'm aware of that was produced by a working contains tens to hundreds of contributions made either on- list, off-list (direct to an editor, or indirectly through another contributor and onto an editor) or made verbally, possibly at a microphone, possibly in a hallway discussion, or possibly at a meeting of an entirely different SDO, such as 3GPP or OMA, and relayed directly or indirectly into IETF. We don't track these in the Author's section, and generally only the most vigorous of such contributors are noted as Contributors in common practice. We might have to change this, and Theo has outlined one procedure for doing so using source-control, although we'd need to extend this to cover the additional contribution channels (which could be really hard). While NEW contributions brought into IETF might ostensibly be covered by our Note Well, it seems that this would NOT apply to any document currently in-progress, or any document derived from a pre-5378 document. Consequently, the only way to develop a document that I could sign off as being RFC 5378 compliant in the fullest sense would be clean-room development; that is, it would have to be started post-5378, copy no text from pre-5378 documents (or external specifications), and have the provenance of every contribution to the document carefully recorded for the purpose of tracking the assignment and assignability of rights related to that contribution. Even then, it could get foiled by somebody accidentally including a blurb overheard at a 3GPP meeting; while this might protect the IETF's liability, it could still taint the document. Of course, that's nothing new, and we've lived with that aspect so far. Otherwise said, since we don't have a record of the contributions made to pre-5378 documents, we can never be sure that the rights necessary to publish the document with a full assignment-of-rights ala RFC 5378 have actually been granted. At best, we can assume that the untracked contributions were made under the IPR terms of the time, which obviously have a lesser scope than RFC 5378. So the only thing we can do with any documents that were discussed on-list, a a meeting, or otherwise contain pre-5378 contributions is to publish them with a restricted rights statement. Caveat: I'm not a lawyer. I professionally consult to lawyers about technical aspects of intellectual property, and this whole thing makes my head throb worse than tensor calculus. I hope I'm completely wrong about everything I think I understand. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your comments on revised proposed legend text to work-around the Pre-5378 Problem
On Jan 23, 2009, at 11:13 AM, Paul Hoffman wrote: Given the wide nature of what is a contributor, I would think that *any* cautious document editor would want this boilerplate in their document for *any* effort that has any contributions that might have been made before 2008-11-10. Is the Trust OK with this being in essentially every single IETF document for many years to come? That's exactly the point I was trying to make in the post that Bob responded to; every document that was in-process prior to 5378 is going to have to carry this We don't know boilerplate. I'm OK with that, and think that the revised working looks to be acceptable, although John's argument about the strength of assertion seems reasonable ( We can't say you can copy it is more realistic than You cannot copy it). -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your comments on ...
On Jan 24, 2009, at 12:11 PM, Paul Hoffman wrote: At 10:39 AM -0700 1/24/09, Doug Ewell wrote: John Levine johnl at iecc dot com wrote: Nonetheless, I can't help but seeing angels dancing on pins here. We're worrying about situations in which someone contributes material to the IETF that ended up in an RFC, then later goes to court and claims to be shocked and injured that someone else used his material in ways that RFCs are routinely used, i.e., someone acts like a complete jerk. It could happen. Remember that some people who participate in a WG, and contribute one or two bits of information that make their way into the RFC, are unhappy overall with that group's rough consensus. Not all contributions are positive or direct; an author might add wording specifically to ward off a rogue interpretation that someone in the WG contributed. If you think this is improbable, read some of the appeals that the IESG has had to address in the past 3 years or so. You are missing John's point, which you elided below the quote above. If someone is a jerk and irrationally aggrieved, nothing we say in a boilerplate will prevent them from suing the IETF and incurring great costs in time and money. A very very careful boilerplate *might* cause them to be less likely to win damages, but balancing that against the time and effort we put into the boilerplate is literally impossible to do. The real risk is where some other SDO can hold IETF liable for damages induced by the irrational aggrievement of someone who contributed to the IETF. While we can't do much about the irrational contributor, we can at least avoid making express commitments to indemnify third parties who use our pre-5378-note-well specifications. This puts the conflict between the irrationally aggrieved party and the third party, leaving the IETF out of the shooting, which is a Good Thing. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
On Jan 12, 2009, at 4:15 PM, Russ Housley wrote: The RFC Editor is asking the authors. That is the list of people that is readily available. If the authors cannot speak for all Contributors, then the document will have to wait until a work- around is found. Given that we've historically weeded out the contributor-list on a document to four or less, even if there were really dozens of contributors at the alleged insistence of the RFC Editor, I don't see how any older document or even a majority of new documents-in- progress could be adapted to the new rules. This appears to require complete abandonment of all previous works and clean room rewrites under the new terms. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Missing Materials
On Jul 24, 2008, at 9:39 PM, Eric Rescorla wrote: As I have done for previous IETFs I just ran getdrafts (http://tools.ietf.org/tools/getdrafts/) on the entire agenda and what follows is the output. As you can see, a pretty substantial number of WGs are without agendas, about 10% of the drafts listed are wrong, and about half of those appear to be simple version errors. ... draft-willis-sip-infopackage-00.txt (wg=sip) Or it could be that I put a draft that expired 4 years ago (but is still in our various secondary servers) on the reading list for a discussion, because it's pretty annoying that we're still trying to decide on whether or not we have consensus to fix the problem 4 years later. Since the agenda I posted is HTML and the draft is linked into that agenda (which everybody SHOULD do, I believe), I suspect it's a question of the getdrafts tool not doing the right thing. Perhaps it should use the agenda's link if there is one? Also, drafts are often revised after agenda are posted. Maybe getdrafts should just pull the latest version? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST
On Jun 25, 2008, at 7:46 AM, Fred Baker wrote: I was about to write something like that to Scott; thanks for making it unnecessary. My additional comment is that if there is some case I can think of that leads me to say should, there might also be another that I didn't think of. Asking me to detail them all up front is IMHO asking too much. On the other hand, I wouldn't be at all bothered by being told that I had to justify a must - since in my mind it is something to be used when not doing the action has a predictable negative outcome, asking the author to say what that predictable negative outcome would be is reasonable. My bottom line on a should is that if an implementer doesn't do what the specification says he should, he should have a good reason and be prepared to explain it if questioned (for example by a customer or during an interoperability test). I disagreed with the spec is *not* a good reason, although it might be a good reason to implement it and provide a configuration knob that turned that functionality off, whatever it was. I believe that in every instance that RFC 2119 language is used to state a requirement that there is either an implicit or explicit statement of consequences that are likely to occur if that requirement is violated. Further, I believe that it is better to make those statements of consequence explicit, and that the severity of the consequences needs to support the severity of the requirements language. We have a tendency to use RFC 2119 requirements language much too liberally. For example, it is frequently used in explication to show what happens, e.g. To reach Bob, Alice MUST send him an INVITE request. There is of course a substantial difference between a description of what does happen, and a statement of requirement against which there are consequences if that requirement is not met. I believe that the clarity of our specifications and our ability to generate test plans against those specifications would greatly benefit from a concerted effort to reduce these spurious usages of RFC 2119 requirements language. The difference between an appropriately used SHOULD and a MUST is one of severity of the consequences. MUST level requirements have the consequence that, if ignored, interoperability failure or other grievous harm is reasonably likely to occur. SHOULD level requirements have consequences of a different order; if the requirement is not met, some operational or functional benefit will not be achieved. MAY level requirements have consequences that are at the level of personal preference, esthetics, flavor, or style. I try, but often fail, to convince authors to explicitly describe the consequences surrounding every RFC 2119 requirement, and to be frugal in the use of such requirements in their text. It is not to our advantage to require a reader to be an expert in the subject to determine what the consequence of ignoring such a requirement may be, or we in effect require every reader of a specification to be an expert in the underlying art. Further, only clear statement of the consequences allow the reviewer of a draft to understand and make a judgement about the appropriateness of the strength with which a requirement is made. While it is always true that there may exist rationale for a requirement that is not known to an author at the time of writing, failure to record any such rationale in a specifications seem to me to be a likely indicator that the specification has not been adequately thought through by the author, making it not yet ready for publication. -- Dean ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Random Network Endpoint Technology (RNET)
On May 21, 2008, at 4:49 PM, [EMAIL PROTECTED] wrote: So we have reinvented STUN? No, we've moved the state of STUN into each of the routers between the two hosts, and have to hope we don't have a route flap somewhere. It's sort of like RSVP. -- Dean ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin == golf!
On Feb 1, 2008, at 2:18 AM, Pekka Savola wrote: Ok, hands up (off-list) everyone who's interested in an IETF golf competition or just casual golf :-) ? Ok, if IETFers are playing golf en-masse, I'm bringing a video camera to the first hole to film tee-off bloopers. I was traumatized for life while working at a Japanese company and being placed in a foursome with a popular engineer who was rotating home and in whose honor we were holding a golf tournament. Of course, I almost but not quite completely missed the ball on the first tee. Maybe 20 or so of the other engineers and their spouses videotaped it. Afterwards, we went back to the office and they played tapes of me whiffing the ball from different angles while everybody drank far too much Kirin and laughed until they fell down. And that's how I got to be this way. -- Dean ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
On Jan 31, 2008, at 3:56 PM, Ray Pelletier wrote: The venue will be the beautiful Citywest Hotel, Ireland’s premier Conference, Leisure Golf Resort and one of Europe’s most popular International Conference destinations. The four star Citywest Hotel is only 20km from Dublin airport and 15km from Dublin City Centre. http://www.citywesthotel.com/site/index.aspx Excuse me, but isn't this in the boonies way outside town? Are we going to be stuck in a $200 a night hotel with no reasonable alternative accommodations eating vastly overpriced hotel food and facing a one-hour commute to anywhere else? We should know by now that isolated resorts ARE NOT ACCEPTABLE as meeting locations. Even if they're vaguely close to cool places like Dublin. It's not too late. Please cancel the meeting now. Even if it costs a bunch of money and means we have to skip that meeting date. Yes, I'm serious. And no, I don't play golf, which appears to be the entire focus of this sort of location. -- Dean ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
