[Ietf-dkim] Re: DKIM with body length

[John Levine]

It appears that Murray S. Kucherawy   said:
>(a) Inertia will mean "l=" is generated and/or accepted for a long time to
>come no matter what we say or do; and

Yup.

>(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at
>verifiers, which will mean those signatures break and we have an
>interoperability problem (though likely a tolerable one).

It Depends(TM).  I see some mail with l=1 which means that the signature
won't verify if you ignore the l=.  But I also see a fair amount from
what appear to be Ironport appliances with the l= covering the entire
body.  If you ignore the l= you still hash the entire body, so the
signature should be OK, right?

>SHOULD be signed, and I think Content-Type was one of them; RFC 6376
>removed the explicit list in favor of more abstract guidance that should
>lead anyone toward the same original list at least.  So even that aspect of
>this attack was anticipated.

More than anticipated, explicitly described on page 41:

   If the "l=" signature tag is in use (see Section 3.5), the Content-
   Type field is also a candidate for being included as it could be
   replaced in a way that causes completely different content to be
   rendered to the receiving user.

Rather than revising 6376 I was thinking about an AS or BCP that tells
you how to make strong signatures.  Nothing exotic, use reasonbly
strong keys and sign all the headers that make sense to sign.

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

[John Levine]

It appears that Wei Chuang   said:
>-=-=-=-=-=-
>
>Hi DKIM folks,
>As many of you know there was a DKIM security vulnerability disclosure
>Friday around the signature header body length tag "l=". The blog post is
>here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
>The authors state that an adversary can append a malicious footer to a
>message with DKIM w/body length, then rewrite the Content-type header mime
>delimitter, that will cause the apparent body to be that of the footer but
>will authenticate as the original DKIM signature. 

This exact attack is described on page 41 of RFC 6376:

   If the "l=" signature tag is in use (see Section 3.5), the Content-
   Type field is also a candidate for being included as it could be
   replaced in a way that causes completely different content to be
   rendered to the receiving user.

There really is nothing whatsoever new here.

I agree that it would be a good idea to discourage people from using
the l= tag but first I am trying to talk to the few places that send
me l= mail and see if I can figure out why they do 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

[John Levine]

It appears that Jeremy Harris   said:
>On 20/05/2024 09:06, Alessandro Vesely wrote:
>> Content-Type: is a technical field
>
>Not a term I've met before.  Is there a formal definition?

As Dave said, no.  There isn't even an informal definition.

>And as far as "which forwarders need to change" goes -
>isn't the entire point of DKIM to detect chages?

If someone changed the Content-Type header on a message I sent,
I would certainly want the signature to break.

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

[John Levine]

It appears that Dave Crocker   said:
>What I  am suggesting is /first/ getting a substantial base of industry 
>agreement, through collective action and field practice, and /then/ 
>codifying it with an update specification.
>
>The specification through the IETF would then merely document a new 
>established practice.
>
>Do not start with an IETF process.  End with it.

Considering how few senders use l= I would start by trying to contact some
of them and see if they realize what they're doing.

Anyone know who runs Verisign's mail system?

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

[John Levine]

It appears that Steve Atkins   said:
>> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 
>> are going to pay attention to a separate RFC
>that updates that RFC?
>
>+1. Senders, no.

Honestly, I don't know. Of the trickle of mail I see with l=, most is
from the libertarian Reason blog with l=1 and the rest is from
Verisign who for some reason sign with l= actual length.

I suspect I could get Verisign's attention. Reason, who knows, as
likely as not they have some political reason they think it's a good
idea.

>But there are already major mail receivers who treat any DKIM signature 
>containing l= to be invalid.

That will definitely get their attention.

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] RFC 8463: DNS textual form underspecified

[John Levine]

It appears that Steffen Nurpmeso   said:
> |I realize that RFC 8463 says repeatedly that the base64-encoded
> |representation of an ED25519 key is 44 bytes, and that the
> |examples go for this.  Still there is no wording that the entire
> |ASN.1 structure shall be thrown away.

Yeah, I should have been clearer.

>That cannot be the reason Google, Microsoft and more do not
>support that, right.  It is a bit bizarre that these huge RSA keys
>are used all over the place, whereas the even stripped-naked ones
>are not.

It's the same reason as the last umpteen times you asked.

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

[John Levine]

It appears that Scott Kitterman   said:
>This isn't horrible.  The main reason for RFC 8463 was, in my view, as a hedge 
>for some discovery that suddenly made RSA
>obsolete, which hasn't happened yet.  From a standards perspective, it is 
>there if needed.

Yes, that is exactly the reason I wrote it.

My MTA doesn't generate or validate Ed25519 signatures either. Maybe
someday when I have some spare time.

R's,
John

___
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?

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso  wrote:
>
>> If a graphical user interface gives you a green "ok" button to
>> click, or "red" otherwise, that is even better as in browser URL
>> lines.  Then pop up a tree-view of message modifications and
>> alertize where it broke, checkbox for is-this-really-an-evil.
>
>I remember seeing a study presented at a conference that showed people
>sometimes[*] click on links found in their spam folders. ...

At session with large mail providers at a meeting a year or two ago, I
recall at least one of them said they'd made the links in the spam
folder non-clickable to prevent people from doing that. Otherwise some
users will click on everything, "just in case the spam filter got it
wrong."

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

[John Levine]

It appears that Jim Fenton   said:
>On 5 Feb 2024, at 14:02, Dave Crocker wrote:
>
>> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>>> And you will also provide citations to refereed research about what you 
>>> just asserted as well, yes?
>>
>>
>> Ahh, you want me to prove the negative. That's not exactly how these things 
>> go.
>
>You said that the URL lock symbol failed. Asking for research to back that up 
>is not asking for you to
>prove the negative. I suspect there is research out there that backs up that 
>statement, and I’m just
>asking for the same amount of rigor that you are asking for.

In this case, Dave's right.  Here's a conference paper from Google saying that 
only 11% of users
understood what the lock meant.

https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

The annual Usenix SOUPS conferences are full of papers about failed security 
UI.  Here's this year's.
Don't miss the one saying that Gmail's message origin indicator doesn't work, 

https://www.usenix.org/conference/soups2023/technical-sessions

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[John Levine]

It appears that Dave Crocker   said:
>> 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.
>
>The state machine has to process /every/ character.  You are focusing on 
>two that have special DKIM meaning, when occurring together, but that's 
>too narrow.  In practical terms, the state engine is evaluating every 
>character.

Sorry, I thought it would be obvious that it already has to treat CR
and LF differently, and it already has special cases for what follows
CR and (on systems that don't turn CRLF to LF on the way in) what
precedes LF.

>In focusing down so narrowly, you've missed the basic point I made:  
>DKIM has no inherent reason to care about these characters' occurring in 
>isolation. ...

Sigh. Except that it already does. You've made it clear that you
believe there is a principled reason to produce invalid signatures
from invalid input. Whatever.

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[John Levine]

It appears that Dave Crocker   said:
>The prohibition is not in DKIM. So the violation is not within DKIM.  
>And why should DKIM care?

RFC 6376 says what to do with 5322 messages. It says nothing about
what to do with blobs of bytes that are sort of like but not quite
5322 messages. It even has a few places that remind us of that, e.g.,
in section 5.3 it reminds us that if the local file convention uses
just CR or LF, change them to CRLF before doing anything else.

I can see that you have strong opinions about what a DKIM verifier
should do with those non-5322 blobs, but I don't see what the basis
for that is, and for that matter, I don't really understand what you
expect code to do with them.  Why is "stop and report failure" any
less valid than anything else?

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso  wrote:
>
>> But i cannot read this from RFC 6376.
>
>Sections 2.8 and 3.4.4 don't answer this?

Not really.  They say what to do with CRLF but not with a lone CR or lone LF.

RFC5322 says:

   o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
  independently in the body.

So I think the answer is that a thing with a lone CR or LF is not a
valid message so signers shouldn't sign them and validators shouldn't
validate them. If you want to allow them, OK, but no promises that
anyone at the other end will treat the brokenness the same way you
dod.

We can get into some theological arguments about BINARYMIME which
allows arbitrary bytes in a MIME part but I expect that DKIM
canonicalization code will choke on other stuff in binary MIME before
it gets to a \x0a or \x0d.

R's,
John

___
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?

[John Levine]

It appears that Evan Burke   said:
>> Insisting on using the same term for these two different cases has an
>> academic purity to it, but has already been demonstrated to be destructive
>> in practical terms, because it creates confused discussion.

>No, that's exactly backwards. The oversigning case is a subset of the
>general DKIM replay case, because mitigation techniques for general DKIM
>replay - they do exist, though they are imperfect - also apply to cases
>where header addition has taken place. Oversigning is a defense against the
>subset of DKIM replay where headers have been added, but not the general
>case.

I think you've rather proved Dave's point. Resending the identical
message and mutating a signed message with duplicate headers are
different problems even though they have some technical overlap.

I don't really care what people call them but it would be nice if they
had different names so we don't have to use six round trip messages
each time to figure out which one we're referring to.

Pretty much everywhere except this mailing list "DKIM Replay" means
the former, resending the identical message.

R's,
John

___
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?

[John Levine]

It appears that Mike Hillyer   said:
>In the interest of the rule of unforseen consequences, we're trying to avoid 
>oversigning any headers that would break further downstream processing. Does 
>anyone
>know of any headers that *should* be DKIM signed, but *should not* be 
>oversigned?

Offhand, I can't think of any.

DKIM signatures are only defined for RFC5322 messages, and anything
with two From: or Subject: or Date: headers isn't an RFC5322 message. A
DKIM validator really shouldn't accept an invalid message, and a spam
filter should give a very high score to duplicate headers, but I realize
theory and practice diverge here.

R's,
John

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Signature

[John Levine]

It appears that Scott Kitterman   said:
>On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" 
> wrote:
>>On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko 
>>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

Re: [ietf-privacy] [Internet Policy] How a Radio Shack Robbery Could Spur a New Era in Digital Privacy

[John Levine]

In article  you write:
>So, it seems like (IANAL) one way to read the situation is that the government 
>is currently trying to
>get companies to forcefully take the expectation of privacy off the table for 
>commonly used
>communication tools.

I don't think that's the issue here.  The telcos have files full of
plaintext location information.  The question is who can look at them.

>I wonder what the analysis is WRT back doors vs. "keep the plaintext" (what 
>they currently seem to be
>pursuing). The latter seems to sidestep the second test above...

That's a whole different can of worms. Access to the contents of
conversations has always required a warrant, and certain parts of law
enforcement believe that they have the right to force everyone else to
provide those contents in plaintext, regardless of what the laws of
mathematics might say.

R's,
John

___
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

Re: [ietf-privacy] Fwd: [Internet Policy] How a Radio Shack Robbery Could Spur a New Era in Digital Privacy

[John Levine]

In article <396e100a-55ba-4155-a29e-92d452a45...@gmail.com> you write:
>Interesting article, cross-posted from ISOC Public Policy list

Carpenter is an interesting case, but it has nothing to do with the
Internet.

It's quite fact specific to mobile phones, which by their nature
transmit a running history of their location to the towers which
mobile phone companies log.  This was true even in AMPS days, at least
the tower data part if not the logging.

The question presented is whether the cops need a warrant from a judge
to get access to those logs or just a subpoena from law enforcement or
from a lawyer.  The argument on one side is that it's a great deal of
rather personal information, e.g., it told them whether Carpenter went
to church each Sunday and when he spent the night at someone's house
other than his own.  The argument on the other is that it's the same
info they'd get if they had a cop tail the guy.  (You don't have to
tell me that those arguments are not equally persuasive, but that's
what they are.)

Lots of details here:

http://www.scotusblog.com/case-files/cases/carpenter-v-united-states-2

Here's the usually reasonable Orin Kerr making the just like a tail argument:

http://www.scotusblog.com/2017/08/symposium-carpenter-eyewitness-rule/

R's,
John

___
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

Re: The core Internet institutions abandon the US Government

[John Levine]

Just few quick questions,

In what part of Fadi Chehad� mandate at ICANN this falls ? And who
sanctified him as representative of the Internet Community ?

He is just an employee of ICANN and these actions go way beyond ICANN's
mission and responsibilities.

ICANN has a long running fantasy that they are a global
multi-stakeholder organization floating above mere politics, and not a
US government contractor incorporated as a California non-profit.
This will never change, and everyone familiar with the situation knows
it, but for internal political reasons ICANN likes to pretend
otherwise.

I suppose in the current political situation about the NSA there's no
harm in the other groups going along with it for a while.

R's,
John

Re: consensus, was leader statements

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Because we've got more than 120 working groups, thousands of
participants, and the internet is now part of the world's
communications infrastructure.  I don't like hierarchy but
I don't know how to scale up the organization without it.

There are largish organizations that work by consensus, notably Quaker
meetings and their regional and national organizations.  But we are
not like the Quakers.  For one thing, they have long standing
traditions of how consensus works, including a tradition of standing
aside and not blocking consensus if you disagee but see that most
people agree in good faith.  For another, they are very, very patient.
The meeting in Ithaca NY, near where I live, took ten years to decide
about getting their own meeting house rather than rented space.  

I don't see us as that disciplined or that patient (including myself,
I'm not a Quaker, but married to one.)

So it is a reasonable question how an organization like the IETF can
govern itself.  My inclination is to be careful in the choice of
leadership, and then trust the leaders to act reasonably.

R's,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlJXA2oACgkQkEiFRdeC/kXbFACfYcKTHPfjK3yFvyGvydHZB0jx
z6AAn23U7x2tygklXyGav0DuYWjEdAvV
=s3DJ
-END PGP SIGNATURE-

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[John Levine]

The IESG has received a request from an individual participant to make
the following status changes:

- RFC5617 from Proposed Standard to Historic

The supporting document for this request can be found here:

http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

I'm one of the authors of this RFC and support the change.

ADSP was basically an experiment that failed.  It has no significant
deployment, and the problem it was supposed to solve is now being
addressed in other ways.

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: Dotless in draft-ietf-homenet-arch-10

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In article 6.2.5.6.2.20130920070952.0664d...@elandnews.com you write:
Hi Spencer,

I read your DISCUSS about draft-ietf-homenet-arch-10:

   'Is there a useful reference that could be provided for dotless?'

Another possibility is draft-hoffine-already-dotless.  It's in the ISE
queue, and I think it's reasoably likely it'll be published.

R's,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlI8fykACgkQkEiFRdeC/kV7igCfeOEJ1OJ+HEiMXuhQSpIYD9OD
3mkAniWmk1q1WZJZ2j8l+YxmPIhom/uB
=cIFH
-END PGP SIGNATURE-

Re: ORCID - unique identifiers for contributors

[John Levine]

 I would even suggest that all I-D authors, at the very least, should
 need to register with the IETF to submit documents. 

Oddly enough, back in the Dark Ages (i.e. the ARPANET), the DDN maintained
such a registry, and so if you Google 'NC3 ARPANET' you will see that that
was the ID assigned to me back then. We could easily do something similar.

It carried over to the early NetSol registries, where I was JL7, but
please include me out this time.

It might be useful to have some way for RFC authors to create a
persistent forwarding address, if they want to do so.  We already have
a place for authors to include an ORCID URL, if they want to.

But it is really not our problem to make life easier for grad students
in the 2040s trying to create influence graphs from the
acknowledgement sections of dusty old RFCs.

R's,
George

Re: ORCID - unique identifiers for contributors

[John Levine]

There are, in the RfC I used as an example, far more acknowledged
contributors, than authors. No addresses for those contributors are
given.

As far as I can tell, nobody else considers that to be a problem.

I have written a bunch of books and looked at a lot of bibliographic
records, and I have never, ever seen any of them try to catalog the
acknowledgements.  Indeed, in many books the acknowledgemnents are
deliberately very informal, e.g., thanks to Grandma Nell for all the
cookies and to George for his unwavering support.  George turns out
to be his dog.

R's,
John

PS: On the other hand:
http://www.condenaststore.com/-sp/On-the-Internet-nobody-knows-you-re-a-dog-New-Yorker-Cartoon-Prints_i8562841_.htm

Re: ORCID - unique identifiers for contributors

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Asking for ORCID support in the tool set and asking for IETF endorsement
are two very different things.

Having tool support for it is a necessary first step to permitting IETF
contributors to gain experience with it.   We need that experience before we
can talk about consensus.

The toolset already lets you put in URIs.  What else do you think it needs?

R's,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlI4gwcACgkQkEiFRdeC/kXqJQCfRBk5uNBf+EEMHlj6BWSRvQCL
YsUAnA6ynSuwlRSigpjw/dhQgQNZltmy
=1xR4
-END PGP SIGNATURE-

Re: ORCID - unique identifiers for contributors

[John Levine]

Having an IETF identity is OK if all you ever publish is in the IETF. Some of 
our
participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a 
few publish
Academic papers. Using the same identifier for all these places would be 
useful, and
that single identifier is not going to be an @ietf.org email address.

If you want Yahoo mail or gmail or pobox.com, you know where to find it.

Or people here are, I expect, mostly able to arrange for their own
vanity domains.

R's,
John, ab...@no.sp.am

Re: [IETF] Re: ORCID - unique identifiers for contributors

[John Levine]

It's practically essential for academics whose career depends on
attribution of publications and on citation counts (and for the
people who hire or promote them).

Gee, several of the other John Levines have published way more than I
have.  If what we want is citation counts, confuse away.

R's,
John

PS: If you think I think this topic has been beaten to death and back,
you wouldn't be mistaken.

Re: ORCID - unique identifiers for bibliographers

[John Levine]

* The purpose of ORCID is to /uniquely/ identify individuals, both to
differentiate between people with similar names, and to unify works
where the author uses variant or changed names

If you think that's a good idea, I don't see any reason to forbid
people from including an ORCID along with the real contact info, but I
would be extremely unhappy if the IETF were to mandate it or anything
like it.

My name turns out to be fairly common.  Over the years, I have been
confused with a comp sci professor in Edinburgh, a psychology
professor in Pittsburgh, another comp sci researcher in Georgia, a
psychiatrist in Cambridge MA, a composer in Cambridge UK, a car buyer
in Phoenix, and some random guy in Brooklyn, all of whom happen to be
named John Levine.  Tough.  Not my problem.

I also think that it's time for people to get over the someone might
spam me so I'm going to hide nonsense.  The point of putting contact
info in an RFC is so that people can contact you, and the most
ubiquitous contact identifiers we have remain e-mail addresses.  I
still use the same e-mail address I've had since 1993 (the one in the
signature below), and my garden variety spam filters are quite able to
keep it usable.  If I can do it, so can you.

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: ORCID - unique identifiers for bibliographers

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Since this has turned out to be ambiguous, I have decided to instead use a
SHA-256 hash of my DNA sequence:

9f00a4-9d1379-002a03-007184-905f6f-796534-06f9da-304b11-0f88d7-92192e-98b2

How does your identical twin brother feel about this?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlI3X+8ACgkQkEiFRdeC/kWmMQCfS56oZrlO5XXrMiS+fyJgA3W+
mZUAoKL5JAFfSAZgKWq8Le+9IvtzLuXv
=E9r0
-END PGP SIGNATURE-

Re: ORCID - unique identifiers for contributors

[John Levine]

How do I know that the sender of this message actually has the right
to claim the ORCID in question (-0001-5882-6823)? The web page
doesn't present anything (such as a public key) that could be used
for authentication.

I dunno.  How do we know who brian.e.carpen...@gmail.com is?  I can
tell you from experience that a lot of people think they are
john.lev...@gmail.com, and all but one of them are mistaken.

R's,
John

PS: Now that I think about it, you can already put in a personal URL
in rfc2xml, so if someone wants to use an ORCID URL, they can do so
right now.

Re: pgp signing in van

[John Levine]

Why do you think that cryptographic doubt = legal doubt? I've heard
that claim many times, but I've never heard an argument for it.

Having attempted to explain technology in court as an expert witness,
I find the assertion risible.

R's,
John

Re: not really pgp signing in van

[John Levine]

 Yes, they should have made that impossible.

Oh my, I _love_ this!   This is actually the first non-covert use case I've 
heard described,
although I'm not convinced that PGP could actually do this without message 
format tweaks.

Sounds like we're on our way to reinventing S/MIME.  Other than the
key signing and distribution (which I agree is a major can of worms)
it works remarkably well.

R's,
John

Re: not really pgp signing in van

[John Levine]

 Sounds like we're on our way to reinventing S/MIME.  Other than the
 key signing and distribution (which I agree is a major can of worms)
 it works remarkably well.

Which sounds kind of like, Other than that Mrs. Lincoln, how was the play?

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.

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.

R's,
John

Re: What real users think [was: Re: pgp signing in van]

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Believe it or not Ted Nelson had a similar idea when he invented Xanadu
Hypertext. He was obsessed by copyright and the notion that it would be
wrong to copy someone else's text to another machine, hence the need for
links.

Well, yes, but he's never been able to implement it, despite decades
of trying.  (I've known Ted since 1972, so I watched a lot of it
happen.)  Xanadu was always envisioned as a monolithic system that
didn't scale over large numbers of machines or wide geographic areas.
It's really interesting as a conceptual design, but the closest
working implentation is the WWW and that, to put it mildly, left out a
lot.

On the other hand, MIME can do multipart messages consisting of a
sequence of signed bodies right now, and most MUAs display them pretty
well.  I've never seen anything create one other than a list manager
like Mailman or mj2 adding a signature part after a signed body.

R's,
John



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlIucekACgkQkEiFRdeC/kXrfgCfYFyXhGaXoIKHiuJg1bYns/sf
6JcAn2qSoWfT/9+9LadEUbG6oHf5YvPy
=RwJq
-END PGP SIGNATURE-

Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[John Levine]

The engineering solution to this deployment problem is to generalize the
problem and use a new record for that.

Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.

The type number is 16 bits, after all.  We're not in any danger of running 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

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

[John Levine]

 SPF is ten years old now.  It would be helpful if you could give us a
 list of other protocols that have had a similar issue with a TXT
 record at the apex during the past decade.

I don't know of any (at least ones that are used in the global dns
namespace), and I would like to still not know of any in 2033.

SPF may be a lost cause, let's try and make that the only one.

Since we agree that the issue you're worried about has not arisen even
once in the past decade, could you clarify what problem needs to be
solved here?

R's,
John

Re: Fwd: [dnsext] SPF isn't going to change, was Deprecating SPF

[John Levine]

 Nobody has argued that SPF usage is zero, and the reasons for
 deprecating SPF have been described repeatedly here and on the ietf
 list, so this exercise seems fairly pointless.
 
  the reasons for not deprecating SPF have been described here
  and on the ietf list repeatedly ... yet there has been little
  concrete data regarding deployment uptake.

Sigh.  We have RFC 6686.  Since this is clearly an issue you consider
to be of vital importance, it is baffling that (as far as I can tell)
you did not contribute to or even comment on it when it was being
written and published.

Those of us in the mail community have a lot of anecdotal evidence,
too.  Most notably, none of the large providers that dominate the mail
world publish or check type 99, and the one that used to check type 99
(Yahoo) doesn't any more.  You don't have to like it, but it's silly
to deny it.

In any event, it's purely a strawman that nobody checks type 99.  A
few people do, the WG knows that, and we decided for well documented
reasons to deprecate it anyway.

R's,
John

Re: IETF 88 - Registration Now Open!

[John Levine]

In article b4828b8f-b900-4dc1-ad3e-7e3044fb8...@isi.edu you write:
and the hotel is fully booked�.

Not if you use the link on the meeting hotel page.

http://www.ietf.org/meeting/88/hotel.html

R's,
John

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

[John Levine]

In article 5215cd8d.3080...@sidn.nl you write:
So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?

SPF is ten years old now.  It would be helpful if you could give us a
list of other protocols that have had a similar issue with a TXT
record at the apex during the past decade.

R's,
John

Re: [spfbis] there is no transitiion, was Last Call: draft-ietf-spfbis-4408bis-19.txt

[John Levine]

Actually, I just checked.   Right now, none of them seem to publish SPF RRtype 
records.
Yahoo doesn't even publish a TXT record containing SPF information.   An 
argument could
be made that if we really wanted to push the adoption of SPF RRtypes, getting 
Google,
Yahoo and Hotmail to publish SPF RRtype records would actually make it 
worthwhile to
query SPF first, because most queries probably go to those domains.

This would require some reason why it is worth them spending time and
money to do something that has no operational benefit whatsoever.

If they start publishing type 99, something will break, because when
you change something in large systems, something always breaks.  Some
mail systems somewhere with bugs in type 99 handling that they never
noticed will start making mail fail.  For doing that, will anyone's
mail work better?  No.  Will their DNS work better?  No.

As I have mentioned a couple of times already, even though Yahoo
doesn't publish SPF (I believe due to political issues related to the
history of Domainkeys and DKIM), they do check SPF.  They used to
check both TXT and type 99, and stopped checking type 99.  What
argumment is there to spend money to revisit and reverse that
decision?

Arguments about DNS purity, and hypothetical arguments about other TXT
records that will never exist are unlikely to be persusasive.

R's,
John

Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408bis-19.txt

[John Levine]

Newsgroups: iecc.lists.ietf.ietf
From: John Levine jo...@iecc.com
Subject: Re: [spfbis] prefixed names, was Last Call: 
draft-ietf-spfbis-4408bis-19.txt
Summary:
Expires:
References: 5212fcef.80...@dcrocker.net 
55459829-933f-4157-893a-f90552d44...@frobbit.se 
5213174d.7080...@dcrocker.net 
d2148a40-2673-40c7-8349-0a65d0d01...@frobbit.se
Sender:
Followup-To:
Distribution: 
Organization: 
Keywords: 
Cc: 
Cleverness: some

The two following MIGHT NOT be in the same zone:

foo.example. IN X RDATAX
_bar.foo.example. IN TXT RDATAY

Since prefixed names have never been used for anything other than
providing information about the unprefixed name, what conceivable
operational reason could there be to put a zone cut at the prefix?

This impresses me as one of those problems where the solution is
don't do that.

R's,
John

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

[John Levine]

* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Internet. ...

Uh huh.

$ dig besserwisser.org txt

;; QUESTION SECTION:
;besserwisser.org.  IN  TXT

;; ANSWER SECTION:
besserwisser.org.   86173   IN  TXT MN-1334-RIPE
besserwisser.org.   86173   IN  TXT v=spf0x44 be allowed to 
contaminate the DNS.
besserwisser.org.   86173   IN  TXT v=spf0x42 besides, SPF as 
concept is a layering violation.
besserwisser.org.   86173   IN  TXT v=spf0x41 not valid. because 
SPF records belong in RRtype 99.
besserwisser.org.   86173   IN  TXT v=spf0x43 adding insult to 
injury, this layering violation MUST not 

$ dig besserwisser.org spf

;; QUESTION SECTION:
;besserwisser.org.  IN  SPF

;; ANSWER SECTION:
besserwisser.org.   86140   IN  SPF v=spf1 ip6:0::/0 -all
besserwisser.org.   86140   IN  SPF v=spf1 ip4:0.0.0.0/0 -all

R's,
John

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

[John Levine]

There is nothing syntactially worng with those entries. I congratulate
people advocating SPF in TXT records while also writing parsers.

None of your TXT records are SPF records because they don't start with
the required version tag.  You have two type 99 records that start
with the version tag, which is invalid under section 3.1.2 of RFC 4408
and the similar section 3.2 of 4408bis.  

So you're publishing no SPF information at all.  I gather that you've
tried the popular SPF implementations like libspf2 and verified that
they correctly report that they found nothing.

I really don't understand what point you're making here.

R's,
John

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

[John Levine]

AFAICT, no one is arguing that overloading TXT in the
way recommended by this draft is a good idea, rather the best arguments appear 
to be that it is a pragmatic
least bad solution to the fact that (a) people often implement (poorly) the 
very least they can get away
with and (b) it can take a very long time to fix mistakes on the Internet. 

Neither of those are the reason the WG dropped type 99 records.  The
actual reason has been discussed at length, and was most recently
described earlier today in this thread.

Once again, I really don't understand what the point is here.

R's,
John

Re: Academic and open source rate (was: Charging remote participants)

[John Levine]

In article 01672754-1c4f-465b-b737-7e82dc5b3...@oracle.com you write:

I've been told, though obviously I don't know, that the costs are 
proportional.  I assume it's not literally a if we get
one additional person, it costs an additional $500.  But I assume SM wasn't 
proposing to get just one or a few more open
source developer attendees.  If we're talking about just a few people it's 
not worth arguing about... or doing anything
about.  It would only be useful if we got a lot of such attendees.

My trip to the Berlin IETF cost me about $3300, of which the
registration fee was only $650.  (The plane ticket was expensive,
since I flew from upstate NY, but the hotel was cheap because I booked
at a place a block away with a prepaid rate back in May.)

If we're going to provide financial inducements for people to come,
whether open source developers or anyone else, unless they happen to
live in the city where we're meeting, we'll need to give them cash
travel grants, not just waive the fee.  The IRTF brings winners of
their research prize to the meetings to present the winning papers,
so we can look at those numbers to see what it costs.

Re: Anyone having trouble submitting I-Ds?

[John Levine]

 The anti-hijacking feature causes the confirmation email to
 only go to the authors listed on the previous version of the document, so
 mail was not sent to me and things are working as expected.

This behavior is not documented to the user when they submit the document
and is therefore a bug.

It's sort of documented somewhere, but I agree that it's a bug that it
doesn't tell the submitter what happened.

I reported it as a bug a while ago, dunno where it is in the tracker.

Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[John Levine]

   http://iaoc.ietf.org/documents/RPC-Proposed-SoW-2013-final.doc

I know that I should not this, but... I am a bit surprised
(disappointed) in seeing a proprietary format used here.  I am not
saying that you should not use the Office suite to write it, but you
could convert it to PDF (better, PDF/A) before publishing it.

Anyway, I use Linux, so I guess I will not be able to give my input about it.

Hmmn.  Is there some reason you are unable to install OpenOffice?  It
opens and displays the SoW including the redline just fine.

I suppose she could have sent it out in OpenOffice's .odt format which
is nominally more open, but then the people who use MS Word (I hear
there are still a few of them) couldn't read it.  There's no great way
to send around a redlined document and I'd say that Word formats are
currently the least bad.  I presume you know that the more recent
.docx file format is ISO/IEC 29500, so that should make everyone
happy, modulo the detail that it's so complicated that in practice the
older nominally un-open .doc interoperates a lot more reliably.

R's,
John

Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[John Levine]

I wonder, though, if this document might have contained change bars that 
nobody but people who use MS
Word would see.   Opening the document up in Preview on the Mac, it's just 
four or five pages of
text, with no way to evaluate what changed.

It looks fine in OpenOffice.  Really.

I agree with your suggestion that rfcdiff would be nice, too.

Re: Community Feedback: IETF Trust Agreement Issues

[John Levine]

We have recently been asked permission to republish the TAO with a creative 
commons
license, but according to counsel, the current trust agreement does not give 
the
trustees the rights to do this.

- Without specific language being added to the trust agreement, we cannot 
grant these
types of requests.  

I'm looking at section 9.5 of the trust agreement, and I'm looking at
the CC Attribution-NoDerivs 3.0 license, and I don't see what's in the
CC license that conflicts with the trust agreement.  The TA says that
derivatives belong to the IETF, the CC license says no derivatives, the
TA says that the goodwill belongs to the IETF, the CC license says no
disparaging, which isn't the same thing but leans in the same direction.

If they want a different CC license, that's easy, the answer is no.

http://creativecommons.org/licenses/by-nd/3.0/legalcode

Once a domain name or trademark is registered by the trust, it cannot be 
abandoned
even if it is no longer needed.  

- We must maintain these in perpetuity based on legal counsel review of the 
current language

I have more sympathy for this one.  Although the renewal fee for a
domain name is usually trivial, what happens if some third party files
a UDRP challenge to or a lawsuit about a domain name that the IETF is
no longer using?  Do they have to run up legal bills responding to and
fighting it?

For trademarks, the renewal fee is $400 payable 5 years and 10 years
after registration, and every 10 years after that.  But along with the
renewal fee, the registrant has to send in a sworn statement saying
that the mark is still in use in commerce, listing the goods and
services on which it's used, and if requested providing samples.  If
the IETF isn't actually using the mark, what is the trust supposed to
do?  Furthermore, unlike patent or copyrights, a trademark owner has
to police unauthorized use and challenge it legally, or risk losing
the trademark to what's known as genericide.  This is a lot of work
for a trademark you want, and it's absurd for one you don't.

My suggestion would be that the abandonment process take a year,
requiring four quarterly announcements and solicitation of comments to
a public venue such as the IETF general list.  After the year,
considering all responses received, if the trustees believe that there
is consensus to abandon, they do so.

If people are concerned that the trustees would do something silly,
the solution is to pick better trustees, not to make more complex
rules.

R's,
John

Re: Community Feedback: IETF Trust Agreement Issues

[John Levine]

 Actually, verbatim translations are already allowed under the existing IETF
document license. It's other modifications that are not allowed under IETF, 
but which
CC-BY would permit. 

That sounds right. Someone might want to add commentary (even in English) to 
the Tao,
such as to discuss local participants, diversity, and so on.

Someone might, or they might rewrite it to say that IETF meetings have
simultaneous translation, and while the IAB is all U.S. greybeards,
the IESG members are chosen to represent the gender and ethnic balance
of the whole world.  Or they might rewrite it to say that the IETF has
corporate members, you have work for one to participate, and all RFCs
are standards.

The CC license says

 You must not distort, mutilate, modify or take other derogatory
 action in relation to the Work which would be prejudicial to the
 Original Author's honor or reputation.

Would those changes be prejudicial to your honor or reputation, or are
they just wrong?  How much are we willing to spend to find out?

It's extremely hard to let just one of the cat's paws out of the bag.
In practice either we have change control or we don't, and I don't see
much sentiment for giving it up to unknown CC users.

On the other hand, if they just want a CC license, it looks to me like
they can use CC BY-ND right now.

R's,
John

Re: Speaking of VAT

[John Levine]

 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.

John

VAT is a European Union tax that all member states are required to levy
on the supply of goods and services, although there is flexibility about
the rate it is levied at and what it is levied on. ...

Yes, but there are also reciprocal agreements separate from the usual
credit for VAT paid, with non-EU countries including Israel.  The page
that Ray pointed to describes this.

R's,
John

Re: [iaoc-rps] RPS Accessibility

[John Levine]

Ironically, this IETF everyone who stayed at the Intercontinental was walking 
around
with an RFID key in their pocket the whole meeting.   How many of us put them 
in
faraday cages?

I put all of my cards in a faraday cage, but perhaps that's just me,
and because I carry an RFID passport card.

R's,
John

Re: Berlin was awesome, let's come again

[John Levine]

Agreed.  One minor downside was needing an additional flight.  It seems AB who
handles about a third of the traffic rather than Lufthansa that handles about 
one
fifth, was not the best choice where a 6 hour layover extended an hour on the 
tarmac
in a hot plane. 

With any luck, the next time we meet in Germany, they'll have opened
the new and much larger Berlin Brandenburg airport which will enable
far more direct intercontinental flights.

Re: [iaoc-rps] RPS Accessibility

[John Levine]

In article m2li4ew2nk.wl%ra...@psg.com you write:
 Ironically, this IETF everyone who stayed at the Intercontinental was
 walking around with an RFID key in their pocket the whole meeting.
 How many of us put them in faraday cages?

one.  i made it a habit

Two.  I have a wallet with a built-in tinfoil hat.

http://www.idstronghold.com/RFID-Blocking-Secure-Wallet-Bi-Fold-10-Slots/productinfo/IDSH7005/

Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)

[John Levine]

If there is a serious drive to discontinue the weekly posting
summary - I strongly object.

As far as I can tell, one person objects, everyone else thinks it's fine.

Seems like rough consensus to me.

R's,
John

Speaking of VAT

[John Levine]

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.

In Buenos Aires, the VAT rate is 21% on most goods and services, with
a special 27% rate on telecom services.

Just saying,

R's,
John

PS: In Vancouver last year there was a combined federal and provincial
VAT, called HST, of 12%.  Now they're split, with the 5% federal VAT,
called GST, at 5%, and the 7% provincial sales tax (PST) applied
separately.

Re: Berlin was awesome, let's come again

[John Levine]

Venue was great, food options here and in the city were great,
all-around great experience. Let's come again!

Agreed.  Great meeting overall, venue worked well, plenty of places
to eat and stay within reasonable distance, and suitable distractions
for those half days when you don't have any sessions.

Perhaps next time we can come to Berlin sometime other than the middle
of the summer to avoid the heat issues.

R's,
John

Re: Berlin was awesome, let's come again

[John Levine]

-1 on doing it during the winter speaking as a Californian who doesn't
even own a winter coat

I expect you could get a very nice one at KaDeWe.

Re: Berlin was awesome, let's come again

[John Levine]

In article 6462.1375450...@sandelman.ca you write:
-=-=-=-=-=-


Many countries let you claim VAT paid as you leave.

Only on goods you export, not on hotels and meals.

I hope the IETF can figure out how to more efficiently reclaim the VAT
it pays on European expenses so the whole thing is a wash.

R's,
John

Re: where's the data, was IAB Statement on Dotless Domains

[John Levine]

In article 51e368f9.70...@dougbarton.us you write:
On 07/12/2013 02:40 PM, John R Levine wrote:

 Point your browser at http://dk/ or http://tm/ and see what happens.

As John points out, the ccTLDs are already doing this. ICANN has no 
authority to tell the ccTLDs NOT to do it, thus restricting the gTLDs 
from doing it (via their contract with ICANN) would arguably be unfair 
in any number of parameters, including (possibly) legal ones.

No, you completely misunderstand my point.

If you try out the existing dotless TLDs, you will find out that they
sort of work for web pages, only because very few sites have hosts
named dk or ai, and mail to them works very badly if at all.  So
there is some actual data we could cite about how badly they work, to
support the hand waving in all the anti-dotless documents to date.

It's silly to think that fairness between ccTLDS and gTLDs matters
at all.  For one thing, gTLDs have for over a decade followed rules
that don't apply to ccTLDs, such as accepting registrations only
indirectly, and publishing WHOIS about all registered names.  For
another, anyone who's looked through the new TLD applicant guidebook
would know that every applicant has agreed to page after page of legal
releases in ICANN's favor, and that dotless domains are specifically
forbidden without a waiver from ICANN, which ICANN can grant or not at
its discretion.

The only reason this has come up is that one (1) of the 1900 new TLD
applications has asked for a waiver to do a dotless domain, and that
applicant happens to be Google applying for .SEARCH.  ICANN can just
say no.  Or they might not even have to, since Google's is only one of
four competing applicants for .SEARCH, and there is no reason to
assume that they would necessarily be the winner at the end of the
negotiations.

R's,
John

Re: IAB Statement on Dotless Domains

[John Levine]

I guess I'm missing something. How exactly is having a gTLD going to bring in
the Big Bucks? Do people actually type addresses into the address bars on
their browsers any more, or do they just type what they're looking for into
the search bar?

Let's just say you're not allowed to ask that question, any more than
you can ask a fundamentalist Christian how he knows he's going to
heaven.

You are definitely not allowed to look at the history of .AERO,
.TRAVEL, .JOBS, .ASIA, .MUSEUM, .COOP, .MOBI, .TEL or .PRO.

Re: IAB Statement on Dotless Domains

[John Levine]

 domains are going to be dotless and three of the biggest dotless domains
 are going to be called .apple and .microsoft and .google and they are going

I've read the applications for .apple, .microsoft, and .google.  None
of them propose to use dotless names, only the usual 2LDs.  At this
pont there is just one application that proposes a dotless name,
Google's .search, and it's far from clear what will happen to that, or
even if that application would beat out the competing ones from
Amazon, Donuts and dot Now, none of which are dotless.

Do you think they are lying when they say they won't be dotless?

R's,
John

PS: The applications are all linked here.  The financial info is
redacted, but the technical stuff is all present.

https://gtldresult.icann.org/

Re: IETF 87 Registration Suspended

[John Levine]

It seems that the rules might be somewhat similar all over europe:

   http://www.tmf-vat.com/vat/german-vat.html

You would think so, which leads to the question about what's different
in Berlin from Paris and Prague and Maastricht.

R's,
John

submission tool not sending confirmations ?

[John Levine]

I'm trying to submit and I-D, and I'm not getting the usual
confirmation mail.  My mail logs show nothing, no attempts, no
failures.  It worked the last time I tried it on Sunday.  (Yes,
I gave it a working address.)

Anyone else seeing this?

R's,
John

Re: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)

[John Levine]

In article 51cf38eb.3080...@dougbarton.us you write:
On 06/29/2013 05:28 AM, Noel Chiappa wrote:
   From: j...@mercury.lcs.mit.edu (Noel Chiappa)

   Yet.

 PS: I probably should have added a :-) to that. Sorry, it's early, the
 brain's not firing on all cylinders yet, and I was so entranced by the chance
 to set the record for the shortest ever IETF list e-mail... :-)

