[Ietf-dkim] Re: DKIM with body length
On Fri, 24 May 2024, Jon Callas wrote: blank lines.) Maybe you can tell it's from a list and the crud is benign, or maybe you can't and you should treat it as suspicious. And yet, I didn't make up the word robustness, it's there in the spec as Dave quoted. When I read the whole paragraph, the message I get is that l= is intended to survive mailing lists but it has many problems so don't use it. My recollection is that for a few features like l=, most of us found them useless, a few people really really wanted them, so that paragraph was a way to get the document out the door. Twenty years ago there was no DMARC* and the issue was that until DKIM became more widely used, mail from dusty lists would have no signatures at all. In fact lists did start signing pretty quickly, list mail all has DKIM reputation and that particular issue is moot. I do not ever recall l= being an proposed as an invitation to recipient systems to do surgery on incoming mail. If anyone had ever suggested that, I'm sure I'm not the only list manager who would have been sure to strip any l= signatures to prevent downstream funny business. 1) It appears that the issue with l= is that implementers are not doing it correctly, ... If there ever was a correct way to use l=, there sure isn't now. But per your next message we seem to agree on the outcome. R's, John * - nobody used ADSP ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
According to Scott Kitterman : Honestly, I think l= is an idea whose time has passed (if it ever existed at all). We ought to just kill it using the simplest procedural mechanism available. We can do an update to deprecate l= but I think that if we just adjusted our validation software to ignore l= the failure rate would be vanishingly low. The ESP that was using l=1 has stopped. Ironport systems sign the entire body and set l= to the body length, so even if you ignore the l=, the signature on an unmodified message will still validate. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: I said "this current round of visibility", a statement which implies _previous_ rounds of visibility of a NOT NEW thing. Sorry, I don't understand what you think is invisible here. I think it could be useful to leverage the current round of publicity to fix more than the specific problem, but it sounds like you believe that's a lost cause and reiterating advice is ineffective. Oh well. General advice to the world, nope. Identifying specific senders with the l= problem has been quite effective. We've found an ESP who was signing with l=1 and has now stopped. It appears that a lot of the others have poorly configured Ironport devices so who do we know at Ironport? By the way, I see from IETF mailing list logs that Ironport users have been signing with l= and no Content-Type for most of a decade and nobody has noticed until now. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: ** or don't over-sign and clients use the first found... I would prefer not to go there. A message with two Content-Type headers or two Subject headers or Date or Message-ID and so forth is not a valid message, and a DKIM signer or validator should just say no. I'm not familiar with DKIM validators that also apply those sorts of "too many instances of a field" rules. Perhaps it would make sense to talk about that in a revision of the DKIM rfc, ... More than a decade ago Doug Otis went on endlessly about adding an extra subject line, which indeed in some cases would get past a DKIM validator, and pretty much randomly MUAs might show one subject or the other. You can do much more effective filtering by assuming defective messages are spam, which they invariably are, rather than screwing around with signatures on them. This current round of visibility on risks of the l= tag and not signing content-type is a moment where *signers* are being prodded and updating their configurations. ,,, For about the tenth time, this particular issue is specifically called out in RFC 6376. It is not new, it is not interesting beyond noticing that a trickle of signers still get it wrong. If people don't read the spec, there's not much we can do about it. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: There's a related, though much less general, attack that works even if you don't use the l= tag: on a message which has nested multiparts, there are multiple potential delimiters that will look legit to a MIME parser, so if you don't sign Content-Type** then an attacker can change the delimiter from the outermost to a inner delimiter and make it appear that the sender directly sent just that inner content, possibly resulting in misattribution. ** or don't over-sign and clients use the first found... I would prefer not to go there. A message with two Content-Type headers or two Subject headers or Date or Message-ID and so forth is not a valid message, and a DKIM signer or validator should just say no. Before anyone mentions the robustness principle, it says to be liberal *where the spec is ambiguous" which it is not here, and to be prepared to recognize and reject garbage that doesn't meet the spec. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
Re: [Ietf-dkim] Question about lone CR / LF
Unix MTAs strip out the CR in CRLF, often on the way in, so by the time opendkim sees the message, the line endings are just LF. That might be true when it's handing a message to an LDA, but it's not true for SMTP ingress filters. For milter, CRs are preserved in the body, so opendkim sees exactly what came in over the wire. https://pythonhosted.org/pymilter/milter_api/xxfi_body.html It's probably more of an issue on the way out. On my system all the DKIM and ARC signatures are applied before the message is handed to the MTA, and it's all \n line endings. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
But on review, it seems like I've tiptoed over that line from time to time in support of robustness in some form or another. ... It occurs to me that Dave and I have different views of how software is put together. His sounds like the waterfall model that was popular when he and I were undergraduates. You design the whole thing, you decide what modules do what, then you code the modules. So if module A is supposed to do something, there's no reason for module B to worry about it because A should already have handled it. My view is more pragmatic. People assemble programs from pieces and the pieces have bugs. So to the extent practical, you defend against things like bad input. It happens that bare CR and LF are really easy to check for in DKIM since as I noted before there's already a state machine that is looking at the current character and knows if the previous character was a CR. So it might as well recognize and reject that particular bit of bad input, particularly since whatever result it would otherwise produce isn't likely to be useful. Maybe this illustrates the difference between pure software engineering and applied software engineering? Yup. R's, John PS: It also optionally does LF to CRLF translation. I'm fairly certain this is to accommodate local/human SMTP injections since humans can't be expected to type CRLFs when entering manual tests from a shell. ... Unix MTAs strip out the CR in CRLF, often on the way in, so by the time opendkim sees the message, the line endings are just LF. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
On Sat, 3 Feb 2024, Dave Crocker wrote: Having a DKIM module check for one aspect of RFC5322 conformance raises a need to make it a full RFC5322 compliance engine. That's easy: no, it doesn't. Any DKIM signer or verifier already has a state machine looking for CR and LF to do header or body canonicalization. When the state machine runs into a bare CR or LF, it has to do something. The only options are to produce a wrong result, since there is no correct result, or no result. (As I said in a recent note to Murray, which wrong result is likely to vary depending on local file details.) You seem to be saying that as a matter of principle it should produce a wrong result. I'd rather not. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
I agree that by the time you're talking to a DKIM (or any) filter, I expect that this has been handled somehow. CRLF ends a line, anything before that is part of the line, and WSP is just a space or a tab. Past that, garbage in, garbage out. Yup, which is why I'd prefer to take out the garbage. As I'm sure you know, on Unix-ish systems the internal line separator is LF, so MTAs add the CR on the way out and remove it on the way in. DKIM routines operate on the internal form so they have code to add a CR before each LF when making hashes. So if a message shows up with bare LFs, those DKIM verifiers will treat it as though those were CR LF. But if a message came from some other system, say Windows, that uses CR LF internally, it won't have added the CRs and the hashes won't match. It seems to me that a signature that may or may not verify depending on internal warts of the verifier is worse than no signature at all. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
Layering is a fine principle, but it's not how DKIM has ever worked in practice. Two weeks ago we had a long discussion about oversigning, so DKIM validators can catch messages with multiple From: or Subject: headers which have never been valid in any version of 822/2822/5322 but show up anyway. Please explain how you think DKIM violates layering. What I said in my previous message, people use oversigning to catch 5322 header violations. For the specific issue of bare CR or LF, I was reminded on another list that there is a trendy attack called SMTP smuggling which depends on mail software inconsistently accepting bare CR or LF, and mail providers are busy patching to fix it. That has nothing to do with DKIM, of course. Opinions differ. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
On Thu, 1 Feb 2024, Dave Crocker wrote: Me, I would*not* put in code looking for bare CRs or LFs. ... A 5322 processor gets to decide what is a valid message. That's not DKIM's job. And DKIM has no inherent reason to care about CR or LF on their own, as distinct from any other character on its own. Layering is a fine principle, but it's not how DKIM has ever worked in practice. Two weeks ago we had a long discussion about oversigning, so DKIM validators can catch messages with multiple From: or Subject: headers which have never been valid in any version of 822/2822/5322 but show up anyway. For the specific issue of bare CR or LF, I was reminded on another list that there is a trendy attack called SMTP smuggling which depends on mail software inconsistently accepting bare CR or LF, and mail providers are busy patching to fix it. Read all about it here: https://smtpsmuggling.com/ I realize that there are plenty of ancient mail messages in archives with bare CR or LF, but none of them are going to be signed or verified now. You're not doing your users any favors by signing or verifiying a message-like thing that contains them. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
Manfred said: (Seems like "seal"ing would be a better term than "oversign"ing.) We've called it oversigning for a decade now. R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Future proofing? The history of encryption is riddled with examples of overconfidence. Well, sure, and I would not be opposed to revisiting this issue in a decade. As Scott noted, approximately nobody handles ed25519 yet, and nobody will until there is some reason to believe that RSA signatures are too weak. Adding another five tons of steel to the door won't change that. And on the third hand, if something unexpected happens and RSA and ed25519 both fail, why do you imagine Ed448 wouldn't fail too? If someone figures out how to make large quantum computers, they're all toast and we'll have to switch to PQC. R's, John On Fri, Oct 27, 2023 at 2:02 PM John Levine wrote: It appears that Scott Kitterman said: On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" < superu...@gmail.com> wrote: On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko 40dusatko@dmarc.ietf.org> wrote: I would like to ask to consider the possibility of defining a DKIM signature using Ed448. [...] My view is that more encryption algorithms are bad for interoperability. For DKIM signing/verifying to work, senders and verifiers need a common algorithm. More choices make this more complex to achieve. We standardized ed25119 as a hedge against unknown vulnerability in RSA. ... Since we already have ed25519, why would we want ed448? If ed25519 is a ten ton steel door on our cardboard box, ed448 is a fifteen ton steel door. R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
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: 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: 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: 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: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (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: draft-ietf-spfbis-4408bis-19.txt (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: draft-ietf-spfbis-4408bis-19.txt (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 jo...@taugh.com 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: 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: 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: 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: 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
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: 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: 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]
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: 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: 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
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: [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
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: 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
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
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
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
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: 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
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
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
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: Last Call: draft-melnikov-smtp-priority-07.txt (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
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: 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
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: 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: 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: Last Call: draft-kucherawy-dkim-atps-11.txt (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
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: 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
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
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: 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
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: 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: 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: draft-ietf-dkim-mailinglists-10.txt (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: draft-ietf-dkim-mailinglists-10.txt (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: draft-ietf-dkim-mailinglists-10.txt (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: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (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: 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 RFCs. 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
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
.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: 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: [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 (CC) 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 CC. 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 CC 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
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: 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
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: 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
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: 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: 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
