Re: I'm struggling with 2219 language again
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. Having read specs like the Algol 68 report and ANSI X3.53-1976, the PL/I standard that's largely written in VDL, I have an extremely low opinion of specs that attempt to be very formal. The problem is not unlike the one with the fad for proofs of program correctness back in the 1970s and 1980s. Your formal thing ends up being in effect a large chunk of software, which will have just as many bugs as any other large chunk of software. The PL/I standard is famous for that; to implement it you both need to be able to decode the VDL and to know PL/I well enough to recognize the mistakes. What we really need to strive for is clear writing, which is not the same thing as formal writing. When you're writing clearly, the places where you'd need 2119 stuff would be where you want to emphasize that something that might seem optional or not a big deal is in fact important and mandatory or important and forbidden. R's, John
Re: travel guide for the next IETF...
Oh, if you were considering a visit to one of the nearby theme parks, check out their latest hi-tech innovation: http://www.nytimes.com/2013/01/07/business/media/at-disney-parks-a-bracelet-meant-to-build-loyalty-and-sales.html
Re: travel guide for the next IETF...
yeah, I know, but I gotta say to the IEEE SERIOUSLY? Apparently the IEEE folks love it, have been there before. Look at the reviews on Tripadvisor or Google, and for the most part they're quite positive. We're an odd group, much more price sensitive than most conventioneers, and way more demanding about food options. Having said that, I'm renting a car and staying at the Sheraton about 2 miles away for $16/day plus a surprisingly small number of points. If you ask nicely, you can drive around with me and look for places to eat.
Re: travel guide for the next IETF...
So if you don't attend IEEE, quit your whining: at least you won't have to eat he same hotel food for 2 weeks in a row... You don't have to eat there. Check out the reviews of this restaurant across the street: https://plus.google.com/118141773512616354020/about
Re: travel guide for the next IETF...
Good... but how to get there? If you plan to do anything more than spend the whole trip at the meeting hotel, you need a car. Orlando is a cheap rental town, it's not hard to rent something for $100 total for five days. Cape Canaveral and Cocoa Beach are only an hour away for people who think the list of attractions in Orlando itself is a bit thin. R's, John PS: Is Xanadu The House Of The Future still in Kissimmee? How about the Tupperware Museum of Food Storage?
Re: A mailing list protocol
Is there an IETF standard format for handling inline quote replies? It's defined in the same RFC that specifies the setting of the Reply-To: header in mailing lists.
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
Anyone for incorporating a slide (!) into the Newcomer's Presentation (!!) that says a presentation in a f2f meeting that makes extensive use of PowerPoint decks with many and/or dense slides brands the presenter as either a newcomer, someone who is trying to avoid an actual discussion, or a fool? :-( No, just hand out copies of this: http://www.edwardtufte.com/tufte/books_pp -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Newcomers [Was: Evolutionizing the IETF]
Shall we move on? Sure. Since we agree that there is no way to pay for the extra costs involved in meeting in places where there are insignificant numbers of IETF participants, it won't happen, and we're done. That was simple, wasn't it?
Re: Newcomers [Was: Evolutionizing the IETF]
Going to other places would help bring people from other backgrounds, different ideas, new ways of thinking, break paradigms, etc. If these people are unable or unwilling to join IETF mailing lists, why do you think it would be useful for them to go to an IETF meeting? If they are able and willing to join IETF mailing lists, why does the location of the meeting matter? -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: how do Newcomers work in the IETF [Was: Evolutionizing
I find this logic circular. There is more participation from Americans (people from US) so more meetings are held there and so more people from US attend. Anyone in the world with an e-mail address can participate in and contribute to the IETF. I did stuff on mailing lists for years before I went to a meeting, which is not unusual. You do need to be able to read and write English, but beyond that, nobody cares who or where you are so long as you do useful work. If people can only get work done by meeting in person, they're not going to be very effective in the IETF. R's, John
Re: Newcomers [Was: Evolutionizing the IETF]
I don't think that thoes Canada and US participants are paying for the attendance, but their organisations, ... In many cases, you are mistaken.
Re: IESG Considering a Revision to NOTE WELL
Looks much better, people might even read it. - If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. Perhaps disclose that fact promptly. Pete's been reminding us that postponing IPR disclosures until last call or IESG review is not good. R's, John
Re: mailing list memberships reminder - passwords in the clear
In article 5092d99f.3070...@cisco.com you write: Why does the mailing list memberships reminder send passwords in the clear? Because that's what Mailman does. Send code. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: mailing list memberships reminder - passwords in the clear
Only majordomo2, which has been unmaintained for a while now (and it's author calls it Dead holds much of a chance, but I doubt it ?would work for the IETF in its current condition. Actually, MJ2 works great, I've been using it in production for years, but I agree that we'd need to locate a perl weenie willing to make tweaks, and it's probably not enough better than MM to be worth the pain of switching. Sadly this isn't possible with mailman; you will always be mailed your password if you need it and can't remember it. If you use a high value password for your IETF list subscriptions, you have deeper security issues than a few tweaks to mail software can fix. R's, John PS: I saw a description of mailman2 by one of the developers last week. It's really not that different, although he mentioned that the monthly reminders are now off by default.
Re: don't overthink, was Just so I'm clear
I agree with you that removing him would be the simplest approach, but I can see possible situations where NOT following the process could lead us into legal trouble. Anyone can sue in the US for any reason, but this is silly. The IAOC made extensive attempts to contact him in many ways, with zero response. No court I know would find it unreasonable to assume that he's no longer interested. I certainly hope that this sort of situation does not recur, but it seems perfectly reasonable in view of the facts to let the IAOC proceed as though he's resigned. R's, John
Re: don't overthink, was Just so I'm clear
The legal issue raised by a previous reply that resonates with me is that someone unsatisfied with a business decision by the adjusted IAOC membership could sue based on documented process not being followed to appoint the membership. Are you aware of any case law that suggests that any U.S. court would be interested in interpreting or enforcing the nitpicky details of the IETF's governance, or that there is any reason to believe that there are third party beneficiaries to the IAOC's operating rules? R's, John PS: Perhaps we can all stop playing Junior Lawyer now.
Re: rules for the sake of rules, was Just so I'm clear
But we don't have rules that say, failure to attend for X period, without permission, will result in the position being declared vacant. I we did this would be simple. I don't think we have any choice from a proceedural point of view other than to start recall proceedings. Having reread RFC 4071, I don't see a rule that says that the death of a member will result in the position being declared vacant, either. Nor are there any rules that say what documentation would be required to establish that someone had died. At some point we have to allow a sliver of common sense to intervene so people can do reasonable things to solve problems. R's, John
Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06
So, is it better to put in a sentence about representing non-ASCII text in the group name without including a replyable address? The main motivation is to provide a syntax for a non-replyable address in From: and Sender: headers for cases where that is appropriate. See the EAI downgrade documents for a concrete example. A secondary motivation is to remove an arcane restriction that has not turned out to be useful in practice. R's, John
Re: Revised Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
An I-D will only be removed from the Public I-D Archive under unusual circumstances with consensus of the IESG. ... If circumstances permit, a removed I-D will be replaced with a tombstone file that describes the reason that the I-D was removed from the Public I-D Archive. That seems much more realistic and practical. Ship it. R's, John
Re: Antitrust FAQ
directs two people who are at an IETF meeting to refrain from one having a sales discussion with the other in private. Um, could you identify which item under 2 or 3 would describe a sales discussion? R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Utility can determine whether it's worth the effort/expense to run a public archive, but your utility never undermines my rights as an author. We're very deep into Junior Lawyer territory here. You might want to review RFC 3978, section 3.3a, in which contributors make a: perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF under all intellectual property rights in the Contribution: This is unrelated to how long I-D's stay in the public archive. If you're not willing to accept those terms including the perpetual and irrevocable part, you really shouldn't be submitting I-Ds or sending mail to IETF mailing lists. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
In article 505a2b08.70...@isi.edu you write: On 9/19/2012 11:24 AM, John Levine wrote: Utility can determine whether it's worth the effort/expense to run a public archive, but your utility never undermines my rights as an author. We're very deep into Junior Lawyer territory here. I'm not. I'm simply refuting *any* argument that starts with because it's useful to the community. Could you answer the question, please? Are you saying that you are unaware, or do not believe that you have already given the IETF a permanent license for all of your I-Ds and all your other IETF contributions, which means it can publish them any way it wants whether you like it or not? This horse left the barn so long ago that the barn has long since been torn down and replaced by a parking lot. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I very much agree. I'm happy with the decision being the consensus of a board, but not giving it to an individual. So give it to the IESG and we can stop arguing about it. I have to say, the urge to post a few I-D's consisting of snuff porn is nearly irresistible. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I believe we /do/ need a written policy that has been reviewed by legal counsel. Even with a group -- versus individual -- we should not create possible charges of censorship up to the personal whims of the moment. Censorship? Sheesh. The IETF is not the government. We have no obligation to anyone to publish anything, nor can we keep anyone from publishing anything on the 99.9% of the Internet that the IETF does not control. As I think I've said several times before, if we think the IESG would start gratuitously deleting stuff, we have much worse problems than any policy statement could solve. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
It shows a tendency of the active IETF discussants to resist doing the work of settling on policy for the IETF. That's quite different from demonstrating a lack of /need/. The IETF has been around for 26 years, and has had, I gather, zero removal requests to date. If that doesn't demonstrate lack of need, what would? R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Or we can voluntarily turn the trend around, one step at a time, starting with rejecting this proposed statement in favor of discretion, flexibility, and intelligence (and definitely not a statement/ policy of even more complexity) and maybe even including do we really have resources for this among the criteria used to evaluate the creation or continuation of WGs. +1 If the IESG doesn't have the native intelligence to figure out how to deal with a removal request based on the facts of the specific request, we have a problem no set of rules can solve. (Personally, I don't think we have that problem.) It might be useful to ask Jorge to prepare a note about dealing with DMCA notices which are not court orders, but do require a response. Or since the DMCA has been in effect for 14 years and we have yet to get the first notice, we could save time and money drop the topic unless and until the issue arises. There are a whole lot of hypothetical threats that the IETF might have to deal with someday, or not. Life is not long enough to make plans for all of them. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
NEW: An I-D MAY be removed from the public I-D archive in compliance with a competent legal demand. If possible, a removed I-D will be replaced with a tombstone file that describes the reason that the I-D was removed from the public I-D archive. This leaves sufficient flexibility for the IESG to decide when a legal demand requires the removal and when it's bogus, but otherwise leaves the bar high. I would suggest that Jorge review the above text for appropriateness. Let's say I write to the IESG and say this: Due to a late night editing error, draft-foo-bar-42 which I submitted yesterday contains several paragraphs of company confidential information which you can easily see are irrelevant to the draft. My boss wants it taken down pronto, even though he realizes that third parties may have made copies of it in the meantime. I will probably lose my job if it stays up for more than a few days. Thanks for your consideration. Is this the response? You didn't make any legal threats, and now that we know the situation, we wouldn't believe any legal threats you might make in the future, so you better check out those burger flipping opportunities. What was wrong with the original version which gave the IESG the latitude to remove an I-D if they feel, for whatever reason, that it would be a good idea to do so? If the IESG were so screwed up that they started deleting I-Ds for bad reasons, no amount of process verbiage would help. R's, John
Re: the usual mail stuff, was IETF...the unconference of SDOs
I have to say that I'm baffled at the perverse pride that people seem to take in being so technically backward that they're unable to handle the mail that 99% of the world uses today. While not being a fan of overdecorated HTML and endless font changes, and strongly preferring a mail program that lets me keep my fingers on the keyboard, I can deal with it. (I use Alpine, keep meaning to take another look at mutt.) I remember how to punch drum cards, but I have no interest in using one to send mail in 2012. For the large majority of mail that is written in paragraphs rather than tables, line wrapping is a useful feature, regardless of the character set, particularly for those of us who sometimes read our mail on a tablet or phone while changing planes. For mail that is a table and stuff has to line up in columns, use HTML tables. That's what they're for. R's, John PS: Yes, this is top posted. You can deal with that, too. Unfortunately there's some stuff going around that line wrapping with hard line terminations is retrograde and goes back to punch cards. I guess that's probably true but aside from the fact that I'm retrograde and go back to punch cards, myself, application line wrapping and flowed text don't deal well (yet) with multiple character sets, fonts, etc. and I'll take readability over application purity every single time.
Re: the usual mail stuff, was IETF...the unconference of SDOs
There's some stuff that's being sent that is extremely difficult to pull apart. Really? Like what? (This is an honest question -- it's been ages since I recall seeing a message that my fairly dorky mail software couldn't handle.) R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Also it might be useful for the submitter to sign (rather tick a tickbox/radio button) an indemnification clause for the IETF before submitting an I-D. Even a totally meritless DMCA challenge could cost upwards of $100,000 in legal fees to challenge and go through court hearings. Will that be Mastercard, Visa, or Bitcoin? R's, John PS: I think everyone else agrees with the general plan that the IESG can use its discretion to remove I-Ds if they see a reason to do so.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
non-laywer here, The IETF is not an ISP and does not accordingly have safe harbor privileges. Junior Lawyer here. A quick look at the law, or even the Wikipedia article about it (http://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limitation_Act) reveals that the DMCA refers to online service providers which in context means whoever runs the server hosting the content. That would be some combination of the IETF and AMS. If someone served AMS with a DMCA complaint, the options are basically that they remove the allegedly infringing material, or that the party providing the material to them, who might be the IETF or the I-D author, provide a counternotice that the material is not infringing. In either case, AMS is off the hook, but in the latter case, the IETF would probably have to defend if the party sending the original notice decided to sue. The IETF may well be able to argue that it too is a conduit just hosting the I-D's since I-Ds are posted by individuals using an automated process, but that is the kind of argument that makes lawyers wealthy, no matter who finally wins. As far as I am aware, there's never been a DMCA notice for an I-D, and with any luck there never will be, but in practice, a reasonable policy is that if a proper DMCA notice (one that contains all six of the required elements) arrives about an I-D, take it down unless the I-D author provides a counternotice and indemnifies the IETF. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
This discussion of DMCA is useful to me as a non-US resident. Are we sure that the boilerplate included in I-Ds does not constitute a statement by the authors that they have not, as far as they are aware, infringed any copyright? In other words, isn't the boilerplate a pre-emptive counternotice? It's not, and even if it were, would you want to find out retroactively that you've agreed to pay the IETF's legal expenses if someone sues about an I-D you posted?. For more information, please see this link in the message you just sent. (http://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limita$ I agree with Elliott that we need a reasonable DMCA policy, keeping in mind that it's pretty rare for a document, particularly a non-archival one, to be worth the hassle of fighting a DMCA notice. Fighting the TZ takedown was absolutely worth it, but it was unusual in the material attacked was of high value, and the basis for the notice was unusually bogus. Even so, someone had to pay for lawyers to prepare the briefs and appear in court, and I wouldn't want the IETF to promise to do that casually. R's, John
Re: much farther away than IETF 92 in Dallas!
For example once I know the criteria I could check around in Poland to see if there is any place which would satisfy the future IETF venue. http://www.ietf.org/meeting/hosting-an-ietf.html That's about how to be a meeting host, and it's mostly about terminal rooms and social events. Is there a list anywhere of minimum requirements without which it's not even worth looking at a venue? I'd expect that if a place doesn't have (as some examples) a meeting room big enough for a plenary, a set of sufficently large meeting rooms for sessions, a place for a terminal room, a place to have coffee and snacks, and the ability to provision Internet access in meeting rooms and guest rooms, forget it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly PS: Meter-deep water running in the streets is presumably optional.
Re: [IAB] IETF 92 in Dallas!
People also should be aware that Dallas has major transit and highway work underway right now in particular North of the airport. By 2015 (2014 actually), you will be able to take light rail (orange line) from the airport to downtown: http://www.dart.org/about/expansion/orangeline.asp Somehow it just won't be the same if we don't have to wade through waist deep water. R's, John
Re: So, where to repeat? (was: Re: management granularity)
This is worth mentioning because the MY formal rule is not strict prohibition but a formal visa process that is so onerous as to equate to a prohibition. Wouldn't that rule out the United States? It is my impression that getting a US visa for someone with a Cuban or Iranian passport is effectively impossible. R's, John
Re: So, where to repeat?
ps. btw, what is it that you think is different about this from the way we /do/ discuss protocol specs? People discussing venues are less willing to believe that anyone else's experience or issues differ from their own. R's, John
Re: So, where to repeat? (was: Re: management granularity)
So I agree with that. If a feasible venue actually in Dublin turns up I'll be sure to let Ray/IAOC/site-visit folks know. The Burlington hotel claims that they can host a 1500 person meeting. MAAWG met there in 2007 and it worked well for us, although that was a somewhat smaller meeting. R's, John
Re: So, where to repeat? (was: Re: management granularity)
The Burlington hotel claims that they can host a 1500 person meeting. Yeah, it's exactly that easy to choose a venue. A single number does it.[1] not. Of course. MAAWG has been there so we know it's not a dump, it's downtown, they can deal with nerds with lots of computers who demand coffee and cookies, the prices are not totally absurd, etc. MAAWG is smaller than the IETF so there may well be problems that make it unsuitable, but if people are looking for a downtown Dublin hotel, that's the most likely one. R's, John PS: Weren't you at that meeting? The day we arrived there was a benefit women's road race in the morning so when we got there in the afternoon, the pubs were all full of the racers, who ranged from athletic teens to good natured grannies, and their friends.
Re: So, where to repeat? (was: Re: management granularity)
If we restrict European cities to the ones with direct flight connections from other continents, we're really limiting the choices. For some of us, if we limit our choices to places with direct flights, that means Newark, Philadelphia, or Detroit. Count your blessings. We can argue about whether Quebec was unduly hard to get to (I didn't have any problem when I got tickets a month ahead, even though I was redeeming points), but it seems to me that so long as most people can get to or from the venue in less than a day for a reasonable amount of money, it's OK. R's, John
Re: So, where to repeat? (was: Re: management granularity)
Flights to Vancouver from some cities were extremely expensive. It would have cost me more than twice as much as it did to fly to Beijing, for example, if I had taken a direct flight from DFW - it would have been by far my most expensive IETF airfare ever. That's very odd. I see lots of fares from DFW to YVR from Saturday to Saturday via Houston or Denver for in upcoming weeks for under $550, and nonstops for $678. (If you can get to Beijing for that price, I'd sure like to hear about it.) Did you perhaps wait until the last minute to buy your tickets, or have company rules that require flying on airlines without competitive prices to Canada? Flying to Canada is certainly more expensive than flying within the US, but it's not that much more expensive. I thought the hotel and food were all quite reasonable, but it does help that I get the HST back. R's, John
Re: management granularity (Re: Meeting lounges at IETF meetings)
And it means we stop being tourists. Depends where. I would be happy to be a tourist in Vancouver, Quebec, Paris (assuming we can sort out the Hotel Klepto issue), and/or Berlin every year. R's, John PS: But not Orlando.
Re: [IAOC] Feedback Requested on Draft Fees Policy
Yes, we typically then point out that much of what they want is available on line, and frequently negotiate with opposing counsel to moderate demands for depositions, etc., but, in the end, we propose, the judge and opposing counsel dispose. That won't change. I'd want to set the depo rate high enough that if someone has to be deposed, he or she will at least feel that the money makes up for the hassle. For people with unique skills or knowledge, $800/hr is not unusual. So long as the rate is published ahead of time, you're not going to get much argument. (Yes, we know it's high. But we've already told you how to download stuff yourself for free.) R's, John
Re: Proposed IETF 95 Date Change
That said, moving the meeting further south would have helped as well vs. How far north Vancouver is. Summer daytime temperatures in Vancouver are typically 20c or lower, while in the southern US they're usually over 30c. I'm not sure that would be an improvement. You're not going to find cool temperatures again in July or August unless you go as far south as Argentina or New Zealand. R's, John
Re: Proposed IETF 95 Date Change
You're not going to find cool temperatures again in July or August unless you go as far south as Argentina or New Zealand. Not only is there life north of the 60th parallel (N), there are even hotels and restaurants and airports. Anchorage is probably large enough for an IETF meeting, although trying to hold a meeting there during tourist season would almost certainly be a mistake. But still. I believe it, but remember that the issue was to minimize daylight fasting during the North American summer. Reykjavik is big enough, too, and has the advantage of being roughly equally inconvenient to get to from North America and Europe. We could have the social event at the Blue Lagoon. R's, John
Re: Proposed IETF 95 Date Change
I see. Well, look on the bright side: the meeting could have been in Reykjavik ;-). Yes, that would have been bright, wouldn't it? R's, John PS: sure like those hot dogs, though.
Re: Feedback Requested on Draft Fees Policy
The draft policy entitled Draft Fee Policy for Legal Requests can be found at: http://iaoc.ietf.org/policyandprocedures.html It seems fine to me, but I would add an hourly rate for research. For requests for e-mail, do they typically provide pointers to the specific archive entries, or do they ask for all mail from A on topic B in month M? In the latter case, a suitable hourly research fee would likely persuade many lawyers to tell an associate to learn how to use grep. R's, John PS: Yes, I know it's volunteers. The revenue would go into the cookies fund.
Re: bits-n-bites: Exhibitors and product vendors hawking wares at anIETF meeting?
NANOG is around 500 attendees. I daresay exposure to the average nanog attendee is worth more, but ultimately the best feedback in that regard will likely come from the sponsors. IETF is bigger, but on the other hand, IETF attendees probably spend less per capita on equipment than NANOGers do. It's an experiment, if we're turning away sponsors and people think it was overall a success, we can raise the price. If not, well, we can do something else. R's, John
Re: New Non-WG Mailing List: IETF-822
Maybe, in the interest of interplanetaryization (i19n ?) and multigalacticism (m13m ?) we should start using FoPSCII and Galicode references in our documents and noting that ASCII and Unicode are temporary substitutes. It hardly seems worth the effort, since the only difference between ASCII and FoPSCII is that the ASCII # is replaced by the modern currency symbol, and, of course, they put the little gap back in the vertical bar to resolve the concerns about religious and cultural insensitivty. R's, John
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
The intended rotation cycle is still 1-1-1 for NA-EU-AP regions, but it's all dependent on finding suitable and available venues and willing hosts and sponsors. Changing the text of the document would imply a change in policy or normal state of things which there hasn't been. Hmm. So a dream world is the normal state of things...I guess really should read this thing, if only to discover what other fantasies have been made real through the magic of rough consensus. Gee, while we're at it, perhaps we should remind novices that the best way to make progress is to send snarky comments rather than revised text. Old: Currently, the IETF meets in North America, Europe, and Asia, approximately once a year in each region. New: Currently, the IETF meets in North America, Europe, and Asia. The intention is to meet once a year in each region, although due to scheduling issues there are often more meetings in North America and fewer in Asia. R's, John
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Do we spell Standardization with and s or a z? Yez. R's, John
Re: Long discussion about IETF on the Internet Governance Caucus mailing list
In article CAHBU6iui0_n_=3p85msgdcswc3johl5f0hcbycmip04fvuo...@mail.gmail.com you write: Who are these people? -T Based on what I've seem on the IGF list, people with an extraordinary amount of free time. R's, John
Re: IETF posting delays
the question seems to be we used to reply to the sender with a notification that their message was blocked due to not being a list member, with options to wait or cancel; did we disable those notifications? I sure hope so. These days about 99.9% of spam from unknown senders is spam with forged addresses, so responses are just more spam aka blowback. There are networks that send me far more blowback than all the other mail they send combined. R's, John PS: Postini, we're talking to you.
Re: Last Call: draft-levine-application-gzip-02.txt (The application/zlib and application/gzip media types) to Informational RFC
I do believe that, someday, someone should try to write up an up-to-date description of the difference that recognizes the fact that compressed files are in use as media types with application/zip (in assorted spellings) and application/gzip (from this spec and in assorted spellings) as examples. But I now believe it is a separate task that should not block this document or registration. I'll be happy to do that if I can ever find enough spare time to write it. You're right, it would be nice if there were some way to distinguish containers from content in MIME types. But given the existing historical mess, and that some kinds of compression are just a different way to encode a bunch of bits (zlib) whereas others are more like a small filesystem (zip and tgz), even if we could start with a clean sheet it's not obvious to me what would be the best thing to do. R's, John
Re: Issues relating to managing a mailing list...
In article 4f6236e6.5030...@nostrum.com you write: The current plan is to investigate both a web based archive access mechanism and an IMAP based one. Don't forget NNTP (RFC 3977). I use it locally, deliver list mail to local per-list newsgroups, and it works really well. R's, John
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Last month I ran into a guy on the dmarc list who complained that his server returns NOTIMP in response to queries for SPF records (because it doesn't implement them) and clients were doing odd things. But it's been a long time since I've run into anyone else like that, so I agree, it's not an issue. In case it wasn't clear, this is an authoritative server. A RFC 1035 recursive server should be able to handle SPF. It's just a opaque data blob to it with a name, type, class and ttl attributes. Agreed. Other than a few dusty Suns still running obsolete BIND 4.x, I don't know of any DNS caches that have problems with arbitrary RRs. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Sometimes an ASCII text record will be fine, in other cases, it probably won't. My point is as we move again towards multiple text representations of the digit five for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not text that someone has to parse. Unless you provision your DNS zones with a hex debugger, the digit will always start out as text that someone has to parse. The question is who does the parsing, the DNS server or the application. As I said in a previous message, I can see plausible reasons to put the parser into the application. Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. R's, John PS: For anyone who didn't read my previous message, I am NOT saying that it's fine to overload everything into TXT. I am saying that new RRTYPEs that are text blobs interpreted by client software wouldn't necessarily be bad. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Would you really want to build an SPF or DKIM parser into every DNS server? Here's another thought experiment. DKIM records are a sequence of tag=value fields. Let's imagine a binary version of DKIM records where each field is a length byte, a tag byte, and a suitably coded value. For the values that are currently strings, it's the string, for the values that are currently base64, it's the binary value. Since DNS TXT records are a sequence of binary strings each preceded by a length byte, we could just stuff this version of DKIM directly into a TXT record, with the first binary string being v=DKIM2. Would that be a good idea? DNS servers can serve the records without adding any new features, the records will be marginally faster to parse. Would that be a good idea? Why or why not? Assume we wave our hands and we have some way to create the records, hacks in provisioning systems, or a wizard web site into which you type your parameters and it gives you a TXT master file record full of hex escapes. Or wave them even more vigorously and assume the parser is built into some future version of BIND. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: field types, was provisioning software, was DNS RRTYPEs, the difficulty with
Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. Honestly, if new RR types were all text to be parsed by clients, a la SPF and DKIM, that wouldn't be the worst thing in the world. The main advantage of a new RR type is that clients can ask for it specifically and know that any they answer they get is that kind of data, as opposed to overloaded TXT where you get what you get. If the DNS records have binary fields, the parsing happens in the DNS server. If they're text, the parsing happens in the client. Back when the DNS was young, the suggestion that clients would have to parse the records would have seemed nuts. Now mail clients parse multiple SPF and DKIM records on every mail transaction and nobody cares. An advantage of parsing in the server is that you catch syntax records earlier, but that's still no guarantee that the data are valid. (For example, see the MX data for international.com, which caused a mail loop I fixed yesterday.) An advantage of parsing in the client is that the parser is in code managed by people who care about it, rather than managed by some distant DNS operator. I suppose that unparsed records mean that the server can't add additional section records, but based on yesterday's discussion, it sounds like nobody's using them any more, so who cares? -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
This draft also defines the MT-Priority header field. �It is quite unusual for a SMTP extension specification to define a mail header field. ... This is my major concern about this protocol as well, as I note in the PROTO writeup (which, unfortunately, can't be seen publicly because of a limitation in the datatracker; perhaps I should post it here). I'm interested in hearing whether others share this concern, and what the community consensus is about it. I have no problem logging stuff from the SMTP session into a message header, we've been doing that since forever. But I have a lot of problem turning a header back into SMTP for a subsequent relay, for two reasons. One is just that it's ugly. There were good reasons to separate the envelope from the body back in the 1970s, and I think those reasons are just as good now. Over in the EAI group, there was a valiant effort to tunnel EAI messages through non-EAI SMTP servers via downgrades, and we eventually gave up. Now, if you want to send an EAI message, there has to be an EAI path all the way from the sender to the recipient. This isn't exactly analogous, but it's instructive. The other reason is that I think it's too ill-specified to interoperate. The theory seems to be that the relay server notices an MT-Priority: header, and (vigorous waving of hands) somehow decides if the message has sufficient virtue to promote the header back into the SMTP session. The hand-waving is not persuasive; the suggestion of S/MIME, which obviously won't work, is not encouraging. If you want to brave the ugliness and standardize this, the spec needs to explain how the server decides whether to believe an MT-Priority header. If it doesn't, it's too vague to interoperate. So I have two suggestions. One is to leave it as is, and make it experimental. If it turns out the tunnels all work the same way, you can come back and add the spec about how they work and rev it as standards track. The other is to take out the tunnel bit and make it standards track now, so a compliant implementation needs priority-aware MTAs from end to end. Even if you take out the tunnel stuff in the spec, you can still tunnel in your implementations, using whatever non-standard ad hoc kludges you want. Since the current spec has gaps that would need to be filled by non-standard ad hoc kludges anyway, you haven't lost anything. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
If your DNS hosting company doesn't support them find another one or complain to them. You are paying them to host your DNS services and this is a basic part of the job. Can you suggest some DNS hosting companies that provide support for provisioning SPF records? I'm not aware of any. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In an ideal world I'd also like to see us move in the direction that RFC5507 promotes, but it seems we still aren't there yet. I'm still hoping to get some more feedback on draft-levine-dnsextlang-02.txt R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
So, what we need to do is learn from that experience. 8.5 years later support for 3597 is a very reasonable thing to expect, and with , DNSSEC, etc. we're well past the era where hidebound DNS software is an acceptable operational model. There are indeed very few current DNS servers that can't be persuaded to serve up arbitrary record types, but as we've been saying over and over, that's not the problem. The problem is provisioning software. We weenies can stuff anything into our DNS servers we want, because we use vi and emacs and (in my case) custom perl scripts. For the other 99.5% of the world, what they can put in their DNS zones is limited to whatever the web provisioning software at their registrar or ISP or web host supports, and I challenge you to find any that supports SPF records. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
Er, so? If the tool to bundle up the needed bits for SPF-as-text and SPF-as-binary are similarly trivial, why should we care if people who want to use a feature of the Internet can't persuade their provider to make a trivial change. Because there's no point in checking records that don't exist. RFC 4408 has been out for six years, and people who run large mail systems report that the number of type 99 records is basically zero. To several significant digits, all type 99 queries are wasted traffic. Soon, y'all will be saying we should give up on DNSSEC because so few registrars support it in their web UIs. Registrars will because they have to. The registries (or maybe ICANN) will beat them up. I'm looking forward to a couple of decades of the DNS crowd complaining that there's no DNSSEC at zone cuts below TLDs, while remaining impervious to the concept that it's because upgrading provisioning to handle them is even harder than upgrades for simple records like type 99. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Errata against RFC 5226 rejected
In other words, I don't see a problem with the existing text that warrants bothering with an errata. If IANA isn't able to figure out what they need to do under the current wording, we have problems that no amount of word twiddling can fix. R's, John PS: The last time I checked, it wasn't a problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Section 5 is for those people that do DKIM without ADSP but care about giving author domain signatures preferential treatment. Since there's nothing in the DKIM spec that suggests that's a correct way to use DKIM, I'd be fairly unhappy about any language that purports to legitimize it. Here in standards-land, if you think that author domain signatures matter, you're supposed to use ADSP. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
With ATPS, the requirement is to replace the d= string with the domain name from the From: field. That replacement value is then passed to the assessment module. In other words, DKIM provides it's own identifier to be used for assessment, whereas ATPS dictates use of the From: field domain name for assessment. At least one of us is confused here. ADSP already dictates use of the From: domain. ATPS is a modification to ADSP. It doesn't change anything that DKIM reports, only the rule for deciding whether ADSP finds an Author Domain Signature. With or without ADSP or ATPS, DKIM returns a possibly empty list of d= domains from valid signatures. ADSP returns the practices value (unknown/all/discardable) and a bit whether it found an Author Domain signature. Since there might be multiple DKIM signatures, even if ADSP says it found an Author Domain signature, you can't assume a d= domain had any relationship to the From: domain. It's true that ATPS adds a field to DKIM signatures that doesn't affect DKIM evaluation, but DKIM already knows how to skip over fields it doesn't understand. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Does this mean that those who have not had a car accident should not carry auto insurance? Should those who have not had their house suffer damage from wind, rain, flood or fire or had someone sue them after slipping on the sidewalk should not have homeowner's insurance? What does insurance have to do with an antitrust policy? Insurance offers specific levels of indemnification for specified and reasonably well understood risks. An antitrust policy has nothing to do with indemnification, and if anything is clear from this discussion, it's that we don't have any idea what the risks actually are. I suppose the suggestion to ask an actual anti-trust litigator if there are risk mitigation steps we could take might be reasonable, but it also strikes me as not unlike asking an herbalist if we need any herbs. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-marf-redaction-03.txt (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC
This draft proposes a way to semi-redact personal information in spam reports by replacing the address or other string by a hash. It's a reasonable idea, but as far as I know, it has not been implemented. Speaking as one of the authors of RFC 5965, which this draft would update if it were on the standards track, I'd have no objection to folding this into an updated version of 5965 if there were some evidence that people actually did what it proposes. Hence I would suggest it be published as experimental rather than informational. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. +1 This has the admirable advantage of waiting until there is an actual problem to address, rather than trying to guess what has not happened in the past 30 years but might happen in the future. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
I'm one of the authors of RFC 5617, which this document would update if it moved into the standards track. It doesn't seem very useful to me, but it also seems mostly harmless so there's no reason not to publish it as experimental. This strikes me a hack that appeals primarily to bulk mail senders who grossly overestimate how interested receivers are in helping them do their mail management. So I would be surprised if there were many receiver-side implementations, but it's an experiment so what the heck. No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. I would strongly suggest changing the IANA section so that the DKIM-Signature tags in section 8.4 are registered when this is published. Tags are text strings, and I'd rather the tags it uses be noted and reserved so that nobody uses them for something else in the future and risks collisions. For the same reason, it'd probably be a good idea to register the authentication-results tags described in sections 8.2 and 8.3. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF - why?
The IETF legal counsel and insurance agent suggest that the IETF ought to have an antitrust policy. I would be interested in a brief explanation of why we need one now, since we have gotten along without one for multiple decades. Having worked with a lot of lawyers, my experience is that few lawyers understand cost-benefit tradeoffs, and often recommend spending unreasonably large amounts of money to defend against very remote risks. Similarly, insurance agents will usually tell you to insure against anything. (This is why NDAs are 12 pages long, and the standard deductible on policies is usually an order of magnitude too small.) I don't know the particular lawyer and agent involved, and it's possible they're exceptions to the rule, but before spending much money, I would want to understand better what problem we are trying to solve and what the realistic risk is. Also keep in mind that the main effect of such a policy would be to shift whatever the risk is from the IETF onto participants. It might also be educational, here's things that might lead to personal legal risk if you talk about them, but we don't need a formal policy for that. I understand that some other SDOs have antitrust policies, but they generally have organizational members, and other differences from the IETF that make them only weakly analogous. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: non-line-printer-shaped screens, was discouraged by .docx
Perhaps because no one actually reads RFC's on these small devices, and so we've been trolled by a master into worrying about a use case which isn't really a problem. I read I-D's on my Kindle, when I can get the XML so I can turn it into something legible. I'd read RFCs on it if there were a reasonable way to do so. I'm 57 years old and quite nearsighted, so my near-geezer opinion is that the option to change the text size and have the text reflow and still look OK is very useful. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Here is some relevant language from the Complaint: 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct ... As I read that, we'd be much better off having no antitrust policy at all. Any volunteers to monitor and enforce whatever policy our lawyer invents? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
FWIW, I think that, if we are going to start banning proprietary formats, it makes lots more sense to ban _all_ proprietary formats, not just picking and choosing among proprietary formats that are, e.g., more recent or less frequently reverse-engineered than others. So, yes, let's ban pptx, docx, ppt, doc, non-standardized forms of PDF, GIF, ... I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. On the other hand, the definition of GIF is in a 20 year old document published by a predecessor of AOL, which includes a widely ignored trademark license requirement and an infamous patent. Hmmn. Since apparently some formats specified in ECMA and ISO standards are proprietary, while some that are privately defined and encumbered with trademark and patent restrictions are not, could someone provide a concise description of how I can recognize a non-proprietary format? R's, John PS: I'm not denying that docx and pptx can be unpleasant to deal with, although LibreOffice hides a lot of the unpleasantness. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reading on small devices, was discouraged by .docx
ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. If you can pan and scan a complex PDF file, you can pan and scan ASCII art. I've been doing some experiments trying to make RFCs and I-D's readable on my Kindle. It has native support for some reflowable formats (AZW and MOBI), and PDF. Amazon provides conversion software that turns several other formats into their flavor of MOBI, and a conversion service in which you e-mail documents to an address assigned to your Kindle, and they convert them to versions that appear on your device via a wireless network connection. You can also plug it into your PC as a USB disk and copy MOBI, AZW, and PDF files to it. The conversion service will accept text documents, but the results of sending an RFC or I-D through it are too painful to read other than in utter desperation, not just the ASCII art but the scrambled text. The device renders PDF page images quite well, but since the screen is so small, the text is too small to read. There's an option to select a rectangle and expand it, but the rectangle doesn't cover an entire line and you have to move it back and forth for every line which is slow and painful. You can turn the Kindle sideways, it rescales PDFs to the width of the screen, and you can use the up and down buttons. That is large enough to read, although still pretty small. I would have to say that PDF support is better than text, but still pretty poor. If you have PDFs with a native 4x6 page size, they look great, but you need to have your document in some other format that can be reformatted and printed to small page size PDFs. The conversion service and software handle a reasonable subset of HTML, so I tried running the XML source for I-Ds through saxon or the new xml2rfc, and then converting that to a Kindle native format. That works well, text nicely reflowed, ASCII art preserved as a block, and links to other sections and documents even work. I now use those as working versions of my I-D's. I haven't tried other e-readers, but the MOBI format is not unlike ePub format, so I expect the results would be similar. This tells me that it would be really nice to have a meta-format (probably xml2rfc, since it exists, and it's ASCII underneath so under even the worst scenarios the content is still accessible) that we can render into formats that work on whatever devices we use to read stuff. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
Adding a new tool/process is absurd. If you have a solution that actually works for everyone without adding much to their time burden, test it, demonstrate it with your own materials, etc. Are there really presentation programs so lame that they can't export PDFs? If so, loop back to the beginning of this dicussion in which people refuse to update decade old software. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
This doesn't address strict pdf/a 1.4 compatibility, but this is a more subtle problem which the ietf cannot realistically expect its presentation submitters to handle in a consistent manner. OOO and LibreOffice purport to export PDF/A. I haven't run the results through a verifier to see how well they do. But I gather that we also have people who are opposed in principle to free software* so never mind. R's, John * - You don't want to get locked into open source, credited to an IBM salesman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
What is much more important is that the data formats used by the IETF will still be fully supported in 15-20 years. For a new, and more so a proprietary data format, ... I'm confused. When you say a proprietary data format, I presume you mean Microsoft's closed and undocumented PPT format, as opposed to PPTX which is ISO/IEC Standard 29500. So you're arguing that everyone should move to the standard PPTX. Or did you mean something else? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 82 Audio Streaming
PowerPoint slides regularly require a real Microsoft Windows with a PowerPoint viewer I find that Libreoffice on FreeBSD shows all the powerpoint slides I need to show just dandy. PDF is nice but not a lot easier. R's, John PS: I presume we've all read the notes that meetecho also speaks SIP? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jdfalk-maawg-cfblbcp-02.txt (Complaint Feedback Loop Operational Recommendations) to Informational RFC
I'd still prefer s/the largest/a/ or s/the largest/a large/ or similar. This makes no sense. you believe that there is another large organization that does what MAAWG does? Others asked about the non-derivative blurb, and maybe I missed the answer for these questions. What is the idea? That's the normal language for for RFCs that reproduce other organizations' documents. There's nothing unusual about it. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: size of the XML of IANA ports
If anyone has any suggestions on how to speedup the rendering part, please do let me know either on-list of off-list. Break up the version that you get by normal web browsing into multiple interlinked smaller pages, keep the big page available at a fixed address for people who want to download it and parse it for other purposes. Parsing giant web pages is just slow, and not likely to get faster since most sites break big pages up precisely to avoid the slow rendering. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jdfalk-maawg-cfblbcp-02.txt (Complaint Feedback Loop Operational Recommendations) to Informational RFC
The no derivative clause makes it impossible to incorporate the material in this draft in any IETF work. Section 3.3 of RFC 5378, on derivative works says: There are two exceptions to this requirement: documents describing proprietary technologies and documents that are republications of the work of other standards organizations. It looks to me like the latter clause applies here. RFC 5744 has similar language specifically for the Independent stream. Since J.D. happens to be on the relevant MAAWG committee, he could probably get approval to make minor changes, e.g., move the MAAWG blurb to the end, but I would rather the IETF stop nitpicking and just publish it. It's a reasonable discussion of a relevant topic on which MAAWG has more expertise than the IETF. RFCs 5564, 5728, 5830, 5831, and 5832, all are republished and have no-derivative notices, so this wouldn't be particularly new or unusual. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Yes, there's no doubt that the IESG needs to have strong input into IASA decisions; there is no way round that. But it isn't clear to me that this must be the IESG Chair's job, if we had a model where the IETF Chair and IESG Chair were two different people. As long as it's one person, this is a zero-sum game. It seems to me that the basic problem with this whole argument is that you can't force people to pay attention by making rules, particularly if the attention shortage is due to lack of time rather than lack of interest. I would rather have somebody show up at my meetings who has delegated authority, enough time to pay attention and think about the issues, and a good working relationship with the chair than insist that a harried chair call in and mute his phone so everyone one else can't hear that he's answering e-mail about all the other stuff he has to do. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
Is there any reason we can't create this on wikipedia itself, e.g.: http://en.wikipedia.org/wiki/RFC3514 Wikipedia is an encyclopedia, and all that is supposed to go on the main pages is encyclopedia type material, which this doesn't sound like. There's a talk page where you can have arguments, but that's not particularly well managed or archived. Setting up a mediawiki system is technically trivial, like 15 minutes' work. The hard part is managing it. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
I think that if some people support the idea, they can easily create a wiki somewhere (e.g., specsannotated.com) and get to work. If the experiment has value, we'll figure that out. If not, well, it was just an experiment. Agreed. In my experience, wikis only work well if they have someone overseeing them to weed out the spam and the flame wars. Actual data point: the IRTF ASRG has a wiki (http://wiki.asrg.sp.am) which works reasonably well, but that's mostly because I'm somewhat selective in handing out passwords so I know who's modifying what. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: you can't force people to write well, was 2119bis
When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. Having done my share of writing, and also having hired people to write for me, I entirely agree. You can't force people to write well by adding ever more detailed and nitpicky rules. If the problem is that RFCs aren't clear, or that they use words in misleading ways, the burden should be on the WGs that produce the drafts to fix them so that they say what they're trying to say better. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: schedules, was voting system for future venues?
Obviously the date needs to be fixed at some point, but does it really have to be six years in advance? ( http://www.ietf.org/meeting/upcoming.html ) As I understand it, the main reason to schedule so far out is to avoid collisions with other meetings that attract a large number of the same people. If there's a way to have more date flexibility without colliding with other meetings, I suspect the IAOC would be highly interested to hear about it. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
I can't tell what problem we're trying to solve here. The original question (other than that whoever runs the IETF web site should buy a new cert) seemed to have something to do with mailing list archives. I think it would be swell to know that the archives I retrieved were the real ones, but what does real mean here? A - The messages sent by authenticated senders B - The contents of the archive as of some past time when the archives were created C - The archives as they are on an IETF server now D - The archives as presented by some presumably reliable piece of software (pipermail) E - Something else While option A might be nice, it's not going to happen without an implausible level of S/MIME or PGP signing. Option B seems useful to me, since it defends against the threat of accidental or deliberate bitrot. (An example might be restoring an archived copy that had the addresses xxx'ed out.) Options C and D seem less useful. Harking back to a previous argument about signing RFCs, the way I would do option B would be to publish hashes of the archive files in enough places to be sure they're persistent, e.g., print the latest set of hashes on the back of everyone's name card at IETF meetings. TLS for session privacy is nice, but I find negligible value in a little lock icon in my browser that means only that one of the several dozen cert issuers configured into my browser, most of whom I've never heard of, and many of whom aren't even the organization in the cert name, signed something. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
What I have heard is that the community would prefer going to locations that were easy to travel to over interesting. Well, some of the community. I expect that's because we just came back from a meeting that wasn't great for travel (insert shout-out to the gang who were all stuck for the night at the Phila airport Marriott) but once we got there, had good food and interesting stuff to do nearby in the evenings. If we'd come back from a meeting that was within walking distance of a hub airport, but all the places to eat had bright lighting and laminated menus, I expect the set of complaints would be quite different. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Manila, was voting system for future venues?
I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Um, you can fly YYZ-NRT/NRT-MNL on AC and NH in about 20 hrs. The return flight is about 18 hrs, same route. Any chance we've forgotten about the International Date Line? I see coach fares of about $1200 which is not bad for such a long trip. From YOW, it's not surprisingly 2-3 hrs more with another connection, but there's a reasonable route on DL via Detroit and Nagoya for only $917, 22 hrs out, 21 hrs back. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
DKIM is designed for to deal with one posting and one delivery. Mailing lists take delivery and re-post. For almost all scenarios, DKIM was not intended to survive re-posting. I wasn't referring to the post from the originator to the list, I was referring to the message posted from the list. The list signs the message on the way out, so the ietf.org signature verifies. If the original sender signed the message, his signature won't verify but (to collapse several years of flamage on the DKIM list) that's not a problem. I still don't think we should add subject tags for the aforementioned autotrofigiaskylousphagic reasons, but DKIM signs perfectly well either way. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
happy to let those who prefer to not have such a prefix setup their procmail rules to remove it.-:) Gee, I was about to say I was happy for people who want a subject tag to add one using procmail or whatever. I'm not unalterably opposed to subject tags, but I believe that the IETF's dogfood is of the List-ID: flavor. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. It's definitely a case of the best being the enemy of the good. There are some basic problems with any system of policy assertions: the people making the assertions may be mistaken or lying (something we've seen with ADSP), and there are precious few assertions that I can make that are of any use to you in deciding how to deal with my traffic. Since you have no reason to believe my assertions unless you already know me, you need mechanisms for third parties that can opine about the credibility of self-assertions. Inventing the mechanism is only medium hard (see RFC 5518) but spinning up vouching services that provide a usefully large amount of information is very hard. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished? If we knew what to build, we'd build it. We published RFC 5518 for VBR, a reputation system that sits on top of DKIM, two years ago. At this point I know of only one small VBR provider, which I manage. Also, even without general reputation systems, there are special cases that are worth doing, e.g., there's a handful of large heavily phished domains that sign all their mail, notably paypal.com and its ccTLD variants. For a medium or large mail system, it's worth adjusting the spam filters to throw away mail purporting to be from Paypal that doesn't have a signature. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. What about a RFC 5617 published signing practice? That RFC is only useful for a narrow range of heavily phished domains like Paypal's. Fabulous though the IETF is, it's not one of them. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
See http://www.out-law.com/page-5536 It says There is no legal authority on the effectiveness of these notices in email messages; and There is no legal authority on the value of these notices in email communications. When the notice is added automatically to every external communication, there is a risk that a court would consider that the venom in your warning has been diluted, then goes on with a couple of pages of advice about how to write a useless confidentiality threat, advising people to put it at the top of the message to force them to read it. Guess I know who I won't be consulting if I ever need legal advice in the UK. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Ever since, I've wondered if these notices were set up by someone who is a lawyer and does understand the situation, or if they were set up by someone who saw others do it, or heard that this sort of thing was needed. It's clueless cargo cult lawyering. I blogged on it in January: http://jl.ly/Internet/confid.html At least in the US, which is where the IETF has its formal existence, these notices have no legal merit at all. They're just stupid. R's, John PS: Anyone who wants to argue they're not stupid should include citations to case law. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Yes, and perhaps disclaimers/confidentiality notices should be standardized with their own MIME type to make automatic processing easier so receivers of this kind of notice (mailing-list or other) can respect the wishes of the sender. That respect would of course be demonstrated by rejecting or discarding the mail unread, to avoid any possibility that it could fall into the wrong hands. R's, John PS: Perhaps I should propose a revised RFC 5617 adding dkim=confidential. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. Seems reasonable. I gather that there are already caches with the ability to partition themselves so that records from different subtrees compete for different pools of cache entries. I'm also sort of surprised that we don't seem to have all that much experimental data about cache behavior. The MIT papers that Tony cited are interesting, but they're also ten years old. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