No.

?

Re: IETF, ICANN and non-standards

[John Levine]

I think this is the correct strategy, BUT, I see as a very active participant 
in ICANN
(chair of SSAC) that work in ICANN could be easier if some more technical 
standards where
developed in IETF, and moved forward along standards track, that ICANN can 
reference.

As a concrete example, the EPP systems used in production by TLD
registries use extensions that are documented only in I-Ds, often
expired I-Ds, or in dusty I-D like web documents.  If you look at the
applications for new TLDs on the ICANN web site at
https://gtldresult.icann.org/application-result/applicationstatus you
will find that nearly all of them plan to use EPP extensions not
described in an RFC.  Most of these extensions should be utterly
uncontroversial, e.g., one to synchronize renewal dates among multiple
domains, or another to tell a client that its credit balance has
dropped below a threshold.

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?

R's,
John

Re: Content-free Last Call comments

[John Levine]

So, if wg discussion has been ordered mute by the wg chairs because
some wg participants believe the group-think consensus is good enough,
can those objections again be raised in IETF LC or are they set in stone?

If that were ever to happen, I don't see why not.

In the recent cases I've seen where someone claims this is an issue,
what actually happned is that a person only tangentially involved in
the WG is obsessing about some technical wart and refuses to (or
worse, can't) understand the overall context that led the WG to decide
what it did.

It's hard to see any benefit to rehashing such arguments in front of
the whole IETF.

R's,
John

Re: financial fun with an IETF Meeting in South America

[John Levine]

 The move appears to be related to new, restrictive 
 regulations the Argentine government has imposed on currency exchanges.' 
 According to the Telegraph, 'The new regulations required anyone wanting 
 to change Argentine pesos into another currency to submit an online 
 request for permission to AFIP, the Argentine equivalent of HM Revenue  
 Customs. ...

This isn't likely to change soon.

Back in 2001 the Argentine government defaulted on about $100 billion
of debt.  Since then they got 93% of the bondholders to agree to
restructure and accept partial payment, and had been making payments
to those and nothing to the other 7%.  But an outfit called Elliot
Management bought some of that 7%, took Argentina to court in New
York, where the bonds were issued. and earlier this year the New York
court decided that if Argentina pays anyone, they have to pay
everyone, including the 7% that still demand payment in full.
Argentina has tried a variety of gimmicks to try to pay the
restructured bonds and not the holdouts, mostly with the effect of
annoying the judge.  Since the payments are made through Bank of New
York, whose management has no interest in going to jail, nobody's
currently getting paid, leading to great gnashing of teeth but no
progress.

For this most part, this wouldn't affect foreigners going to Argentina
since we'd be changing hard currency into pesos, which the government
encourages, since their supply of hard currency is very limited.  (If
they had more, they could pay off the holdouts, but they don't.)
Except that the holdouts have done a lot of gimmicky things to try and
get their money, notably slapping a lien on the Argentine navy's
sailing training ship Libertad while it was in port in Ghana.  If they
slap a lien on an Argentine airplane, for example, things could be
somewhat chaotic.

These kinds of currency controls are quite common in the aftermath of
a currency crisis, e.g., in Iceland and Cyprus, but Argentina has had
a rolling crisis for decades.

R's,
John

Issues in wider geographic participation

[John Levine]

I think this is a summary of the issues people have mentioned that
discourage participation from LDCs, in rough order of importance.

* People aren't aware the IETF exists, or what it does, or that it has
an open participation model

* People don't read and write English well enough to be comfortable
participating

* People are unaccustomed to and perhaps uncomfortable expressing
overt disagreement

* People don't think they have anything to contribute to an organization
that is mostly people from rich countries

* People don't have adequate Internet access for mail, or to use the
remote participation tools

I have to say that I don't see one or two meetings in South America
addressing any of these.  Given that the incremental cost to the
participants, compared to meeting in North America, would likely be on
the order of a million dollars, it seems to me very likely that there
are better ways to spend the money.

For example, if language and net access is a problem, it might be
interesting to set up a remote participation center in B.A. during one
of the North American meetings (it's one time zone off from Toronto)
with screens and cameras, paid interpreters, and a few volunteers to
help explain what's going on.

R's,
John

Re: IETF Meeting in North America

[John Levine]

Feh.  There is no winter in Vancouver.  On the other hand there are
salmon and steelhead.

I distinctly remember a meeting in Vancouver where certain attendees
were complaining about the winter weather, with temperatures plunging
below zero* and snow drifting 1 to 2*.  

The specific complaint was that this made it uncomfortable to wear
sandals.

R's,
John


* - we're engineers, that would be celsius and centimetres

Re: IETF Meeting in South America

[John Levine]

My question is about whether we would be there during the peak season,
and when exactly is that season?

I gather you're in Ottawa.  Here's Air Canada's calendar rules for
their lowest fare to EZE:

 ORIGINATING CANADA -
 PERMITTED 01JAN THROUGH 08JUL OR 06AUG THROUGH 16SEP
 OR 01OCT THROUGH 16DEC OR 24DEC THROUGH 31DEC ON THE
 FIRST INTERNATIONAL SECTOR. SEASON IS BASED ON DATE
 OF ORIGIN.

   ORIGINATING ARGENTINA -
 PERMITTED 13JAN THROUGH 30JUN OR 21JUL THROUGH 02SEP
 OR 17SEP THROUGH 01JAN ON THE FIRST INTERNATIONAL
 SECTOR. SEASON IS BASED ON DATE OF ORIGIN.

I checked some US cities, turned out the cheapest fares were also
AC (rather an odd routing if you're starting at LAX but think of
all those miles) and the dates are:

  ORIGINATING UNITED STATES -
 PERMITTED 01FEB THROUGH 13JUL OR 04SEP THROUGH 30NOV
 ON THE FIRST INTERNATIONAL SECTOR. SEASON IS BASED
 ON DATE OF ORIGIN.

   ORIGINATING ARGENTINA -
 PERMITTED 17SEP THROUGH 31DEC OR 27JAN THROUGH 22FEB
 OR 01APR THROUGH 20JUN ON THE FIRST INTERNATIONAL
 SECTOR. SEASON IS BASED ON DATE OF ORIGIN.

I don't know what happens in B.A. in July and August in the middle of
the winter.  The cheapest fares from Paris have no calendar limits.
The cheapest fares from Frankfurt are only good Aug-Oct.  Go figure.

Re: IETF Meeting in South America

[John Levine]

 I suspect that if the meeting is approved, the food in Buenos Aires
 will be more interesting than it was in Adelaide, at least for many of
 us. The locals speaking English might also be more understandable. :-)

If you like steak or pizza and lots of pretty good red wine, the food
in Buenos Aires is quite excellent.  If you want something else, it's
spotty.  But I agree that it's likely to be as good a place in South
America as any to meet.

R's,
John

Re: IETF Meeting in South America

[John Levine]

On May 23, 2013, at 7:44 PM, Melinda Shore melinda.sh...@gmail.com wrote:
 So the question is why we aren't seeing more drafts, reviews, and
 discussions from people in Central and South America,

Language?

Possibly, but we get quite a lot from parts of Asia where I'd think
the language issue would be more severe.

I agree with Melinda, it would be good to figure out how to get people
in South America more involved in the IETF, but I also agree that
there is no reason to expect that an IETF meeting there would make any
difference.

Re: Last Call: Change the status of DKIM (RFC 6376) to Internet Standard

[John Levine]

I use DKIM via two independent implementations, perl Mail::DKIM to
sign outgoing mail, and C language opendkim to check incoming mail in
the SMTP daemon.  It is a mature protocol and the implmentations
interoperate with no problems I've ever seen.

I support promoting 6376 to Internet Standard.

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

What's a reasonable and non-discriminatory patent license?

[John Levine]

The Patently-O blog has a new guest post by Jorge Contreras, who among
other things is the IETF's lawyer, on a recent court decision about
how to determine what's an appropriate RAND royalty rate for
standard-essential patents.  The patents and standards in question
aren't from the IETF (they're ITU H.264 and IEEE 801.11) but the
article is highly relevant to the patent issues that crop up here.

Jorge writes well and it's quite readable.

http://www.patentlyo.com/patent/2013/04/so-thats-what-rand-means-a-brief-report-on-the-findings-of-fact-and-conclusions-of-law-in-microsoft-v-motorola.html

-- 
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: Sufficient email authentication requirements for IPv6

[John Levine]

 There seems to be a faction that feel that 15 years ago someone once
 blacklisted them and caused them some inconvenience, therefore all
 DNSBLs suck forever.  I could say similar things about buggy PC
 implementations of TCP/IP, but I think a few things have changed since
 then, in both cases.

There's an inherent problem with letting 3rd parties affect email 
traffic, especially when there's no way to hold those 3rd parties 
accountable for negligence or malice.

Like I said, things have changed since 1996.  I talk to Spamhaus every
day am intimately familiar with their processes, and understand who
they report to.

In the meantime, see

http://www.circleid.com/posts/20130301_icann_announces_blocking_usage_review_panel/

Re: Sufficient email authentication requirements for IPv6

[John Levine]

Quoting Nathaniel Borenstein  [1]:

   One man's blacklist is another's denial-of-service attack.

Email reputation services have a bad reputation.

They have a good enough reputation that every non-trivial mail system
in the world uses them.  They're not all the same, and a Darwinian
process has caused the best run ones to be the most widely used.

There seems to be a faction that feel that 15 years ago someone once
blacklisted them and caused them some inconvenience, therefore all
DNSBLs suck forever.  I could say similar things about buggy PC
implementations of TCP/IP, but I think a few things have changed since
then, in both cases.

R's,
John

Re: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated April the first

[John Levine]

That said, I did at one point have to exercise my diplomatic skills when I got 
forwarded a customer (nameless
here for evermore) question about whether support for RFC 3514 was on our 
roadmap.

Think of it as free market intelligence on your customer base.

Of course we've only had April 1 RFCs for 35 years now.  Who knows
what horrible problem they may yet cause that we haven't noticed yet.

Re: Sufficient email authentication requirements for IPv6

[John Levine]

In practice, the /64 prefix of the IPv6 address has very much the same
administrative properties as the /32 value of the IPv4 address.

You would hope so, but I know hosting places that give their customers
a /128 in a shared /64.  They claim that their routers make this hard
to fix.  I don't know the details.

Like I said, whitelisting known good single IPs can probably work, but
it is a major unsolved question how to figure out the size of the
relevant bad range if you see an IP doing bad stuff.

R's,
John

PS: Just to save time, any answer starting all you need to do is ...
doesn't work.  We've been around this barn enough times that there is
severe soil erosion.

Re: Sufficient email authentication requirements for IPv6

[John Levine]

As a result, it is questionable whether any IPv6 address-based reputation 
system can be successful (at least those based on voluntary principles.)

It can probably work for whitelisting well behaved senders, give or take
the DNS cache busting issues of IPv6 per-message lookups.

Since a bad guy can easily hop to a new IP for every message (offering
interesting new frontiers in listwashing) I agree that it's a losing
battle for blacklisting, other than blocking large ranges of hostile
networks.

Fortunately, the IETF as a whole is not called upon to solve this
problem right now.  People interested in mail reputation are welcome
to drop by the spfbis WG and the discussions in appsarea about
updating authentication and authentication logging RFCs.

Re: Getting rid of the dot

[John Levine]

In article 51489888.6050...@internet2.edu you write:
I want my badge to have my name and a small screen showing the room I
just came from.

I want the screen to show the room I'm going to next.  And it should
be upside down so I can read it.

Re: Getting rid of the dot

[John Levine]

In article 5148d415.1000...@internet2.edu you write:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/19/13 20:38, Michael Richardson allegedly wrote:
 Actually, I'd just settle for a badge that wasn't always
 backwards.

It costs a lot more to get lanyards that attach at two corners.

If our t-shirts had pockets, it wouldn't be a problem.

Re: raw meeting minutes (Re: meetecho praise)

[John Levine]

It would also allow some crows-sourcing of corrections and additions to 
the raw minutes...

CAW CAW CAW CAW !!!

Re: Review: draft-iab-dns-applications-07

[John Levine]

In article 5142fe8f.1020...@dcrocker.net you write:

Review of:Architectural Considerations on Application Features in
   the DNS

I-D:  draft-iab-dns-applications-07

Reviewed by:  D. Crocker

I had similar comments to Dave's on earlier versions of this draft,
and although I think the recent draft is more of an improvement than
he seems to, it still has deep problems.

For me, the worst problem is that it's utterly unclear what it's
trying to say, and whether it is describing functional problems (e.g.,
DNS responses that are too large for UDP) or aesthetic ones (the
complex way that NAPTR is used, even though the DNS lookups are dead
simple.)

It would be a help if the documents' authors could explain in a few
lines what they're trying to say.  I'm aware of some fairly clear
technical advice one might give about DNS suitability, e.g.:

* keys must be domain names

* no fuzzy matching beyond case folding and what DNS wildcards do

* name space must map reasonably into DNS tree (we can argue about
  whether _prefix is reasonable)

* values must work as an unordered set of typed records

* values must not be too big, for some version of too big

* names that look related may not be, tree walks are bad

* lookup patterns that cache well are good

etc.  

I think those are all in the current draft, but they're mixed in with
a lot of other stuff the point of which is hard for me to understand.


Here's a concrete example of the sort of question that I would hope
this draft would answer: last year I was thinking about how to do DNS
blacklists and whitelists for IPv6 addresses sending e-mail.  The
obvious approach would be to adapt the design of rDNS and assign a
domain name to every possible IP address, then look up that name to
see if it's blacklisted or whitelisted, like we do with IPv4
addresses.  The problem is that it would be trivial for a hostile
sender to hop to a new IP address for each new message, leading to a
different DNS query, which would have dreadful cache behavior and
overload servers.

So I came up with a completely different approach adapted from
database B-trees, a bushy tree of blocks of data representing lists of
address ranges.  The key for each block is the lowest IP address
described by that block as a hex number followed by the name of the
BL, e.g, 1234567812345678.bl.example, the data in each block is a
bunch of variable length binary fields stashed in a TXT record.
(Despite its name, a TXT record can contain arbitrary binary data.)
The data in each block tells whether it needs to look at another
block, and if so the exact name of that block.  A little testing
confirms that the number of lookups is quite reasonable, and the
structure of the database means that most lookups will be satisfied
from the local DNS cache.  The details are in expired draft
draft-levine-iprangepub-02.

Is this an appropriate use of the DNS?  It looks up fixed keys to get
moderate sized results, and the lookups cache well.  It shares the
NAPTR aspect that the records are complex and don't look anything like
A or  records, and the processing to use them is quite complex,
albeit well defined.  I would want to be able to look at this draft to
figure out the answer.  As it stands, I can't.

R's,
John

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

[John Levine]

If the disk goes bad so as to provoke a misread of a sector, post
write, the file is effectively corrupted. If this happens with git,
the checksum calculated on write will fail to match, and the
corruption is detected.

If you're worried about that (not totally unreasonable on modern
disks) wouldn't it be better to use a filesystem like zfs that checks
for corruption at the filesystem level?

