RE: ORCID - unique identifiers for bibliographers
I do have an identical twin brother, and hashing the DNA sequence collides more regularly than either random or MAC-based interface-identifiers in IPv6. Also, he doesn't have the same opinions. Clearly, one of you needs to get to know some retroviruses. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: not really pgp signing in van
You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair. I think we're entering the tinfoil zone here. Comodo is one of the largest CAs around, with their entire income depending on people paying them to sign web and code certs because they are seen as trustworthy. How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: not really pgp signing in van
Typical S/MIME keys are issued by CAs that verify them by sending you mail with a link. While it is easy to imagine ways that could be subverted, in practice I've never seen it. The most obvious way that it can be subverted is that the CA issues you a key pair and gives a copy of the private key to one or more others who would like either to be able to pretend to be you, or to intercept communication that you have encrypted. I would argue that this is substantially less trustworthy than a PGP key! Like I said, it's easy to imagine ways it could be subverted. If you believe all CAs are crooks, you presumably don't use SSL or TLS either, right? Of course you can _do_ S/MIME with a non-shared key, but not for free, and not without privacy implications. (I'm just assuming that an individual can get an S/MIME Cert on a self-generated public key—I haven't actually found a CA who offers that service.) Same issue. I can send signed mail to a buttload more people with S/MIME than I can with PGP, because I have their keys in my MUA. Hypothetically, one of them might be bogus. Realistically, they aren't. Very nearly that same degree of assurance can be obtained with PGP; the difference is that we don't have a ready system for making it happen. E.g., if my MUA grabs a copy of your key from a URL where you've published it, and validates email from you for a while, it could develop a degree of confidence in your key without requiring an external CA, and without that CA having a copy of your private key. Or it could just do ssh-style leap-of-faith authentication of the key the first time it sees it; a fake key would be quickly detected unless your attacker controls your home MTA or the attacked identity's home MTA. That would be great if MUAs did that, but they don't. As I think I've said three times now, the actual support for S/MIME in MUAs is a lot better than the support for PGP. It helps that you can extract a correspondent's key from every S/MIME message, rather than having to go to a keyserver of some (likely untrustworthy) sort to get the PGP keys. If we think that PGP is so great, how about writing native PGP support for Thunderbird and Evolution, and contribute them to the open source codebase? 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: not really pgp signing in van
> Yes, and no. PGP and S/MIME each have their own key distribution > problems. With PGP, it's easy to invent a key, and hard to get other > people's software to trust it. With S/MIME it's harder to get a key, > but once you have one, the software is all happy. That's a bug, not a feature. The PGP key is almost certainly more trust= worthy than the S/MIME key. Um, didn't this start out as a discussion about how we should try to get people using crypto, rather than demanding perfection that will never happen? Typical S/MIME keys are issued by CAs that verify them by sending you mail with a link. While it is easy to imagine ways that could be subverted, in practice I've never seen it. > The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot > better than they support PGP. There's typically a one key command or > a button to turn signing and encryption on and off, and they all > automagically import the certs from on incoming mail. Yup. That's also a bug, not a feature. I was just wondering why that is. The only implementation I've seen a reference to is Sylpheed, which is not widely used Same issue. I can send signed mail to a buttload more people with S/MIME than I can with PGP, because I have their keys in my MUA. Hypothetically, one of them might be bogus. Realistically, they aren't. R's, John smime.p7s Description: S/MIME Cryptographic Signature
Re: What real users think [was: Re: pgp signing in van]
To be clear, what I would like to see in an MUA that addresses the use case Brian described is that it is just a new mime encoding that allows a message to be pieced together from a collection of signed attachments. So in this message, the mail would be encoded as two parts. The first would be the complete message you wrote, with its signature. The second would be the text I have written here. The quoted text above would be represented as a reference to the attached message. This should be very easy to accomplish in the UI—the UI should look exactly like the current UI. It's just a tweak to how copy, cut and paste work. There's no reason to get rid of MIME—I think it's a pretty good solution. I mentioned the other solutions not because I prefer them but because they exist and do demonstrate that replacements for IETF standards can and do catch on in the marketplace, and that we ought not to just be smug about how great SMTP, RFC822 and MIME are and pretend that we don't have competition. S/MIME handles this case pretty well, but I've never seen anything other than a list manager such as Mailman wrap signed parts together. 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Sorry if that last one came across as dismissive. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on "overloaded TXT considered harmful" to get it into the RFC record. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
prevented, not solved. I would like to prevent someone from having to submit a draft specifying that in the case of TXT, the (name, class, type)-tuple should be extended with the first X octets from the RDATA fields, somewhere in the future, because client-side demuxing is getting too buggy and it seems like a good idea to select specific records in the DNS itself. Could you point to anyone, anywhere, who has ever said that the odd history of the SPF TXT record means that it is perfectly fine to do something similar in the future? On the other hand, please look at all of the stuff that people outside of the IETF do with apex TXT records, and try and say with a straight face that SPF as as much as 1% of the multiplexing problem. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
* The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. ... The SPF working group discussed this issue at painful, extensive length. As you saw when you read the WG archives, there is a significant interop bug in rfc 4408 in the handling of SPF and TXT records, which (again after painful and extension discussion) we decided the least bad fix was to get rid of SPF records. I don't see anything in your note about how else you think we should address the interop bug. In your case it doesn't matter, since your TXT and SPF records make no usable assertions, but a lot of people use SPF right now as part of their mail stream management. R's, John
RE: Faraday cages...
Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. You must not have seen my cell phone. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: Speaking of VAT
At last week's very successful Berlin meeting, the finances were thrown of whack by the late discovery that the IETF had to pay 19% German VAT on the registration fee. At the IAOC session they said that about half of that is likely to be reclaimed from VAT paid, but the net amount is still a large number. The usual IANAL and IANAC should not be joined by IANACPA. But a CPA at my company said that we couldn't reclaim the VAT, because the "service" was consumed in Germany. If others hear different from their accounting departments, I'd love to hear about it. Ray said the tax guys told him the IETF would get back about half of the VAT it paid. That's unrelated to what anyone can reclaim. My understanding is that Germany has reciprocal VAT agreements with a bunch of countries so if your employer is in one of those countries it may be able to reclaim, but since the US isn't one of them I haven't looked in detail. R's, John
Re: IAB Statement on Dotless Domains
Since http://dotless won't work in any host that has a default domain configured, ... It's worse than that. If there is a name "dotless" in the default domain, it'll find that one, otherwise it'll fall back to the TLD. Point your browser at http://dk/ or http://tm/ and see what happens. For extra fun, try https://dk/ or https://tm/ Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: IETF, ICANN and non-standards
On Jun 19, 2013, at 3:43 PM, John Levine wrote: Assuming we care about stability and interoperability, wouldn't it make sense for the IETF to spin up a WG, collect these drafts, clean up the language, make sure they agree with the widely implemented reality, and publish them? The only way that something like this can happen is for some current or future IETF participants to do it. "The IETF" doesn't spin up working groups. IETF participants do. I'd do it if there were other interest. 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: Issues in wider geographic participation
Translation ?? This a very old discussion and moot point, people that have interest to participate in this type of international forums and processes SHOULD learn English. Another barrier. Anyway we are talking about remote participation only. You guys would know better than us gringos, but how likely is it that having translation available for live sessions would encourage people to use their limited English to work through drafts and try some e-mail? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: Issues in wider geographic participation
On Mon, 27 May 2013, Yoav Nir wrote: LCD? LDC, Less Developed Country, what used to be called the third world, now that the second has been bought by the first. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: financial fun with an IETF Meeting in South America
Is this above advice from Tripadvisor correct? I believe so, but when I was there a few years ago for the ICANN meeting, excess cash was not a problem. It wasn't hard to estimate how much cash I'd need, and whatever was left I spent at the airport. The wine they drink in Argentina is often better than the stuff they send to the UK (which isn't bad) and much cheaper. Take some home in your suitcase, even if you have to pay duty it's a bargain. This still doesn't mean I think a meeting in South America is a good idea, though. See other messages. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: Sufficient email authentication requirements for IPv6
Like I said, things have changed since 1996. Indeed they have. Email is much less reliable now than it was then. Agreed. But it's not the DNSBLs, it's all the other stuff, notably heuristic content filters, that we have to do to deal with the 95% of mail that is spam these days. I track what happens to the mail going out of my system, and the only time in recent history that any of it got blocked by significant* DNSBLs was when someone found a bug in my submit server and sent several thousand spams through it. Oops. I can't really blame people for not taking my mail until I'd shown that I'd fixed it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. * - i.e., ones used by a perceptible number of recipients smime.p7s Description: S/MIME Cryptographic Signature
Re: Time zones in IETF agenda
I've said it before: just go back and forth between Iceland and Hawaii. Oh, and maybe Minneapolis for old-time's sake. ;-) New Zealand, please, in easy to remember UTC+12 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Time zones in IETF agenda
Florida will be at UTC-4 (which we call EDT) as of early Sunday morning, so a meeting at noon in Florida any day of IETF 86 will be at 0800 UTC. Yow - wrong way around. The correct time for a noon meeting in Florida is 16:00 UTC (12:00 - (-4:00)). Sorry, you are quite right. 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Newcomers [Was: Evolutionizing the IETF]
I wonder how you measure/count "IETF participants"... Do you measure participants based on subscriptions to IETF mailing-lists? -- If so, how do you assign a location to the plenty of gTLD addresses? (including those at gmail.com) I'm guessing based on the mail I see on the lists I'm on and the drafts I look at. I really don't think there's a vast group of Latin Americans or south Asians or Africans lurking behind gmail addresses. As I think I've said many times, I think it would be great if we got more activity from underrepresented parts of the world, but the way to do that is to get people active on mailing lists and writing drafts, not to have unaffordable ICANN-style road shows. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: Newcomers [Was: Evolutionizing the IETF]
Sure. Since we agree that there is no way to pay for the extra costs I wouldn't say that we agreed on that. We do not want to look how to pay the extra cost, we are simply not interested. We agree on this. Oh, sorry, I didn't realize this was a purely hypothetical argument. Never mind. 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]
Comparing with the ITU who does tour the world, organizing workshops in far away places, I really think we should be trying a little harder to be more open. The IAOC has often noted that holding meetings in more exotic places is considerably more expensive, the hotels and other services just charge more. Keeping in mind that the IETF is paid for by a combination of conference fees and an annual grant from ISOC, not governments, who were you expecting to pay the increased costs? Also, why do you believe that people people need to go to meetings in person rather than joining the mailing lists where the bulk of the IETF's work gets done? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: Newcomers [Was: Evolutionizing the IETF]
As Arturo says, having people that traditionally go to an IETF meeting travel to (for them) far away places and (for them) new cultures, do definitely open their eyes to how large our world is. I think that learning about other parts of the world is swell, but I don't think the IETF should be a travel agent. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: mailing list memberships reminder -> passwords in the clear
Why does the "mailing list memberships reminder" send passwords in the clear? Because that's what Mailman does. Send code. And that's acceptable to the IETF? You're kidding me, right? I can't speak for the IETF, but I do note that the same password notices have been going out on the first of every month for years. You just noticed iit now? And once again, if you think it should do something else, send code. We're volunteers here. Assertions that it is very important for someone else to do work that you're not prepared to do are rarely effective. R's, John
Re: [IETF] Re: Recall petition for Mr. Marshall Eubanks
As a small point of procedures, no one is sending an actual signature. It therefore would provide a modicum of better assurance for signatories to send the email that declares their signature directly to the ISOC President rather than to the person initiating the recall. If you're concerned that some of the 20 people who Olafur says signed his petition did not actually do so, please say that. If there's some other problem, what is it? Or if you're worried about unsigned or forged mail, why are you assuming that any of the messages on this list are real? The list software uses only the easily faked From: line to verify senders. R's, John smime.p7s Description: S/MIME Cryptographic Signature
Re: Antitrust FAQ
Saleguy: "Buy my product. I'll sell it to you for US$xxx." Potential customer: "OK, but only if you guarantee me that that's your best price to any customer for the next 6 moths." Salesguy: "OK." It's only price fixing if it's a discussion between vendors, but I suppose I see how people who didn't understand the issues could misunderstand it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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. Exactly. This sort of thing is wh a policy is needed, although I note in passing that the folks at this hypothetical might want to read up on the Streisand Effect. Note that I phrased it as a polite request, not a threat. And again, this is best developed with counsel. A very emphatic +1 to this. Sure, but keep in mind that it's one thing to minimize legal risk, is not the same as minimizing cost or complexity, or doing what's best for the IETF and the community. 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: the usual mail stuff, was IETF...the unconference of SDOs
try reading the nov3 list in a text mua. and do not tell folk what mua they should use. Gee, this whole argument is about telling people what MUA to use. Apparently nothing written since about 1996 need apply. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: [IAB] IETF 92 in Dallas!
Fond memories of my first IETF... We were stuck at a highway exit for 4 hours unable to either cross the swollen river that had been a side road minutes before or to go back. I got to DFW, called the place I was staying (a motel across the street from the venue) who told me that the water was several feet deep in front, so I snagged an overpriced room at the airport Marriott for the night. On 8/16/12 4:48 PM, Tony Hansen wrote: ah, the memories ... Tony Hansen On 8/16/2012 2:31 PM, John Levine wrote: 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 Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: So, where to repeat? (was: Re: management granularity)
The thing is that I don't need a flight to DFW to YVR for this coming week and I don't see the prices you do either. I did not buy my tickets at the last minute and believe it or not, I'm actually not lying about what I paid for my tickets to YVR nor to Beijing. I made a very simple statement of fact based on my own experiences. I can't fathom why you felt obligated to spend time trying to show that I was lying. Sigh. If you'll review my previous messages, you'll note that I never said you were lying. Is there some reason that it's important to put words in people's mouths? But since non-stop tickets from Dallas to Vancouver are easily available for prices far below any plausible price for a ticket to China via aa.com and the usual travel agents, something peculiar was evidently going on when you bought yours. R's, John
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did not do them any favor - I did the IETF a favor (as the then ISOC VP for Standards) Really, if you didn't make the opposing party pay for your time, you did them a favor. It's absolutely expected to pay hostile witnesses for their depo time. (If nobody mentioned it, why would they offer to pay if you were willing to do it for free?) If it happens again, pick the highest rate you think you're worth and double it. If you want, donate the money to the IETF trust and encourage them to use it for better cookies. R's, John
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember) there were no significant expenses - the depo was in Boston & my only expense was a few hours parking - the depo was done in the office of the law firm that was providing the IETF with pro-bono legal services at the time If the opposing party didn't pay you for your time in the depo, you did them an unnecessary favor. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: [IAOC] Feedback Requested on Draft Fees Policy
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.") Please note : out of pocket expenses (if someone has to travel to a hearing, say) would be reimbursed, but IETF volunteers will not be paid from these fees. If you know, how often have people been deposed on behalf of the IETF, and how long does it typically take? My thought is that in a depo or trial, the other side pays both for the expenses and the time of the person being deposed, so it would be good idea to say up front here's what it'll cost if you want a live witness. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: New Non-WG Mailing List: IETF-822
Do we have to rehash all of this stuff AGAIN? R's, John Huh? ISO/IEC 646 IRV (another candidate for a FoPSCII precursor) replaces the ASCII $, not #, with that universal currency symbol. As for that vertical bar, sufficiently elderly practitioners of the art of Character Confusion and Coding (CCS) will recall that the ancient Earthling-Based Convention for Difficult Information Coding included two peculiar characters: a mathematical "not" sign that closely resembled Unicode's "⌐" (U+2310) and that broken vertical bar. Those characters spawned multiple wars over how they should be mapped into "ASCII" and "ISO/IEC 646" with one group arguing for caret and (solid) vertical bar, another for tilde and exclamation mark, and a third for exclamation mark and [solid] vertical bar. After much bloodshed, 16 and 32 bit character sets were invented so that almost everyone could contemplate their cakes while eating them and continued dissenters were tortured until they repented. Those battles were repeated in the development of FoPSCII when it was noticed that the 5th character of the Klingon alphabet was confusable with both the not-sign, Greek upper case Gamma, and Latin "r". In addition, the Klingon numeral 8 was easily confused with Cyrillic "Ж". This created a variant problem that the Intergalactic Consortium for Arbitrary Names and Numbers could not dismiss because of some of the advocates had a more effective means of persuasion than merely hiring lawyers. :-(
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Most provisioning systems ... I well know they don't because they are still stuck in 1980's think mode. ... Hi. Could you give some concrete examples of DNS provisioning systems that let you enter arbitrary RRs? I've never seen one in the wild, other than the one I wrote for myself. 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: provisioning software, was DNS RRTYPEs, the difficulty with
Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. ... Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? Most provisioning systems ... Hi. Could you give some concrete examples of DNS provisioning systems that let you enter arbitrary RRs? I've never seen one in the wild, other than the one I wrote for myself. Yes, I know that hypothetically they could do all sorts of stuff. But they don't. 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: provisioning software, was DNS RRTYPEs, the difficulty with
Gee, by sheer random walk this has wandered back to the original topic, that provisioning software is the major bar to deploying new RRs. Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. I couldn't disagree more. Other than my own homebrew system, all the provisioning systems I know support a handful of specific RR types and make it somewhere between painful and impossible to install anything else. Godaddy's is a good and very large example of this. They have a "wizard" to create an SPF record, but it turns out to be a TXT record. If you want a real type 99 SPF record, you're out of luck. Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? 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: 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 authoritative server should be returning NOERROR / NXDOMAIN not NOTIMP Yes, we all know that. My point, which I would have thought was obvious, was that it's been a long time since I've run into anyone whose server was broken like that. As I said, it's not an issue. 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
However we do have standard presentation/entry formats defined and a good front end will accept those as well. Sigh. Now we're back to "people who don't do it my way are wrong", so I guess we're done. 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: provisioning software, was DNS RRTYPEs, the difficulty with
They're not implementation specific, but they're also not required to interoperate, as the wire format queries and responses are. They are a interchange standard as per RFC 1034. Yes, we all know that. But as I presume you also know, there are plenty of DNS servers that store the zone info in other ways, ranging from djbdns mutant syntax text files to various databases. Whatever the server uses, the provisioning system better match. The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. That is one implementation. But it's far from the only one. My system has a web front end that lets my users edit groups of their djbdns RRs, which it stores in a database. Once an hour, a perl script goes through the database, regenerates the mutant text files, and stuffs them into the name servers. It's not fabulous, but it gets the job done. 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: provisioning software, was DNS RRTYPEs, the difficulty with
I was also going to mention that. There's a lot of different formats for zone file data, with BIND-ish master files being only one of them. DNS master files are specified in RFC 1035 so it's wrong to imply they are implementation-specific. They're not implementation specific, but they're also not required to interoperate, as the wire format queries and responses are. 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: provisioning software, was DNS RRTYPEs, the difficulty with
Input -P-> DNS server -D-> DNS stub -Q-> Output P is the provisioning I think you want to break that into the provisioning interface and the data format it produces that the DNS server consumes. (My reason for that is we have a specification for at least such format, with all that implies.) I was also going to mention that. There's a lot of different formats for zone file data, with BIND-ish master files being only one of them. We seem to believe that the "D" part is deployed so that adding new "unknown" RRTypes is not an issue. I think this is correct, but OTOH someone recently asked about possible issues in this area, and if I remember correctly, received no response. 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. Problem is then in "P" and "Q". I personally don't see a big problem with "Q", but others clearly do so we need to leave it in. I'm not aware of problems, but I don't use Windows which is where the problems are supposed to be. 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: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
I do prefer the latter as well (and yes, happy to remove the restriction), but I don't feel very comfortable pretending that tunneling wouldn't happen. Of course people will tunnel stuff. But will they all tunnel it the same way, in which case a standard could be useful, or will they each have their own hacks? Given the vagueness about how you can tell that something should come out of the tunnel back into the envelope, it sounds more like the latter. 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: provisioning software, was DNS RRTYPEs, the difficulty with
Well for BIND it's add a new file that defines the type's methods and recompile. That isn't a whole new version. Recompile -> new version. These days, most server systems are built from precompiled packages. Check your local Linux box for an example. Which is why there is a format for unknown types. You can cut and paste them as easily as known types. Unfortunately the provision systems often do a subset of RFC 1035 types let alone anything newer. Basically they are often just plain garbage. Well, yes. Wouldn't it be nice to have provisioning systems that could be configured to support the RR types you want to use? If so, you might want to look at my draft. Until provisoning systems accept UNKNOWN record types they will always be a bottle neck. Without that you will have to wait for the change request to be processed. Given the history just getting records added to most of these system it will be forever. was unusually painful, since it requires adding a parser for IPv6 addresses. (Having hacked it into my provisioning system, I speak from experience.) Most new RR types are just strings, numbers, names, and the occasional bit field. 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: provisioning software, was DNS RRTYPEs, the difficulty with
Skipping over all the parts I agree with, and noting that two decades of telling people to upgrade their DNS servers frequently hasn't worked, we get to ... I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors Checked for syntax errors? By what? The whole point of the extension language is to describe the syntax of new RRs as data that provisioning software and nams servers can read at runtime, so you don't have to patch your software for every new RR. It also can be translated into an HTML form for the RR that the user can fill in, the provisioning software can syntax check by field, so you don't have to build an entire BIND master file parser into your PHP web scripts. And, of course, your DNS server uses the same data to parse new RRs without being patched. 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: provisioning software, was DNS RRTYPEs, the difficulty with
By the way, what's your opinion of draft-levine-dnsextlang-02? It isn't clear to me what problem you're trying to solve. For resolving name servers 3597 should be enough. For authoritative name servers your idea is sort of interesting, but generally upgrading the software to pick up support for new RRtypes is a good idea, since you'll also pick up new security fixes, etc. Oh, wow. Now I see the problem: people here are totally unaware of what using DNS software is like if you're not a DNS weenie. If you think that it's reasonable to require a new version of your DNS software every time there's a new RR, you've conceded total defeat. On most servers I know, software upgrades are risky and infrequent. It could easily take a year for a new version of BIND to percolate out of the lab, into the various distribution channels, and to be installed on people's servers, by which time everyone has built their applications with TXT records and it's too late. Moreover, the servers aren't the hard part, it's the provisioning systems. You and I may edit our zone files with emacs, but civilians use web based things with pulldown menus and checkboxes. If they can't enter an RR into one of them it doesn't matter whether the name server supports it or not. This latest round of teeth gnashing was provoked by discussions in the spfbis WG, where we're wondering whether to deprecate the type 99 SPF record. Among the reasons it's unused in practice is that nobody's provisioning system lets you create SPF records. The point of my draft is that it's an extension language that both name servers and provisioning systems can read on the fly. Add a new stanza to /etc/rrtypes and you're done, no software upgrades needed. The risk is much lower since the worst that will happen if the new stanza is broken is that the provisioning software and name servers will ignore it, not that the whole thing will crash. Sure, there are some RRs with complex semantics that can't be done without new code (DNSSEC being the major example), but most RRs are syntactically and semantically trivial, just a bunch of fields that the server doesn't even interpret once it's parsed the master records or their equivalent. Until the DNS crowd admits that provisioning systems are a major bottleneck, and telling people to hand-code more types into them isn't going to happen, there's no chance of getting more RRs deployed. 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
SPF is listed. http://dyn.com/dns/dns-comparison/ Hmmn, only on the premium $30/mo and up packages, not on the cheap ones. There must be a moral here. By the way, what do you think of draft-levine-dnsextlang-02 ? 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
In your little dialog, the boss was entirely reasonable -- the practical benefit from implementing SPF records would be zip. Or, put more simply, your conclusion seems to be that we can never add new RRs. Given that adding new RRs is crucial to the growth of the Internet, I reject that conclusion completely. No, I'm saying that it would be a lot more productive to help people improve their provisioning systems, rather than say how stupid they are for not doing what we want. Even now, there are precious few provisioning systems that support records, and even fewer that support DNSSEC. I hacked support for into mine, but as far as I can tell, none of my users other than me is using them. I added SPF records, but then took them out when my DNS mirror complained that he was getting strange error messages. By the way, what's your opinion of draft-levine-dnsextlang-02? 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: (DKIM Authorized Third-Party Signers) to Experimental RFC
ATPS essentially modifies name extraction, by making it a two-step process. The first step is the usual one, with d=, for use with validation, but the second one takes the domain in the From: field and makes it the output string to the assessment process. If you're referring to the second paragraph in section 5, I agree that the second sentence should go, or at least be rewritten to clarify that the client is supposed to pretend that the message passed ADSP. If it's anything else in atps-11, you'll have to help me out with references to specific language. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
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? John, if they'd had no relevant rules, it would probably have read "100. By their failures to promulgate appropriate SSO Rules, ... Quite possibly, although it seems to me that it's a much easier legal argument to say they didn't enforce the rules they had than, that they should have been prescient and known what sort of rules would have avoided a suit. I can't see that having a set of rules would do anything other than give potential litigants a stick to beat us with. 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
I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. In this case, we've seen references to /continuing/ interoperability problems when trying to use docx. I wouldn't disagree, but if we mean easy to interoperate, let's say so. Word 97-2003 format is totally proprietary, but is now sufficiently widely reverse engineered that it interoperates pretty well. On the other hand, ODF format is well documented and interoperates well among different software that support it, but since old versions of Microsoft Office don't support it, we get complaints. 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: Plagued by PPTX again
* - "You don't want to get locked into open source", credited to an IBM salesman Because once you try an open source mail reader, you'll never want to go back to Lotus Notes? :-) That was way before IBM ever thought of buying the remains of Lotus. 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: authenticated archives, was https
In the case of http: access, MSIE just times out. Repeat the request and it usually works; something has changed (could even be DNS). It works fine for me in IE on Windows 7 on an ordinary consumer DSL connection, click through the warning about the expired cert and the pages come right up. I suspect you will find that "my tools are broken" is not a persuasive argument to get people to remove security features, even fairly lame ones like this. Recently, DKIM was added to outgoing mail. The mail still works, the cost to me is small and the benefit - to me -is nil. Who decided to put it in? The IAOC, I expect. I find DKIM useful to skip mail filtering. Are you saying that people are not allowed to use RFC-standard security features until you, Tom, approve of them? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
I'm not unalterably opposed to subject tags, but I believe that the IETF's dogfood is of the List-ID: flavor. Which WG list do you suggest should be the guinea pig? Or shall we change them all at once to remove the dreaded subject prefix? :) I said I'm not unalterably opposed. My advice would be to leave well enough alone. If the IETF used a better list manager, the subject tag would be a per-user option, but n ... 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: DKIM Signatures now being applied to IETF Email
But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. I can't help but be baffled at the lack of a PGP or S/MIME signature on your message. 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. I don't understand why the setup is OK for reverse DNS but not blacklists. One obvious reason is that the most widely used DNSBL server doesn't return NODATA vs. NXDOMAIN according to current standards, so probing and NXDOMAIN synthesis doesn't work. I'm planning to fix it, but it'll take a while. 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: Comments surrounding draft-iab-dns-applications-01
The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. For IPv6 if you did the reverse of /48, /52, /56, /60 and /64 prefixes, which matches delegation patterns along with NXDOMAIN synthesis, you would still be fine. You stop the search on NXDOMAIN or data with perhaps a new value which says to continue searching for white listed records. One could even start with /32 if one is worried about spammers pretending to be ISPs. I don't necessarily disagree, but now you've just upgraded the DNS (NXDOMAIN synthesis is far from universal) and layered a probing protocol on top of it. We can have a theological argument about whether that counts as "using the DNS". R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. Or you just tune the cache retention times. For NXDOMAIN/NODATA that's 3 hours by default for named but could be tuned down to 10 minutes or lower without ill effects. RFC 2308 recommends 1-3 hours. DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. Doesn't really matter how low it is if you have so many entries that they force out the useful ones. I also don't see the point in worrying about this. Caches cope with spammers using a different From domains on each piece of email which is looked up in the DNS. Modern spam filters don't usually look up the author domain, since it's usually a genuine address taken from the spam list so it's unrelated to the real sender. Even if they did, universe of domains that exist is a vastly smaller set than even IPv4 addresses, and one which caches pretty well since so many of them are at large sites like Yahoo and Hotmail. In any event, we can argue about how good or bad an idea it is to use IPv6 rDNS, but that's tangential to the issues of deciding what are reasonable applications for the DNS. If you're right and rDNS caches well, it's a good application for DNS. If I'm right and it doesn't cache at all, it's not such a good application. 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: Comments surrounding draft-iab-dns-applications-01
Reverse IPv6 caches well. You just can't pre-populate servers with PTR records for all 2^64 ptr records in a normal IPv6 subnet. You need to use tools that add records for nodes that actually exist. Those tools are a decade old now. Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. 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: Comments surrounding draft-iab-dns-applications-01
So my advice would be to back up and write down in one or two sentences what problem this document is supposed to fix or at least describe, and then see how much of the rest of it might be salvaged. I was thinking of storing data in DNS and the document proved valuable to determine whether its a good idea or not. I mean, not whether it is technically feasible, but whether it makes sense at all. So, while the mission statement may be a bit unclear, it's definitely a useful document. I agree that such a document would be useful, but this isn't it. Applications are poorly suited for the DNS if they need fuzzy matches, or range queries, or have query patterns that don't cache well. (IPv6 rDNS has that last problem.) You can argue about how large query and response sizes should be, although DNSSEC has forced an answer to that one. Applications that map fixed query names to (more or less) fixed responses work fine on top of the DNS, even if the query doesn't look much like a host name and the response looks nothing at all like an A record, e.g., NAPTR. A document that described the actual technical architecture of the DNS, without confusing it with the design of applications built on top of the DNS would be a good idea. I suppose I could try and write one. 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: whine, whine, whine
San Diego is much easier to get to than Quebec City, since multiple air carriers serve it. You can't fool me. I've been to both. Quebec is a lot closer, and the food is better. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Getting to Quebec City
Why didn't you fly ORD-YQB? There's a 7pm flight that gets in around 10:23. It had to be cheaper than a hotel and train ride. Probably not available at the time I made the booking... Expert flyer says it still has four seats available, with fares in Y B M U H Q V classes and one way fare of $307. You can change your ticket and save the hassle. 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: Getting to Quebec City
As far as renting a car, it is likely a very good choice for anyone that is arriving in Montreal later in the day. I have a choice of one direct flight to Montreal that puts me arriving in Montreal > 7pm. FYI, there is a direct bus from YUL to Quebec that leaves at 20:30. With Wifi, even. It's a reasonable choice, and about $100 less than a one way car rental. The Quebec bus station is adjacent to the train station and a quick taxi to hotels. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Why don't we run it the opposite way: -IPv6 by default, else: -Legacy: just run IPv4 with some kind of NAT. If the answer to that question isn't obvious, I don't think I can help. 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: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. Well, I couldn't afford to go, so I can't say you're wrong, and I don't know why I didn't see that on the list. I guess on procedural grounds, you win, even though we all know that there's nothing B or C about this document. 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: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
As chair, I can say that consensus was to make this normative, not experimental. With the best will in the world, I was there, and I saw no such consensus. The closest thing I can find in a quick search of the archive is this note, which says that the group agreed on one thing (that lists should sign their mail) but not on anything else: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014630.html This document does not describe existing signing practice. It makes a variety of highly speculative recommendations unsupported by experience. It is an experiment. 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: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
I'd be very surprised to find that mention of "cron" in an RFC is "unprecedented". Maybe I'll download the RFC set, have Google do a word index on it, and see. RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs. There may be others, but I found those with a simple grep. (If anyone was planning to ask what grep is, don't.) I don't see that "automated mail robot with an MTA" is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the "cron" Unix system utility). There's no need to change the current language. RFCs have been referring to cron jobs since 1997. R's, John___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
I think it's best to have an example. "cron" seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one. If not, changing 'such as "cron"' to 'such as the "cron" UNIX utility' seems a better change to me. Anyone who's ever managed a Unix or linux system knows what cron is. It's a fine example. Indeed, on my own servers, there are cron scripts that push out daily digests which are DKIM signed on the way out. 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: How to pay $47 for a copy of RFC 793
(Institute of Electrical and Electronics Engineers) and its publishing partners. Unless I am mistaken, RFCs aren't IEEE publications. Indeed they aren't but "publishing partners" offers a lot of leeway. 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: How to pay $47 for a copy of RFC 793
Yes, you can find it in Google, but Google isn't a particularly good place to look for engineering papers. Xplore is. RFCs aren't in the ACM Digital Library, either, same problem. Nor is it in Google Scholar, which is generally where I look first. There's a lot of overlap. I'm pretty sure that everything in Xplore and ACM DL is automatically in Scholar. This isn't an enormous project, but it requires figuring out which online libraries are worth getting into, making the necessary arrangements with them (which may or may not involve money), a batch process to load in all the existing RFCs, and arrange with the production house to ensure that each new RFC gets listed as it's published. Most of these systems include abstracts and forward and backward references, which will doubtless require some debugging to make them work reliably. Like I said, it's a good project for the new RFC series editor. It should be a lot easier than deciding how to put Chinese names into RFCs. 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: draft-housley-two-maturity-levels-06
This suggests that perhaps we should rename "Proposed Standard" to "Not a Standard But Might Be One Later," promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them "RFC"s. Maybe we should have a "PROP" series for PS docs, and only give them "RFC" numbers later, when they progress. Well, you know, the "Not a Standard But Might Be One Later" really are requesting comments. 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: Buckets of spam coming through IETF lists
Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. DKIM is directly designed to address this... What do we need to do to put it in play? Probably more than you want to try to do in a hurry. It seems to me there are two separate problems. One is that a bad guy is sending spam with fake IETF and IRTF return addresses, something that DKIM can mitigate. The other is that the mailing list software is getting confused by multiple From line addresses, which is probably buggy code that wasn't written to handle them. For the former, first you adjust the IETF's mail servers to put DKIM signatures on all the outgoing mail. Once that works, you adjust the incoming spam filters so that mail that purports to be from the IETF or IRTF and doesn't have a signature is treated as spam. (Spamassassin can easily be tuned to do that.) You don't want to do that in a hurry, because there always turn out to be considerably more outgoing mail paths than you thought, and finding and securing them all is tedious. It's not immediately apparent to me why Mailman is letting that mail through, since the addresses on the From: line aren't all subscribed to the various lists. As a band-aid, it's straightforward to add a Mailman spam filter like from: .*<.*>.*, which will catch any multiple from lines and either hold or discard them. 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
Buckets of spam coming through IETF lists
Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. Given the amount of legitimate mail with multiple From: addresses (none, in practice) a quick shim in front of Mailman should deal with it until someone can go fix the underlying 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 -- Forwarded message -- Date: Thu, 31 Mar 2011 14:47:22 -0700 (PDT) From: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu To: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu Subject: [IRSG] An offer you can't refuse ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
The usual way to generate a TOC is to use .tm directives which write the TOC to the standard error, which you capture in a file using the usual Unix shell redirection. Then you rerun nroff using .so to include that file up at the front where the TOC goes. That's what I understood from previous threads, but I had no idea how to get that second output stream (I was staring at ".open" earlier today). PS: You could use .open and .write but they are a recent (circa 1990) addition so I haven't gotten around to using them yet. 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: Automatically updated Table of Contents with Nroff
.Tc 2 4.2 12 "Efficient lossless packet compression" In this example, this is second level heading 4.2 on page 12. It's easy enough to generate whatever sort of TOC you want, and the usual nroff page break stuff does the pagination. So is .TC plain nroff or in some package? It's a macro. Plain nroff formatting is all very low level, e.g., skip a line, switch to font 3, set line length to N picas. I have a bad habit of writing my own nroff/troff macros so you're welcome to whatever I have lying around, but I doubt it'll be directly useful. 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: [ietf] DNS spoofing at captive portals
Not sure I see the relationship between malware spam and DNSSEC. See below. But we have real situtations where the opposite is true, quite possibly more often than the other way around. Hmm. Are you talking about SiteFinder-like services? Not really. There turn out to be a significant number of domains, in the hundreds of thousands at least, that are purely evil. Some host websites with drive-by malware installs, with victims pointed there by links in spam or various malicious SEO tricks in search engines. Some are command and control (C&C) hosts that existing bots use to update themselves and get new instructions. Last year the Conficker Working Group did a great deal of quiet work preemptively registering or reserving the domains that the conficker 'bot tried to use to contact C&C. See this for more info http://www.confickerworkinggroup.org/wiki/pmwiki.php/TLD/TLDOperators They were reasonably successful until the bad guys switched to ccTLDs that were less cooperative about reserving domains. Unless you are a malware researcher, it is overwhelmingly likely that any request for one of those domains is from a 'bot, not from you, and if a large ISP like Comcast intercepts them, it makes a significant difference to the amount of active malware on their networks. I have even heard of ISPs redirecting C&C requests to a local server that sends the bot instructions to turn itself off. (I don't know whether Comcast does that, and I doubt they'd tell me if I asked.) As I said in a previous message, I am not a big fan of rewriting NXDOMAIN, and I was on one of ICANN's advisory committees and helped them get rid of Sitefinder, but if an ISP does it on consumer networks where there aren't supposed to be servers, the damage from doing so is hard to show, so I'm not inclined to make a big deal about it. So anyway, there are some good reasons for ISPs to mess with the DNS results their caches provide their users. If we ask them to use tools that will keep them from doing so, it won't happen. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
presuming your statement about an inversion of the stated trust model is correct, can we dereference "friendly" and "hostile" to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? Those are all excellent questions, and if I had good answers I would answer them. I suspect that for most consumer ISP users, their least bad choice is to get their trust policy from the ISP. The ISP may well be awful, but for nontechnical broadband users, it is less awful than any plausible alternative I can think of. They want to maximize their revenue, but they probably don't want to install spambots on your PC and wire the contents of your bank account to Belarus. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
It will be interesting to see what will happen to these "services" when DNSSEC is used more widely. Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Malware that infects browsers and rewrites bank transactions on the fly is a huge problem, particularly in Europe, and requires no DNS funny business at all. We can certainly imagine attacks that depend on DNS poisoning, but any tradeoff that makes it easier to get infected by malware is, for typical PC users, a foolish one. Be careful what you ask for, and all that. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Varying meeting venue -- why?
If someone offered to sponsor a meeting there, I bet the IETF would consider it. First, it actually has an airport, and second there is alternative public transportation: bus service from Syracuse, Rochester, Buffalo, etc. That should fit right in with Maastricht. I get the strong impression you've never been to Ithaca. If you can't get a spot on one of the small planes that flies to the Ithaca airport you will find that it is so slow and painful to get here from the airpots in Syracuse, Rochester, Binghamton, Elmira, or Buffalo that it's easier to fly into NYC and take the five hour bus trip from there. One time I rented a car in Ithaca and dropped it off in Rochester two hours later, paying a drop fee, because that was far easier and cheaper than any alternative. It's a swell place to live, but it'd be miserable for a large meeting. It's not Maastricht, even after Maastricht gets rid of the drug tourism. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Varying meeting venue -- why?
but when you tried to get here, you'd be saying why can't we meet some place convenient, like Maastricht? That's what everyone says. I wanted to have an IETF in Ithaca back in 1990 or so but the lack of airline seats was already too much of a problem, alas. Bummer. The beer is much better now. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The anonymity question
In the sense that an email address is in fact used by an identifiable person, it is an identity that is verified in the process of joining a list. This sounds to me like a situation where the Internet has evolved underneath us. Until about 1995, email addresses were generally tied to accounts assigned to known users of host systems, an employee, a paying customer, or maybe for us hobbyists, a friend. Then in 1996 Hotmail came along, and now we have enormous mail systems whose managers have no idea who their users are beyond the IP addresses they connect from. The ability of users to sign up from throwaway accounts doesn't seem to have been a big problem in practice, but it does make it hard to claim that the lists are free of submarine patent trolls. Once again, there isn't necessarily anything to fix here, but a useful privacy policy needs to work in our environment where depending on the context a user can be entirely anonymous (download a web page), fairly well verified (pay with a credit card), and a lot of points in between. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
What does a privacy policy mean?
What I don't understand is the amount of arm wrestling that happens on this list. You're certainly right, there's a culture of nitpicking. In this case I think some of the issues are nitpicks, while some are significant. The IETF is very peculiarly organized, which suggests that it would need a somewhat peculiar privacy policy. Here are some questions that I think are not nits: Although the IETF per se has no legal existence, ISOC, the IETF Trust, and perhaps other things I haven't noticed do. How should an IETF privacy policy relate to the ISOC's existing privacy policy? Does the IETF Trust need a privacy policy? The IETF potentially collects PII in various ways, including publication of Internet Drafts and RFCs, messages on mailing lists, registration info for meetings, and activities in meetings. Meeting activites include paper documents (meeting attendance sheets), electronic session presentation material, oral session material which is transmitted over the voice feeds, jabber chats, and random traffic sent over meeting networks. Are there other forms of PII? Should a privacy policy treat them all the same, or differently? Some people have argued that it should be possible to participate in some or all IETF processes while remaining partly or completely anonymous. Is this a reasonable expectation? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - still a bad idea
The IETF has a legal home, named ISOC. Let me rephrase: "Do you think ISOC is not subject to the laws of Europe?" Of course they are. But that's OK, since ISOC has had a privacy policy in place since 2006, which makes specific reference to the "safe harbor" policy kludge worked out between the US and EU: http://www.isoc.org/help/privacy/ Good grief. Indeed. Do we agree that this means we're done? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - still a bad idea
Exceptionalism really does not work very well as a legal strategy. I'm not saying that the IETF is unique in the universe, but I am saying that all of the arguments advanced so far for privacy policies are relevant to corporations with employees and revenue and contacts, which the IETF definitely is not. Someone pointed out that the IAOC, which does have a legal existence, could find a privacy policy useful, which is not unreasonable, but I do think that anyone who proposes such a policy should at least be familiar with the (non)structure of the IETF and identify what aspects of it apply to what four-letter bits. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
between the XML and the final output. If we could agree that the final XML was authoritative, What, precisely, do you mean here? Do you mean that there would be NO text form of an RFC that was authoritative, or do you mean that BOTH the xml2rfc form and some text-equivalent form (say, .txt or .pdf) would be authoritative? The XML is authoritative, the text is derived from it. This presumes that we improve xml2rfc so it produces text comparable to the stuff we have now, and has sufficient change control and regression testing that we can count on future versions of xml2rfc to produce the same output with the same input. As I expect you know, multiple forms are quite common in other SDOs. The ITU typically publishers authoritative PDFs, but also provides Word documents for people who want to cut and paste. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
Indeed, I know plenty of people these days who have no idea today how to produce an ASCII file with only tab, CR, and LF formatting characters. Type. Save as text. How hard is that? Good guess, but wrong. If you do that, you will still generally get various non-ASCII quotes and punctuation marks unless you carefully configure your WP program not to insert smart quotes or whatever they call it. I have actually written a few drafts that way. The text part isn't hard, but the hard breaks at every line are, and the hard breaks at every page even more so. Tools do create those don't exist in today's world. Right. Again, you've figured it out, but most people haven't. I write books in emacs with nroff-like markup, but my editors consider me pretty strange. Lucky for them, I have scripts to turn my stuff into RTF which works with the the tools they use. As many people have pointed out, the world has moved on since 1980. (No, I'm not suggesting the IETF use Word.) xml2rfc is very hard to use for anyone who has otherwise no experience with XML just because it's XML (the proper nesting and terminating are hell) and also because at least 50% of the xml2rfc commands aren't documented. Are you assuming that the only way to write XML is by hand? Aw, come on. I don't understand why we would even need to discuss the output formats, you can get HTML and PDF without trouble, even though the text version is authoritative. It's the input that's the problem. Now I'm confused. Even though the RFC Editor mostly uses XML internally, they don't publish the XML, and there is a hand-edit stop between the XML and the final output. If we could agree that the final XML was authoritative, and if necessary let them hire someone to fix xmlrfc so it can produce the text version without hand editing or postprocessing, that would be a big step forward. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
for the record, sink.arpa document was my idea and Joe volunteered to help it has nothing to do with his day time job but is related to something that Joe cares about, having explicit documentation of special cases. In that case, could you work with him to add language to the draft that explains why SINK.ARPA provides something usefully different from FOO.INVALID? The reason I keep harping on this is that this looks to me a lot more like a documentation problem than a technical problem. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reserved names draft, was Defining the existence of non-existent domains
These are reasonable things to add, but I'm waiting to see if there's agreement that it's worth moving forward. On the table at 2.1.4 you need to add LATNIC that seems to be also reserved by ICANN, not sure why they missed it on the DAG but it's on every single Registry Agreement. You're right, but since it's not in the guidebook, I have nothing to document it. Perhaps this shows why it would be a good idea to create these registries, so missing entries are more immediately evident. For 2.2.4, I believe all the names listed in 2.1.4 are also reserved for second level domains and you are still missing a place where to record the names reserved by each Registry (if any) and listed on each individual Registry Agreement (http://www.icann.org/en/registries/agreements.htm), for example ABOUT.INFO, not sure if IANA has to be responsible to keep the list for them but it would be nice if they are all listed in a single place. What about tagged domain names like "bq--1k2n4h4b" or "xn--ndk061n" and one or two character names ? They're all in appendices to the various gTLD and sTLD agreements. I'm happy to add them but since it's a lot of work I'll wait and see where we're going. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
Yeah. As far as I know, it is quite uncommon for applications to hard code treatment of .INVALID. But you seem to be saying that they do, and that causes problems that SINK.ARPA would solve. Tell us what they are. There is one case where knowledge and special handling of the name may cause problems: DNS "Liers" i.e. specialized DNS resolvers that make all non-existing name exist that do not generate "lie" for sink.arpa. That strikes me as appropriate for a BCP, not a new domain. The non-existence of .INVALID has been well-documented since RFC 2606 in 1999, and ICANN has agreed to follow IETF technical domain name assignments since RFC 2860 in 2000. If you fear that people won't pay attention to those, why would they pay any more attention to a new document? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
The ARPA domain can be tuned better to the needs of negative caching than the root zone, having a negative caching of a week in ARPA will not cause any problems. Currently the root has one day, if in the future there are frequent adds/deletes of names in the root zone the operators may want to lower that value. That's the first plausible argument I've heard. (It's not overwhemingly persuasive, but at least plausible.) It would be nice if it could be in the draft for future readers. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
It would still be nice to put in an explanation of the motivation for adding SINK.ARPA when its semantics and operations, at least for clients, appear identical to whatever.INVALID. I don't know that I have anything much to add to my previous answers to that question. Well, at this point there seems to be no practical difference at all between the two, which returns to the question of why we need two different ways to do the same thing. If the problem is that people are unfamilar with .INVALID, that would suggest an informational or BCP to tell people how to use names known not to exist. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
For the sink.arpa, it would be good to explain why we want this name to exist. We *don't* want the name to exist; that's the point of the draft. I presume that's what you meant? It would still be nice to put in an explanation of the motivation for adding SINK.ARPA when its semantics and operations, at least for clients, appear identical to whatever.INVALID. Also, if your goal is that applications not have special logic for sink.arpa you should *say* that: Yeah. As far as I know, it is quite uncommon for applications to hard code treatment of .INVALID. But you seem to be saying that they do, and that causes problems that SINK.ARPA would solve. Tell us what they are. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
If you could me more substantive guidance as to where the documents could be improved, I'd be very happy. As things stand the best I can do is say "I'm sorry" :-) Well, OK. Is there a plan to move the DNS for in-addr.arpa and ip6.arpa to the new set of servers? If so, what is it? Will it need more IAB or IETF action? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
The document aims to specify the names of the nameservers to which IN-ADDR.ARPA and IP6.ARPA can be delegated to, and nothing more. OK. Does that mean it'll take another RFC to do the actual delegation? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Aren't we arguing in circles here? The original proposal was for an RFC to mark SINK.ARPA as special. The proposal did not seek to update the behaviour of protocols or applications to treat SINK.ARPA any differently from any other name in the DNS. Right. For all practical purposes, its treatment would be identical to .INVALID. Technically there's nothing special, administratively the manager would promise never to delegate it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Remove the leading dots, ICANN and IANA related names are reserved at 2nd and all levels. In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, who knows? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Since "underscore labels" are not considered "normal" DNS labels for domains representing (roughly) physical hosts and networks, everything below the topmost underscore label should not need to go in a central repository for underscore labels but be pointed to by the documentation referenced for the upper label in such repository. That's reasonable, but it would be nice to have a repository somewhere. Your draft (draft-levine-reserved-names-registry) IMO should focus on the "normal" reserved labels. If you're offering to include _domainkey and _vouch in your list, that's great. If not, what's the plan? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures
| But I have often been sorely tempted to return messages like this with | boilerplate of my own explaining that since I cannot accept the | sender's alleged restrictions, the message has been returned unread, That's the wrong response, it achieves nothing, the person who sent the message usually cannot do anything about it. A better response would be to send the stupid boilerplate (and only the boilerplate, not the real message, or its headers) to the CEO (or corporate lawyer, or similar) You must know different CEOs and lawyers than I do. The CEO's secretary will send it to the lawyer, and the lawyer will say "yes, that's what I told them to do", under the well-known principle that a lawyer will always recommend any measure, no matter how expensive, to defend against any risk, no matter how trivial.* The only hope of change is if there's enough pushback that the staff reports it's making it hard for them to do their jobs. R's, John * - For a good example, see the ever expanding RFC legal boilerplate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures
Unfortunately, many corporate email systems, including at a former employer of mine, automatically add these to every outgoing email, and individual employees have no control over it nor any way to change the corporate policy. Which is one of the reasons why I use non-work email for my IETF work. Oh, yes, we know. But, of course, if someone's employer insists on doing something silly, that's their problem, not ours. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
Agreed, except for the surprise part. The whole staff is paid impressively large amounts and has been as long as I've been watching ICANN. They seem to feel that their peer organizations for compensation purposes are investment banks rather than other non-profits. I don't have access to the salaries of individual employees, and I doubt you do either. ... Hi, Steve. As you know, ICANN is a legally incorporated as a public charity operating for the public benefit, exempt from taxes under IRS code section 501(c)(3). Like every exempt organization, it files an annual financial statement on IRS Form 990, which includes the amounts paid to the highest paid employees and contractors and is available for public inspection. The most recent 990 I can find online is from 2007. It says that ICANN paid CEO Paul Twomey $691,610 plus $255,649 pension contribution. They paid COO Doug Brent $390,939 plus $98,412 pension plus $23,804 expenses. They paid General Counsel John Jeffrey $314,500 plus $63,982 pension. They paid VP Kutt Pritz $318,846 plus $79,627 pension. They paid VP Thressa Swinehart $251,497 plus $62,916 pension. They paid VP David Conrad $197,779 plus $53,028 pension. They paid VP Denise Michel $235,722 plus $52,500 pension, plus an impressive $115,649 expenses, presumably living expenses in Brussels. They paid Ombudsman Frank Fowlie an astonishing $437,727 via his consulting corporation in Canada. They didn't pay you anything. There's more, but this is plenty to get the idea. To approximate what everyone else is paid it's easy enough to look at the staff and budget numbers, and it's quite clear nobody is underpaid. If I were a root server operator, it would take an implausibly large amount of money to be worth the strings that ICANN would attach. ... This is multiple pieces of nonsense: I actually don't think we have any serious disagreement here. ICANN's management of the root zone is cautious for all sorts of reasons, and as you note the root server operators have no plans to say no to what ICANN offers them. It's always been clear that one reason is that the consequences if any of the root servers felt unable or unwilling to accept ICANN's root would be too awful to contemplate, so it'll never happen. But to return to the original issue, ICANN has plenty of money if they wanted to support the IETF. But the IETF needs to get organized enough to ask in a way to which you and the rest of the board can say yes. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf