> Think of it as an explicit "interoperability considerations" section to
> supplement the usual "security considerations" one.
That seems reasonable, so long as someone steps forward to write it.
> I note that we have never standardized a magic bullet in the anti-spam
> area. I believe that to
> Indeed. And, along the lines of my response to John, and to
> Dave's request to be specific, that sort of analysis and
> description is _precisely_ what I believe should be required to
> be written into text, ...
The more I think about this, the less sense it makes. DKIM is not the
first misus
> > undocumented, and unstable. I hope we have consensus on that.
> Sorry, no such consensus.
No problem. We've taken your tip and redefined consensus to exclude
anyone who disagrees with us.
> I don't see why the editor you use needs to be open-standard.
Actually, I don't care what editor you
> John> Here's a concrete suggestion: it is clear that the bad uses
> John> of DKIM people have mentioned are a subset of the bad uses
> John> of STARTTLS.
>
> That's not clear to me.
> I'd never really considered the question though so it may well be true.
If walled gardens are the pr
> OK. If this is just an assumption and not backed by evidence, I would
> suspect that outside of the web you see a lot less use of the big CAs.
Probably true. And since DKIM has no provision for authorities at all, it
definitely doesn't use them.
So remind me, what is the problem with DKIM tha
This document (hereafter called ADSP) allows the domain to advertise
its signing policy, thus allowing recipients to distinguish these
(and some other) cases.
ADSP is a very, very narow design, that attempts to deal with only a
single threat: exact forgery of an address on the From: line. Ther
The other thing I don't understand is why you minimize the expected VBR
effect. (If that's meant as an apotropaic stance, I have no objection.
Otherwise,) I wonder why we shouldn't push VBR as hard as we can, if it can
stop spam.
Could you point out where anyone, anywhere has claimed that VBR
> But one of the important criteria for an acceptable alternate
> form, one which came up in the earlier discussion on this list,
> is that the format be searchable.
In case it wasn't clear, my quite informal suggestion was that one might
attach a few GIF illusttrations to an ASCII document, sort
> > The IETF standards process is already so slow and uncertain that
> > people throw up their hands in exasperation and go around it.
>
> True. Which is why it's necessary to handle the reviews in a pipelined
> rather than a stop-and-wait fashion.
Maybe I'm unduly pessimistic, but I would have t
> but rather, how to make better use of its time by producing a
> specification that was more relevant. ...
> Apparently you think that an artist is the best judge of the relevance
> of his own work.
I find the assumption that external reviewers are better able to score a
project's "relevance", wh
> Merely calling something or someone a name like sclerotic or dillitante
> is unconvincing. You haven't seen a proposal yet, you have no idea of
> how this would work
Good point. The sooner you send around a proposal, the sooner we can
figure out how it might improve the process.
_
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 t
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 o
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
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 ch
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.
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
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 Le
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 bef
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
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
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.
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
On Jun 19, 2013, at 3:43 PM, John Levine wrote:
Assuming we care about stability and interoperability, wouldn't it
make sense for the IETF to spin up a WG, collect these drafts, clean
up the language, make sure they agree with the widely implemented
reality, and publish them?
The only way that
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)
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 m
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
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 defini
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 th
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 ne
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
account
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 no
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
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 ra
presuming your statement about an inversion of the stated trust model is
correct, can we dereference "friendly" and "hostile" to whom? Who makes
that assessment and who/what defines the tools to implement a trust
policy?
Those are all excellent questions, and if I had good answers I would
an
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 nu
.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.
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
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
Some clever spambot seems to have scraped a bunch of addresses out of the
archives and is sending spam with multiple addresses on the From: line through
IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it.
DKIM is directly designed to address this... What do we need to do
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
th
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 t
(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",
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
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 w
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 shou
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
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 enviro
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
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
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/mai
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
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 sp
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 a
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
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 curren
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
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
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 think you didn't mean domain. In that case, the catchall address encourages
delivery. I'm looking for a guaranteed bounce, for test purposes, at any email
service provider.
I think we understand what you want. You can't have it.
Beyond the issue of catchall domains, there's the more basic
Agreed, except for the surprise part. The whole staff is paid
impressively large amounts and has been as long as I've been watching
ICANN. They seem to feel that their peer organizations for
compensation purposes are investment banks rather than other
non-profits.
I don't have access to the
Unfortunately, many corporate email systems, including at a former
employer of mine, automatically add these to every outgoing email, and
individual employees have no control over it nor any way to change the
corporate policy. Which is one of the reasons why I use non-work email
for my IETF work.
| But I have often been sorely tempted to return messages like this with
| boilerplate of my own explaining that since I cannot accept the
| sender's alleged restrictions, the message has been returned unread,
That's the wrong response, it achieves nothing, the person who sent the
message usua
Since "underscore labels" are not considered "normal" DNS labels
for domains representing (roughly) physical hosts and networks,
everything below the topmost underscore label should not need
to go in a central repository for underscore labels but be
pointed to by the documentation referenced for t
Remove the leading dots, ICANN and IANA related names are reserved at
2nd and all levels.
In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA,
who knows?
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/
Aren't we arguing in circles here? The original proposal was for an
RFC to mark SINK.ARPA as special.
The proposal did not seek to update the behaviour of protocols or applications
to treat SINK.ARPA any differently from any other name in the DNS.
Right. For all practical purposes, its tre
The document aims to specify the names of the nameservers to which
IN-ADDR.ARPA and IP6.ARPA can be delegated to, and nothing more.
OK. Does that mean it'll take another RFC to do the actual delegation?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
In
If you could me more substantive guidance as to where the documents could be improved,
I'd be very happy. As things stand the best I can do is say "I'm sorry" :-)
Well, OK. Is there a plan to move the DNS for in-addr.arpa
and ip6.arpa to the new set of servers? If so, what is it? Will it ne
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of the draft. I presume
that's what you meant?
It would still be nice to put in an explanation of the motivation for
adding SINK.ARPA when its semantics and oper
It would still be nice to put in an explanation of the motivation for adding
SINK.ARPA when its semantics and operations, at least for clients, appear
identical to whatever.INVALID.
I don't know that I have anything much to add to my previous answers to that
question.
Well, at this point th
The ARPA domain can be tuned better to the needs of negative caching than the
root zone, having a negative caching of a week in ARPA will not cause any
problems. Currently the root has one day, if in the future there are
frequent adds/deletes of names in the root zone the operators may
want to
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 pr
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 righ
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
explain
* - "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, Prim
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 propr
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 pos
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 para
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 conclusi
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
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
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
wit
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 unk
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
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.
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
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 i
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",
Pl
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
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. Ot
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
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.
Regar
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
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 s
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
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
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 o
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 s
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 dropp
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 thoug
1 - 100 of 112 matches
Mail list logo