In practice, rsync works great.  I pull the RFCs and I-Ds every night.

Re: fixing language in documents written by Martians and others

[John Levine]

Moving on, what I do believe is that many i-d's could benefit from a
review by a linguist.

This role, IMO, is different from the role of an editor. The linguist
doesn't need to have any technical background. He is more like a syntax
/ semantic verifier. It's common practice in other fields.

This sounds like what a copy editor does in the publication process.
The RFC production center staff has always done copy editing as part
of the process of turning an I-D into an RFC.

Nonetheless I think that John K's suggestion has considerable merit
for I-Ds whose authors are not fluent in written English (a situation
that I agree has surprisingly little to do with whether the author is
a native English speaker.)  The reason is that often it is hard to
tell what a document is supposed to be saying, and the only way to
find out is to go back to the author and ask.  This is very slow and
time consuming if each iteration has to go from the editor to the
author and back, If the document has a co-author who's working on it
all along, the rewriting could happen as the document was developed,
leaving only a final check for the copy editor.

-- 
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: [86all] Caribe Overbooking

[John Levine]

 8.10  Hotel Booked Beyond 100% Capacity.   Hotel agrees not to
 relocate any conference attendee holding a guaranteed
 reservation only after it has relocated any other guests
 required to be relocated. 

I tried reading the sentence above several times and have
concluded it isn't me -- it doesn't parse properly.

I read it as saying that they can't walk any conferees until they've
walked all the non-conferees.

R's,
John

PS: Walk in the hospitality industry sense.

Re: Diversity of IETF Leadership

[John Levine]

 - Each of the confirming bodies (the ISOC Board for the IAB, the
   IAB for the IESG, and the IESG for the IAOC) could make a
   public statement at the beginning of each year's nominations
   process that they will not confirm a slate unless it
   contributes to increased diversity within the IETF leadership,
   or it is accompanied by a detailed explanation of what
   steps were taken to select a more diverse slate and why it was
   not possible to do so.

That sounds a lot like quotas.  Let's not go there.  It would be
entirely reasonable to tell future nomcoms that increased diversity
(for some definition of diversity) is one of their goals and expect
them to do their job in good faith, as nomcoms have consistently done.

A large point that you've only touched on is that we can't create
diversity by fiat.  While it is admirable in some ways that many of
the people active in the IETF now are the same people who were active
in the IETF and its predecessors 20 or 30 years ago, it's also kind of
scary, since nobody is immortal (although in a few cases it may seem
that way.)

In some senses the IETF is phenomenally open, since anyone with an
e-mail address can sign up for the mailing lists and join the fun, but
in other ways it's really difficult to break in, partly because the
topics can be complex and subtle, partly because of a (not wholly
unreasonable) impatience with people who out of ignorance or otherwise
want to reopen ancient arguments, or who imagine that the way to
define a standard is to create a kitchen sink of everyone's favorite
featurettes.  (No, it's not better to support both XML and JSON than
just one of them.)  These are reasonably straightforward to deal with,
largely by pointing people at list archives, the Tao, and other things
we've written over the years.

What concerns me more is that people who could contribute don't.  Part
of that is because some parts of the IETF have become ossified, which
is an issue I don't want to address here, but a lot of it is that
people still just don't know who we are.  The IRTF's newish ANRP looks
like a good model, it picks promising students who probably wouldn't
pay any attention to us, and waves a small prize and a junket to an
IETF meeting at them.  The quality of the papers has been very good,
but equally important, they go back home and tell their friends about
their favorable experience at the IETF/IRTF.

There's only so many prizes we can hand out, but I think it's worth
thinking about what other modest inducements we might come up with to
get people who would be good IETFers to give us a look.

R's,
John

Re: Time zones in IETF agenda

[John Levine]

So I guess one still has to keep track of daylight savings.

I've been trying to explain this to people for years, that I cannot
tell when their meeting is if they will not tell me what time zone
they're using.  

It turns out most people don't actually know what time zone they're
using (no, San Francisco is not on PST in July) so I've found the
least error prone approach is to ask what place their time is for,
since even if they don't know what time zone their city is in, I do.

 Personally I 
prefer to have local time for meetings, otherwise UTC is nice.

We should meet in Iceland, where the local time is always UTC.  It has
other advantages, too, roughly equal ping times to the US and Europe.

R's,
John

Re: Time zones in IETF agenda

[John Levine]

t.p.  daedu...@btconnect.com wrote:
Can anyone help an ignorant European?  Given a meeting time of 12:00
Noon ET [sic] on Sunday 10th March 2013, what is that in UTC?  Daylight
saving will have started by then in the USA but not in Europe so the
scope for being an hour late or an hour early is much increased.

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.

-- 
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: Call for Comment: RFC Format Requirements and Future Development

[John Levine]

There should be an immutable requirement that any alternative format
MUST NOT increase the size by more than a factor of two compared to
ASCII text.

So you're saying you're unalterably opposed to the RFC editor providing
PDF, HTML, epub, mobipocket, and every other format that people actually
use on modern computers, as well as anything that includes reasonably
legible images?

If that's not what you mean, what DO you mean?  We all seem to agree
that we want to continue to provide the traditional line printer image
format, but on today's Internet where 20Mb/sec cable modems aren't
particularly fast, it's silly to demand that documents be sized for
floppy disks.

R's,
John

Re: [IETF] Internet Draft Final Submission Cut-Off Today

[John Levine]

I'd be willing to deal with an embargo for draft-ietf-*, but don't see at all 
why it extends
to other drafts.

We have software.  Embargo drafts for WGs that are actually meeting
during the preceding week, leave the others alone.

Re: IPv6 update for BCP5?

[John Levine]

On 1/27/13 10:07 AM, tglassey wrote:
 So... we probably need a IPv6 update for BCP5 (RFC1918), doesnt that
 make sense?

My understanding is people have been using ULAs (RFC 4193) for this type 
of functionality.

That's certainly one option.

The other is just to apply for some IPv6 address space from your local
RIR.  There's plenty of it, they don't care if you don't plan to make
it routable outside your own network.

It is definitely NOT a goal of IPv6 to create hacks to permit two
different interfaces to have the same IP address, anywhere.

Re: A modest proposal

[John Levine]

Do none of you know what the phrase a modest proposal refers to?

No, but I'm sure that this will be a Great Leap Forward.

Re: A modest proposal

[John Levine]

 Additionally, I can't understand why each line is terminated with
 CRLF, why use two characters when one will do.

Microsoft-OS text editors. Seriously.

My, what a bunch of parvenus.  SIP got it from SMTP, SMTP got it from
Telnet.  Back in the 1960s we all used CRLF because on a
mechanical model 33 or 35 Teletype, CR really returned the carriage,
LF really advanced the platen, and you needed both.  I first ran into
CR/LF on a PDP-6 in about 1968, but I know it wasn't new then.

A single LF to start a new line arrived with the model 37 Teletype,
and Unix was, as far as I know, the first system to use just \n as the
line terminator starting in the early 1970s.  But by then the Arpanet
protocols were designed, and the hassle of changing wasn't (and still
isn't) worth it.

Re: I'm struggling with 2219 language again

[John Levine]

 But some people feel we need a more formal specification language
 that goes beyond key point compliance or requirements definition,
 and some are using 2119 words in that role and like it.

Having read specs like the Algol 68 report and ANSI X3.53-1976, the
PL/I standard that's largely written in VDL, I have an extremely low
opinion of specs that attempt to be very formal.  

The problem is not unlike the one with the fad for proofs of program
correctness back in the 1970s and 1980s.  Your formal thing ends up
being in effect a large chunk of software, which will have just as
many bugs as any other large chunk of software.  The PL/I standard is
famous for that; to implement it you both need to be able to decode
the VDL and to know PL/I well enough to recognize the mistakes.

What we really need to strive for is clear writing, which is not the
same thing as formal writing.  When you're writing clearly, the places
where you'd need 2119 stuff would be where you want to emphasize that
something that might seem optional or not a big deal is in fact
important and mandatory or important and forbidden.

R's,
John

Re: travel guide for the next IETF...

[John Levine]

Oh, if you were considering a visit to one of the nearby theme parks,
check out their latest hi-tech innovation:

http://www.nytimes.com/2013/01/07/business/media/at-disney-parks-a-bracelet-meant-to-build-loyalty-and-sales.html

Re: travel guide for the next IETF...

[John Levine]

 yeah, I know, but I gotta say to the IEEE SERIOUSLY?

Apparently the IEEE folks love it, have been there before.

Look at the reviews on Tripadvisor or Google, and for the most part
they're quite positive.  We're an odd group, much more price sensitive
than most conventioneers, and way more demanding about food options.

Having said that, I'm renting a car and staying at the Sheraton about
2 miles away for $16/day plus a surprisingly small number of points.
If you ask nicely, you can drive around with me and look for places to
eat.

Re: travel guide for the next IETF...

[John Levine]

So if you don't attend IEEE, quit your whining:  at least you won't have 
to eat he same hotel food for 2 weeks in a row...

You don't have to eat there.  Check out the reviews of this restaurant
across the street:

https://plus.google.com/118141773512616354020/about

Re: travel guide for the next IETF...

[John Levine]

 Good... but how to get there?

If you plan to do anything more than spend the whole trip at the
meeting hotel, you need a car.  Orlando is a cheap rental town, it's
not hard to rent something for $100 total for five days.

Cape Canaveral and Cocoa Beach are only an hour away for people who
think the list of attractions in Orlando itself is a bit thin.

R's,
John

PS: Is Xanadu The House Of The Future still in Kissimmee?  How about
the Tupperware Museum of Food Storage?

Re: A mailing list protocol

[John Levine]

Is there an IETF standard format for handling inline quote replies?

It's defined in the same RFC that specifies the setting of the
Reply-To: header in mailing lists.