Re: paralysis

[Paul Hoffman / IMC]

At 3:03 PM -0800 3/7/04, Michael Thomas wrote:
From what I can tell, anything that falls
short of perfection then gets summarily
executed.
The majority of the "anti-spam" proposals being actively discussed 
are variants on the "prove the sender is who he says he is". None of 
these are perfect, yet:

- they are being actively discussed in the ASRG

- they are being actively discussed on the [EMAIL PROTECTED] mailing list

- there was a BOF about them last week in Seoul

- some people are creating experimental implementations and looking 
at the results

This seems different than "summarily executed".

--Paul Hoffman, Director
--Internet Mail Consortium

Re: paralysis

[Paul Hoffman / IMC]

At 8:19 AM -0800 3/6/04, Michael Thomas wrote:
So... instead of pointing out the obvious that
there is no silver bullet, wouldn't it be a lot
more productive to frame this debate in terms of
what incremental steps could be taken to at least
try to change the overall climate?
Only if such framing includes the costs of the steps. To date, most 
of the initial proposals we have seen on this (and many other) lists 
have three attributes in common:

- They don't list the obvious problems

- They don't even guess at the costs of those problems

- They don't have an analysis of how hard or easy it will be for 
spammers to adapt to the proposal

We have already seen that every deployed anti-spam solution has 
costs. We have already seen that those costs can be listed with an 
extra hour or two of effort. We have already seen that spammers 
quickly adapt to anti-spam tools.

This is not that much different than doing a security analysis on new 
protocol proposals. "Just authenticate {senders | MTAs | messages}" 
is not that different than "we authenticate by sending a password in 
the clear".

--Paul Hoffman, Director
--Internet Mail Consortium

Re: visa requirements (US citizens)

[Paul Hoffman / IMC]

At 10:46 AM -0800 1/28/04, Kevin C. Almeroth wrote:
 >>The Korean embassy page that is linked to from the IETF meetings page
() makes it
pretty darn clear that US folks should get a visa. They do have a
link from that page saying how wonderful US-Korea relations are, of
course.
What part are you reading that says this?

"# You may enter Korea without a visa for a stay up to 30 days
or less for tourism, visiting, or transit to another country when
carrying a valid US passport."
Seems to me to pretty clear that a visa is not needed.
I am not a lawyer, but I don't think attending a professional meeting 
is either "tourism", "visiting", or "transit to another country". 
YMMV.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: visa requirements (US citizens)

[Paul Hoffman / IMC]

At 2:31 PM -0500 1/27/04, Steve Bellovin wrote:
I was advised by our corporate travel consultants that I should get a
visa.  Given the current international climate -- there was an article
in last Thursday's Wall Street Journal about how other countries
are retaliating for the current U.S. fingerprinting and visa application
requirements -- this may be a prudent course of action.
The Korean embassy page that is linked to from the IETF meetings page 
() makes it 
pretty darn clear that US folks should get a visa. They do have a 
link from that page saying how wonderful US-Korea relations are, of 
course.

Showing up in the airport without a visa and saying "but someone at 
one of your consulates told me I didn't need one" may go over as well 
in other countries as it does in the US...

--Paul Hoffman, Director
--Internet Mail Consortium

New mail-ng mailing list open for sign-ups

[Paul Hoffman / IMC]

Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See  for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.

--Paul Hoffman, Director
--Internet Mail Consortium

New mail-ng mailing list open for sign-ups

[Paul Hoffman / IMC]

Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See  for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: SMTP Minimum Retry Period - Proposal To Modify Mx

[Paul Hoffman / IMC]

At 12:48 PM -0500 1/13/04, [EMAIL PROTECTED] wrote:
On Tue, 13 Jan 2004 07:21:53 EST, [EMAIL PROTECTED] (Mike S)  said:

 > As I said, fascist.

Godwin.
Valdis, you have confused two protocols that produced similar results 
but used different underlying transports and different signalling.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Has anybody heard back from the Hotel in Seoul?

[Paul Hoffman / IMC]

At 2:39 PM -0600 1/5/04, Pete Resnick wrote:
I got no response (other than an initial e-mail telling me I filled 
out part of the form incorrectly, which I answered by e-mail). After 
hearing nothing, I called them and got a confirmation number. 
Perhaps it is a NACK rather than an ACK protocol?
Not to worry everyone, but I got an ACK via FAX a few days after I 
faxed them my reservation.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Tag, You're It!

[Paul Hoffman / IMC]

At 12:47 PM -0500 12/17/03, John Stracke wrote:
Paul Hoffman / IMC wrote:

At 9:55 AM -0500 12/17/03, John Stracke wrote:

Modifying the Subject: line is a Bad Thing; it invalidates digital 
signatures.
Which digital signatures are you talking about? Neither S/MIME nor 
OpenPGP sign the headers in messages, only the bodies.
S/MIME can sign the Subject: header (see RFC-1848, section 6.3)
RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant 
implementation.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Tag, You're It!

[Paul Hoffman / IMC]

At 9:55 AM -0500 12/17/03, John Stracke wrote:
Modifying the Subject: line is a Bad Thing; it invalidates digital signatures.
Which digital signatures are you talking about? Neither S/MIME nor 
OpenPGP sign the headers in messages, only the bodies.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PKIs and trust

[Paul Hoffman / IMC]

At 4:29 PM -0500 12/14/03, [EMAIL PROTECTED] wrote:
On Sun, 14 Dec 2003 12:09:37 PST, Paul Hoffman / IMC said:

 All of that is describable, and many vendors have such products.
 There are no standards (or none that are significantly followed) for
 such assertions. So? Many different PKIs can handle such assertions,
 once you codify them.
I'm having a very hard time as reading this as anything except "Sure, the
PKI's out there could do it, if we only understood it well enough to come
up with a consistent way that would work for everybody.  And since the PKI
could deal with it if we knew what we wanted it to deal with, it's not a
problem for actual production use of a PKI now".
Try harder then. Maybe try "The PKI works fine for this, as does the 
signed messages, and we understand what we want, but we can't figure 
out how to trust the other humans in the process." You can't find "a 
consistent way that would would for everybody" if they can't define 
why and how they trust each other.

There are literally billions of dollars that can be saved if someone 
can figure out how to get the human trust part to work. Given that 
the technical end of the PKI world has not changed much in the past 
five years, it's pretty clear that if someone is leaving billions of 
dollars on the table, the problem is pretty difficult and not prone 
to a technical fix.

This has nearly nothing to do with the technical part of the PKI, and 
everything to do with the humans.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PKIs and trust

[Paul Hoffman / IMC]

At 2:52 PM -0500 12/14/03, [EMAIL PROTECTED] wrote:
On Sun, 14 Dec 2003 11:33:23 PST, Paul Hoffman / IMC said:
 At 2:14 PM -0500 12/14/03, Keith Moore wrote:
I trust my boss to make statements about my job.
 All of those statements, assertions, and so on can be made in simple
 signed messages. When you get a message with statements about your
 job, you verify that the message has been signed using your boss'
 public key. What's the problem here?
Please explain how you enforce that the signed part of the message *only*
contains statements about his job, and does not make any claims that 
he doesn't
trust his boss to make, but does trust his landlord to make?
As the person trusting something, I don't have to "enforce" anything: 
I look at it and make a trust judgement.

If you are assuming that this trust has to be made automatic, then 
you first need to scope the kind of statements that can be made. You 
then describe that scope in the boss' certificate.

Note that this isn't a hypothetical.  This message is signed, and it 
quotes you
quoting Keith.  Or at least it claims to.  Now what does the 
signature tell you
about the words that Keith is attributed with?  Absolutely nothing - 
you get to
rely on your judgment of how careful I am with attributing quotes.
Exactly right. I don't trust you to quote Keith or me. So?

At our site, we have multiple people who are authorized to sign 
purchase orders.
Explain a "simple signed message" format that explains to the vendor that the
digitally signed PO from Mary Smith for desktop computers is OK, because Mary
is authorized to buy those for us, and the PO from Richard James for concrete
for construction project #11934 is OK - but Richard isn't allowed to 
buy desktop
computers or concrete for other projects.
All of that is describable, and many vendors have such products. 
There are no standards (or none that are significantly followed) for 
such assertions. So? Many different PKIs can handle such assertions, 
once you codify them.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PKIs and trust

[Paul Hoffman / IMC]

At 2:48 PM -0500 12/14/03, Keith Moore wrote:
All of those statements, assertions, and so on can be made in 
simple signed messages. When you get a message with statements 
about your job, you verify that the message has been signed using 
your boss' public key. What's the problem here?
Some of the problems occur when I start trusting software to tell me 
whether to believe in the identity, authority, or role claimed by 
someone I don't know personally.  It gets worse if I start trusting 
software to make decisions based on the things that people I don't 
know personally tell me.
You're talking about a problem with software, not with the standards.

You started this thread with:

At 12:12 PM -0500 12/14/03, Keith Moore wrote:
Until PKIs are able to represent the rich diversity of trust 
relationships that exist in the real world, they are mere 
curiosities with marginal practical value.
PKIs are able to represent the blah blah blah; your software isn't 
yet translating that into something that you want to use.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PKIs and trust

[Paul Hoffman / IMC]

At 2:14 PM -0500 12/14/03, Keith Moore wrote:
I'd put this a different way.  Until PKIs are able to represent 
the rich diversity of trust relationships that exist in the real 
world, they are mere curiosities with marginal practical value.
Oh, please. Describe a trust relationship that cannot be 
represented using current PKI technology (PKIX certs, S/MIME signed 
messages, OpenPGP certs, OpenPGP signed messages, or SPKI certs).
I trust my boss to make statements about my job.
I trust my landlord to make statements about the house I rent from him.
I trust my mother and my siblings to make statements about my 
immediate family.
I trust my mother and my siblings to make statements about the 
identities of other family members.
I trust the State of Tennessee to make statements about the 
identities of state agencies.
I trust state agencies to make statements about which they have 
authority: (e.g. automobile licensing) but not to make statements 
about things that are outside of their purview.
I trust the United States government to make statements about the 
identifies of US government agencies.
I trust US government agencies to make statements about which the 
agency has authority: (e.g. aircraft licensing, federal income tax) 
but not to make statements about things which are outside of their 
purview.
I trust my employer to make assertions about the identities of its 
officers and/or other employees, for the purpose of establishing 
identity for work-related communications, but not for other purposes.

Now if you can show me a tool that will translate statements like 
the above (or other statements that ordinary humans can understand) 
into data structures that existing PKI-based tools will interpret 
reliably and correctly, I'll be extremely impressed.
All of those statements, assertions, and so on can be made in simple 
signed messages. When you get a message with statements about your 
job, you verify that the message has been signed using your boss' 
public key. What's the problem here?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PKIs and trust

[Paul Hoffman / IMC]

At 12:12 PM -0500 12/14/03, Keith Moore wrote:
To further your point, an area completely outside of ICANN's purview, yet an
area requiring governance is PKI. We are at the point where deployment of a
PKI has moved beyond technical issues, becoming almost completely the policy
& politics of "trust". Until the politicians broker the trust relationships,
there is nothing technology can do.
since when are politicians trustworthy enough to broker trust relationships?

I'd put this a different way.  Until PKIs are able to represent the 
rich diversity of trust relationships that exist in the real world, 
they are mere curiosities with marginal practical value.
Oh, please. Describe a trust relationship that cannot be represented 
using current PKI technology (PKIX certs, S/MIME signed messages, 
OpenPGP certs, OpenPGP signed messages, or SPKI certs). The lack of 
ability to represent the trust relationship is not what is stopping 
the PKIs.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: ITU takes over?

[Paul Hoffman / IMC]

At 8:39 AM -0800 12/12/03, Tony Hain wrote:
vinton g. cerf wrote:
 ...
 Unfortunately, the discussion has tended to center on ICANN as the only
 really visible example of an organization attempting to develop policy
 (which is being treated as synonymous with "governance"
To further your point, an area completely outside of ICANN's purview, yet an
area requiring governance is PKI. We are at the point where deployment of a
PKI has moved beyond technical issues, becoming almost completely the policy
& politics of "trust". Until the politicians broker the trust relationships,
there is nothing technology can do.
s/politicians/politicians and business community/

Absolutely agree with this sentiment. Anyone who starts an anti-spam 
proposal with "All we need to do is digitally sign the {messages|SMTP 
transmissions}..." is completely unclear on how little governance 
there is in this area.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: just a brief note about anycast

[Paul Hoffman / IMC]

At 3:30 PM +1200 12/9/03, Franck Martin wrote:
And one important fact, is that IETF issues standards which do not 
contain patents... but ITU does!
It depends on what you mean by "do not contain patents". If you mean 
"that are not covered by any patents", then tropical living has 
really affected your view of IETF reality. Reading 
 will possibly drag you back to where 
the rest of the folks on this mailing list reside.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: How to submit a draft

[Paul Hoffman / IMC]

At 4:21 AM -0800 11/21/03, Dinesh Kumar wrote:
  Could someone tell the procedure for submitting a
draft to IETF.
See "The Tao of the IETF" at .

--Paul Hoffman, Director
--Internet Mail Consortium

Re: i18n name badges

[Paul Hoffman / IMC]

There are going to be *at least* three desirable encodings of a person's
identity -- the 'natural' encoding in the preferred/native charset of the
person's name, some kind of phonetic-ASCII encoding that tells non-natives
how to pronounce the name, and the email/idna encoding[s] that folks would
use to exchange mail.
Folks: it has *not* been decided that there will be a different 
encoding for email. One such encoding has been proposed; other 
proposals have been made. This is being actively discussed, and there 
should be no assumption that the discussion will end with a new 
encoding.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Plans for IETF - 60

[Paul Hoffman / IMC]

At 10:41 AM -0500 11/19/03, Brett Thorson wrote:
I am hoping to get this done in time for IETF 59, but with current workload
here at the IETF, I am going to aim for 60.
Something else to add to the list: make software available for 
popular OS's that help the NOC team document the problems. For 
example, it would be grand if I could tell you which MAC just 
hijacked my network connection and turned it into a peer-to-peer 
connection. The software should be available for Win2K and later, as 
well as OS X. I suspect that the software is already available for 
Linux and BSD; all you need is instructions on which commands to use 
to get the data that is valuable to the NOC.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: IETF58 - Network Status

[Paul Hoffman / IMC]

Sitting in the Thursday plenary, I note none of the network-to-ad-hoc 
flappage that have been plaguing us the past few days.

Did the attackers get bored and go home?

Did the accidental ad-hocers finally get their settings right?

Did someone deploy a good blocking mechanism?

--Paul Hoffman, Director
--Internet Mail Consortium

Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA))

[Paul Hoffman / IMC]

At 11:54 AM -0500 10/28/03, [EMAIL PROTECTED] wrote:
The BOF description lists [EMAIL PROTECTED] as the
discussion list, but this discussion is being
cc:ed to [EMAIL PROTECTED]  I'd suggest that you
move this discussion to whichever of those lists
is actually correct.
It is [EMAIL PROTECTED], although because Patrik sent out the wrong 
address, I have made sure that both addresses work. An archive of the 
list, and links to the current versions of the drafts, can be found 
at .

No more messages to all lists: that's what the IMAA list is for.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: How to bulid a new group?

[Paul Hoffman / IMC]

At 11:07 AM +0800 10/3/03, wang liang wrote:
 If I find there is no a group for some important issues about Internet, and
It may be  necessary  to build a new one,what should I do?Who will deal with
this kind of suggestion?Where can I find the detailed  process of  asking
for a new work group?thanks.
See  for probably everything you need 
to get started.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]

[Paul Hoffman / IMC]

At 2:14 PM +0200 9/18/03, Francis Dupont wrote:
=> IMHO it should reject SMTP connection from the beginning with
the 521 greeting described in RFC 1846...
People are unhappy about VeriSign breaking the rules. But here you 
are proposing that they follow an *experimental* RFC whose rules were 
not accepted into the later revision of SMTP in RFC 2821. How will 
them breaking the rules twice make it better?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: A modest proposal - allow the ID repository to hold xml

[Paul Hoffman / IMC]

At 10:47 AM -0700 9/2/03, Eliot Lear wrote:
I don't know about about you, Paul, but I'm writing my drafts using 
EMACS and Marshall's tool.  That allows for generation of HTML, 
NROFF, and text.  The HTML allows for hyperlinks, which is REALLY 
nice.
Great! Why does that mean that the XML input should be published in 
the Internet Drafts directory along with the text output?

--Paul Hoffman, Director
--Internet Mail Consortium

RE: A modest proposal - allow the ID repository to hold xml

[Paul Hoffman / IMC]

At 1:22 PM -0400 9/2/03, Rosen, Brian wrote:
I think there are quite a few reasons.  Mine are:
1) Ability to render in alternate ways to improve
readability and accessibility
Please be more specific on "accessibility". Which groups of people 
are currently excluded, or would be much more included with XML 
documents?

2) Ability to cross reference documents
That benefit only appears if all, or a significant proportion, of the 
Internet Drafts are in XML or a similar format. That's not what you 
proposed.

3) More uniformity in, e.g. references
In what way is that helpful? Are there kinds of references commonly 
used now that don't work well?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: A modest proposal - allow the ID repository to hold xml

[Paul Hoffman / IMC]

At 6:15 PM -0400 8/27/03, Rosen, Brian wrote:
I therefore have a modest proposal:

Allow the submission of an xml file meeting the requirements of RFC2629
along with the text file (and optional ps file) for an Internet Draft.
You didn't say what the additional value would be. We know the 
additional value of a .ps file (drawings that don't translate to 
ASCII art). What is the value of XML? It certainly isn't 
searchability or readability.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / IMC]

At 10:26 PM -0700 6/21/03, Alex Zinin wrote:
Folks-

 Having watched this discussion, it seems a couple of data points
 might be helpful:
 1. L2VPN and L3VPN proposed WGs are part of PPVPN WG split

Creation of L2VPN and L3VPN WG does not represent addition of new
work to the IETF. They are created as part of the process of
splitting the PPVPN WG to improve progress and focus it by setting
clear directions in the charters.
 2. L2VPN work is already chartered within the IETF

The discussion about whether this work should be chartered or not
happened when the PPVPN WG was being created. Please see minutes
and slides from the PPVPN BOF at IETF 49. L2VPN solutions are
within the PPVPN charter and milestones.
 Hope this helps.
My comments about possibly moving this work to a different standards 
body is based on our track record with this work so far in the IETF, 
not a worry about new work.

Just because we chartered some work doesn't mean we shouldn't revisit 
the question of whether or not doing so was a good idea, particularly 
after we see the kind of progress that has been made and the problems 
that have come up under those charters.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / IMC]

At 6:43 PM -0700 6/18/03, Vach Kompella wrote:
 > I'm not sure how to argue with the statement "the IETF has done a
 horrible job with a similar working group, so we want our working
 group in the IETF".
Well, how about, we can't agree on IPv6 numbering schemes, so let's 
find another
standards org to fix that problem. We can't decide whether site-local is good
for IPv6 or not, so let's find another standards org.
IPv6 is an IP technology. We are supposed to know how to make it 
work. L2VPNs (and half of the interesting parts of 2547bis L2VPNs) 
are outside the scope of our expertise.

 ...  What kind of
unmitigated disaster would IKE have been if we had just punted it 
over to, say,
the ITU?
Worse, no doubt. But I'm not proposing to send the L2VPN work to an 
organization with no expertise or credibility in the L2 area.

Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if we
want a solution, we will create one here.
If we decide that "the problem" is one in our realm, I fully agree. 
But transporting layer 2 stuff over IP is not a problem that affects 
the Internet. It is a problem for the service providers marketing 
departments. The past three yeas have proven that service providers 
can satisfy their customers needs with L3VPNs, with 
somewhat-interoperable L2VPNs, with non-interoperable L2VPNs, and 
with just plain layer 2 circuits. What is "the problem" that the IETF 
needs to standardize?

  E.g., I'm happier having IPSec than
no security.
Of course. But we'd both be happier if IPsec worked better as a VPN 
technology, and applications folks would be happier if it worked 
better as an application security technology.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / IMC]

At 1:31 PM -0700 6/18/03, Vach Kompella wrote:
 > - the IETF's track record for this work so far is quite poor

That's not a problem of the ppvpn group only.  It is a problem of the IETF.
Generally agree.

I don't need to refresh your memory about IPSec, do I?  SKIP, Skeme, Oakley,
IKE.  AH or ESP with auth?  5 years of bloody fighting.
I'm not sure how to argue with the statement "the IETF has done a 
horrible job with a similar working group, so we want our working 
group in the IETF".

First off, I agree with you about the IPsec WG, and think it is a 
very good indicator of what the IETF does poorly, particularly in the 
area of focus. (Hint: look at the number of WG Internet Drafts there 
are right now in IPsec that no one is working on.) The problems in 
the IPsec WG and others are typical of the problems of the WGs that 
are working on trusted VPN technologies.

It's wherever the action is that the political jostling for position 
is the most
prominent.  That's also where the leadership needs to be strong and 
participants
need to have a "nose to the grindstone" attitude.  That's hardly an indication
that the work should not be chartered or worked upon.
Er, yes it is. There is no indication that we will do a better job 
than the terrible job we are doing now. What you propose sounds like 
"we're terrible parents for our six children and barely have enough 
time to pay attention to them, but maybe we'll be better with the 
seventh."

 > We have not shown any ability to create standards in this area with
 due speed or predictability. We have not shown the good judgement
 needed to limit the scope of the work we do. (Look at the number of
 L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the
 large number of non-WG documents being actively discussed.
Do you think the new L2VPN charter addresses these concerns of scoping?  How
about the timelines?  Basically, it's going to be a WG issue, chairs and
participants, to finish the WG charter items first.
Why do you think that the re-chartered WG will have any more luck 
with these than the current one? There are a zillion hardware vendors 
and service providers who have reasons to want the dozens of 
documents that are in the current WGs, and it takes very little 
effort on their part to promote their views. The IETF structure does 
poorly in such an environment; maybe a different standards body would 
do better.

 > The IETF understands the need for layer 2 technologies for OAM much
 better than we understand the Internet customer's need (or even
 concern) for layer 2 transport of their IP packets. This is because
 we have a tighter relationship with operators than we do with
 Internet users, and because Internet users generally could care less
 about how their ISPs move their traffic as long as they meet the
 service level agreements. The ISPs would love to have better
 cross-vendor interop for the L2VPN technologies, but so far the
 vendors haven't had time to think about that because they have been
 overloaded with the literally dozens of flavors that are being
 discussed in the IETF.
Are you talking PWE3 or L2VPN?
Yes. There is a significant amount of spillage between the two.

The gazillion drafts is in PWE3.  The interop issues are localized 
to the drafts
with contention, silly issues of where bits should go.

There are 16 pseudowire types:
   0x0001   Frame Relay DLCI
   0x0002   ATM AAL5 SDU VCC transport
   0x0003   ATM transparent cell transport
   0x0004   Ethernet Tagged Mode
   0x0005   Ethernet
   0x0006   HDLC
   0x0007   PPP
   0x0008   SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8]
   0x0009   ATM n-to-one VCC cell transport
   0x000A   ATM n-to-one VPC cell transport
   0x000B   IP Layer2 Transport
   0x000C   ATM one-to-one VCC Cell Mode
   0x000D   ATM one-to-one VPC Cell Mode
   0x000E   ATM AAL5 PDU VCC transport
   0x000F   Frame-Relay Port mode
   0x0010   SONET/SDH Circuit Emulation over Packet (CEP)
At least half of these are and have been interoperable.  It is the harder (and
more arcane, IMHO) PW types that people are having a hard time coming to some
sort of compromise.
And why should the IETF care at all about these? There are other fora 
for layer-2 interworking.

BTW, I'm glad to see you have a healthier respect for providers than 
Kurtis who
claims that "most of these providers have bought what their vendor 
told them to
buy."
He and I might both be right. In my talks with service providers, I 
find that many of them who want to expand their presence in, or just 
get into, the "IP VPN" market look at what hardware they have on hand 
in their core (they certainly can't buy any significant new hardware 
these days) and base their decision on the layer-2 technologies on 
that. Usually, the customers don't know or care. If the customers 
care, they only care enough to ask "are you 

Re: CLOSE ASRG NOW IT HAS FAILED

[Paul Hoffman / IMC]

At 11:27 AM -0600 6/16/03, Vernon Schryver wrote:
All contributions that are rejected
by any moderators (including spam filters) of any IRTF or IETF mailing
lists must be archived and should be published on web pages somewhere.
FWIW, some of the IETF WG mailing lists that IMC runs get >10 spams a 
day, and often get the virus/trojans that are >120K each. This is not 
an insignificant amount of junk to wade through when looking for 
proof of moderator badness/goodness.

And there's also the problem of robots that harvest everything, 
regardless of your robots.txt file. If we had a system like you 
describe, it would be believable that the archives would get a fair 
number of hits from people searching for pr0n but finding our archive 
of spam instead.

I think that having all bounces (for whatever reason) archived is 
fine; I think having it as "web pages somewhere" is overkill. Access 
to one of the big text archives can be a trivial password given to 
anyone who wants it for research purposes.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 4:12 PM -0700 5/30/03, Dave Crocker wrote:
Perhaps you could synthesize the numbers in a way that the carriers will
agree to?   That it, sanitize out the competitive information, to
produce something relevant only to spam control in the aggregate.
The numbers are a few years old, anecdotal (although at least they 
came from people inside the companies!), and not computed in the saw 
way. For instance, BigISP1 counted the time spent on customer service 
on spam-related topics plus sysop time plus connectivity costs, while 
BigISP2 only counted the latter two.

But, to be more relevant, let me say that all of the numbers were in 
millions of dollars.

To bludgeon the point a bit:

- Big ISPs and other mail service providers know how much spam is costing them.

- For some ISPs, the amount is in the millions of dollars.

- Even an expensive team of consultants could devise a trust-based or 
work-based protocol and shepherd it through the IETF for less than 
one tenth the annual cost for a single ISP.

Given the above, the reason that the people who are most financially 
hurt by the spam problem have not done anything about it from a 
protocol level is either that they are financially stupid or that 
their research into the solutions didn't result in a solution that 
would cost them more. I believe it is the latter. People outside 
those companies might have different opinions, but to say "if we 
invent a protocol that we think will work, they will use it" is 
nonsense.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 11:09 AM -0700 5/30/03, Tony Hain wrote:
Paul Hoffman wrote:
 So far on this thread, we have heard from none of the "large-scale
 mail carriers", although we have heard that the spam problem is
 costing them millions of dollars a year. That should be a clue to the
 IETF list. If there is a problem that is affecting a company to the
 tune of millions of dollars a year, and that company thinks that the
 problem could be solved, they would spend that much money to solve
 it. Please note that they aren't.
And that would be because they can't do it in isolation. They need a
system wide standard everyone is building to, to make your argument
below about cost of untrusted mail moot.
And you believe that these companies are so stupid that when they 
have a problem that is costing them tens of millions of dollars a 
year, they wouldn't think of coming together for a solution? Maybe I 
have a higher opinion of them than you do because they were members 
of my consortium.

All of these companies have people following (and often 
participating) in the IETF. To assume otherwise without first asking 
them is pretty silly.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 10:40 AM -0700 5/30/03, Peter Deutsch wrote:
Paul Hoffman / IMC wrote:
...
 So far on this thread, we have heard from none of the "large-scale
 mail carriers", although we have heard that the spam problem is
 costing them millions of dollars a year. That should be a clue to the
 IETF list. If there is a problem that is affecting a company to the
 tune of millions of dollars a year, and that company thinks that the
 problem could be solved, they would spend that much money to solve
 it. Please note that they aren't.
Well, perhaps it's more accurate to say "if they thought it could be
solved by working with all those nice and entusiastic folks on the IETF
general discussion list"... ;-)
We disagree here. For the millions of dollars that they are losing, 
they would come up with the solution with the IETF or not. They 
haven't.

 > I have spoken to some of these heavily-affected companies (instead of
 just hypothesizing about them). Their answers were all the same: they
 don't believe the problem is solvable for the amount of money that
 they are losing. They would love to solve the spam problem: not only
 would doing so save them money, it would get them new income. Some
 estimate this potential income to be hundreds of millions of dollars
 a year, much more than they are losing on spam. But they believe that
 the overhead of the needed trust system, and the cost of losing mail
 that didn't go through the trust system, is simply too high.
 You might disagree with them, and based on that disagreement you
 might write a protocol. But don't do so saying "the big carriers will
 want this" without much more concrete evidence as to their desires.
Paul, are you aware of any concrete numbers here?
Yes.

 I've looked through
the IMC site, but the only references to cost seem to be in a report
from the late 90's, with no hard data. If not, this might be something
the IMC could consider pulling together? I'd agree that there's way too
much hand-waving going on here on this point...
All my discussions were not for attribution. Large mail carriers 
don't want their competitors to know how many users they actually 
have (as compared to the highly inflated numbers that various 
analysts say they have), and they certainly don't want their 
competitors knowing how much they are spending on dealing with spam. 
"Our company spends more per user on fighting spam than 
OtherBigCarrier!"

In aggregate, then numbers were in the tens of millions of dollars 
US, and that was more than two years ago. I would be shocked if the 
numbers were much lower now, given the greatly increasing amount of 
spam and the level-or-increasing number of customers.

Again, the summary is that these folks are hurting badly enough to 
throw highly-qualified full-time staff on the problem, and they don't 
believe any of the solutions that have been presented so far will 
save them enough money. If they thought differently, they would have 
deployed them by now so that they could save those millions of 
dollars.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 11:36 PM -0700 5/29/03, Dave Crocker wrote:
The POP->IMAP example is excellent, since it really demonstrates my
point. IMAP is rather popular in some local area network environments.
However it's long history has failed utterly to seriously displace POP
on a global scale.
Exactly right. The benefits of IMAP are obvious to everyone who has 
looked at it in any depth, and yet it is very thinly deployed. The 
main reason: the perceived additional administrative overhead.

EAH> Large-scale mail carriers would probably switch quickly if
EAH> the accountability feature proved useful,
and now we are back to hypothesizing about the behaviors of
mega-corporations with massive installed bases and a rather poor history
of adopting changes from the IETF community.
So far on this thread, we have heard from none of the "large-scale 
mail carriers", although we have heard that the spam problem is 
costing them millions of dollars a year. That should be a clue to the 
IETF list. If there is a problem that is affecting a company to the 
tune of millions of dollars a year, and that company thinks that the 
problem could be solved, they would spend that much money to solve 
it. Please note that they aren't.

I have spoken to some of these heavily-affected companies (instead of 
just hypothesizing about them). Their answers were all the same: they 
don't believe the problem is solvable for the amount of money that 
they are losing. They would love to solve the spam problem: not only 
would doing so save them money, it would get them new income. Some 
estimate this potential income to be hundreds of millions of dollars 
a year, much more than they are losing on spam. But they believe that 
the overhead of the needed trust system, and the cost of losing mail 
that didn't go through the trust system, is simply too high.

You might disagree with them, and based on that disagreement you 
might write a protocol. But don't do so saying "the big carriers will 
want this" without much more concrete evidence as to their desires.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 4:58 PM -0700 5/29/03, Tony Hain wrote:
The sysadmin effort would be setting up an automated way to hand out
keys, and the user would have a one-time (or very infrequently) effort
to establish a key pair.
And you are saying that is trivial? How would a typical user know 
which third parties to trust? How would the typical user know what to 
do when they started getting spam through this filter? How would the 
typical user know what to do when someone wants to send him/her mail 
but can't because the sender isn't in the right trust group?

If you have already worked this out and I missed it, my apologies. A 
pointer to that document would be very helpful.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: The utilitiy of IP is at stake here

[Paul Hoffman / IMC]

At 2:22 PM -0700 5/29/03, Eliot Lear wrote:
Please indicate some historical basis for moving an installed base of
users on this kind of scale and for this kind of reason.
History is replete with examples.  From the Internet Worm to Code 
Red, consumers do install software when they perceive either a 
threat or a benefit.
Tony's proposal is not for new software: it is for software that 
*replaces* what they have now. Further, it is not a one-to-one 
replacement. It requires new administrative actions by the sysadmin 
and by the user to validate who they want to get mail from.

  Getting rid of spam is a HUGE benefit.
And all the proposals so far have some amount of cost. The trick is 
to come up with a solution whose benefit to at least half of the 100 
million mail users overwhelms the cost. That is, the bother of using 
the new system has to be less than the bother of getting spam.

  Heck.  What I've found so amusing is that people seem to upgrade 
their Microsoft systems just 'cause, with no perceived benefit, but 
merely protecting from Bit Rot.
This is because (despite history) people believe that the replacement 
will be no harder to user than the previous version.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: spam

[Paul Hoffman / IMC]

At 11:36 AM -0700 5/28/03, Tony Hain wrote:
The external mechanisms already exist to deal with the
social engineering once the originator can be pinned down.
This is good to hear. I thought that the international trusted 
micropayments that would be needed for such a sender-pays system was 
a problem that was yet to be solved.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: [Sip] Eating our own Dog Food...could the IAB and IESG useSIP for conference calls

[Paul Hoffman / IMC]

A modest request: could all the people who think that this is a good 
place to advertise their company's products and services please 
reconsider? If you really want to offer your services, send a message 
to the original proposer, not the whole mailing list. Advertising 
here is really, really tacky.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Barrel-bottom scraping

[Paul Hoffman / IMC]

At 12:05 AM +0200 3/24/03, Pekka Savola wrote:
I fail to see what added value they might bring
They could be very useful to explaining to our management and 
marketing departments and so on the value of standards, particularly 
IETF standards. Further, because most companies focus on a small part 
of the Internet, they could show why the whole picture is important.

And I agree that they should not be held next to IETF meetings. Maybe 
once a year between meetings, or in conjunction with other 
"networking events" that these people might go to, such as N+I or 
Comnet.

--Paul Hoffman, Director
--Internet Mail Consortium

Can we move this discussion to a more appropriate place? (was:Re: IAB policy on anti-spam mechanisms?)

[Paul Hoffman / IMC]

This thread is trying to redefine or redesign SMTP's use of TLS. It 
should probably be happening on the [EMAIL PROTECTED] list 
instead of the main IETF mailing list. That's where the implementers 
are, and that's where the implementers of most of the foo-over-TLS 
protocols are. They too should be hearing this discussion, since much 
of it applies to many protocols, not just SMTP.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: IAB policy on anti-spam mechanisms?

[Paul Hoffman / IMC]

At 5:34 PM -0800 2/27/03, [EMAIL PROTECTED] wrote:
Your question assumes that the DUL is actually a meaningful anti-spam
mechanism. It is not.
Could you elaborate a bit on what you mean by "meaningful"? As 
someone who uses the DUL list as an anti-spam mechanism and who 
experiments with turning it off and on, I can definitely say that 
turning it on reduces the amount of spam I receive (on the order of 
about 100 messages a day).

I recognize that it also harms folks like you for many of the reasons 
you give. But I don't understand why you say it is not a meaningful 
anti-spam mechanism.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: a personal opinion on what to do about the sub-ip area

[Paul Hoffman / IMC]

At 4:50 PM -0800 12/9/02, Tony Hain wrote:

If there were are real need for cross group
coordination within the sub-IP area, that would be a little clearer.


A presentation at the SubIP Area meeting in Atlanta drove home the 
point that the amount of coordination in the area was not as high as 
expected when the area started. The originally-envisioned hourglass 
(with CCAMP in the middle) turned into spaghetti. This is not to say 
that the spaghetti is bad, just that the proposed coordination didn't 
help keep them on track and therefore might be less needed than some 
are saying.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: IETF Sub-IP area: request for input

[Paul Hoffman / IMC]

A few more issues for this discussion:

- The statement that some of the WGs in the SubIP area are about to 
finish up may be deceptive. Some of the WGs are accepting new 
proposals on wide-ranging topics. Some of the proposals that are 
within the charters are bogged down in personal/political hassles 
that are only apparent in the hallways, not on the mailing lists. In 
other words, they are similar to many WGs in other areas of the IETF.

- So far, every message has miscounted the number of WGs in the area 
by one. PWE3, even though it is in Transport, is very clearly a SubIP 
WG. I have yet to speak to anyone who could clearly say why PWE3 is 
not part of SubIP (the fact that it "affects" transport is silly: all 
SubIP technologies will affect transport). And it is nowhere near 
finishing.

- There are other WGs that are not in SubIP but have many of the 
characteristics that people in this thread have been talking about. 
There is a real question about why is the IETf working on IPoverFoo 
for any given Foo. The charters for IPCDN and IPOIB and IPORPR 
indicate that they are covering layer 2 technologies carrying IP. If 
IPO is part of SubIP, these should be as well.

- The "wait for some of the WGs to wind down before acting" 
suggestions are based on the theory that the WGs will wind down. It 
is odd to hear that from people with lots of IETF experience.


The SubIP area experiment should be terminated because it didn't 
reach any appreciable results in the allotted time. Further, the IESG 
should decide for all of the WGs currently in what is really SubIP 
(that is: ccamp, gsmp, ipcdn, ipo, ipoib, iporpr, mpls, ppvpn, pwe3, 
tewg), which area is actually appropriate for each WG. It's likely 
that the answer will be "well, it doesn't really fit anywhere 
sensibly in the current IETF area structure".

That's a pretty significant answer. Fortunately, there is a solution, 
which is to disband the WGs and let the industry trade associations 
that are dealing with the topics take over the work. The MPLS Forum 
is an obvious place for the MPLS-related work. ipo could go to the 
Optical Internetworking Forum, iorpr can go to the Resilient Packet 
Ring Alliance, and so on. These are organizations that have funded 
secretariats, existing technical committees, and so on.

Keeping these WGs in the IETF has a real cost, namely on the time of 
the IESG and the IETF Secretariat. It is probably better to let 
groups whose primary focus is the named technology do the work.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: mail headers for announce

[Paul Hoffman / IMC]

 Or the IETF could simply start using its own Proposed Standard 
mechanism described in RFC 2919.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Global PKI on DNS?

[Paul Hoffman / IMC]

At 7:44 PM +0200 6/12/02, Jakob Schlyter wrote:
>could we perhaps move this discussion to [EMAIL PROTECTED]?

Yes we could, but whether or not people want to is another question.

As for the people who have made comments about "it would be nice to 
be able to discover paths to trusted roots", please be advised that 
the PKIX WG is working on this. In fact, it has been the 
most-discussed topic in the WG lately. Yes, it has been discussed 
there for a few years, but it appears that in the fine IETF 
tradition, convergence through attrition is happening.

--Paul Hoffman, Director
--Internet Mail Consortium

[idn] Re: CDNC Final Comments on Last call of IDN drafts

[Paul Hoffman / IMC]

At 12:52 PM +0200 6/6/02, Simon Josefsson wrote:
>This means IDN is not guaranteed to be secure on non-Unicode systems.
>There are alot of non-Unicode systems out there today...

Nothing is ever guaranteed to be secure. Even if we supplied mapping 
tables, there is no guarantee that the mapping tables we supplied 
would match those already in use in those systems, so there will be 
the same security issues. In fact, we can be sure that some 
"standardized" mapping tables would disagree with those already 
implemented.

>  > When standards bodies for character sets define such equivalences, and
>>  when those equivalences gain popularity, it might be appropriate for
>>  the IDN effort to consider incorporating these new standards.
>
>This isn't an adequate solution IMHO, when the consequences of errors
>made by such standard bodies, or conflicts between different standard
>bodies, or different interpretations of said standards, or changes
>between different versions of those standards, or simply a complete
>lack of standardisation in the area (which is the situation today),
>may be exploitable for attacking systems on the Internet.

And your proposal for an adequate solution is? Short of forcing 
every current system to use a single set of standardized mapping 
table (which is patently unrealistic), how could you ever avoid such 
an exploit?

Further, the exploit you descirbe is identical in every application 
that allows an encoding of the Unicode character set (such as UTF-8). 
Are you saying that we shouldn't allow any input in UTF-8 in any 
application until there is both a standard set of mapping tables and 
absolute conformance to them?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: [idn] WG last call summary

[Paul Hoffman / IMC]

At 3:58 AM + 3/11/02, D. J. Bernstein wrote:
>You say that you are obliged to ignore all these objections because the
>IDN WG has to _do something_.

You are lying again, Dan. Marc never said that, and you know it.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: RFC2119 Keywords

[Paul Hoffman / IMC]

At 8:15 AM -0500 2/15/02, Scott Brim wrote:
>In normative text, I don't see how "must" could occur anywhere except
>where it was supposed to mean "MUST".

It occurs when describing how something happened, not what needs to 
happen. Example from a current Internet Draft that is having the 
capitalization fixed:

...not less than 3, but 4 is less than 5, so 4 must be the last digit.
->
...not less than 3, but 4 is less than 5, so 4 has to be the last digit.

There were a few places where the "must" turned into a "MUST" as a 
way of specifying how an implementation of the protocol had to work.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: REMINDER: revision to RFC2727 - NOMCOM

[Paul Hoffman / IMC]

At 8:50 AM -0800 1/25/02, Dave Crocker wrote:
>At 10:34 AM 1/25/2002 -0500, James M Galvin wrote:
>>I just wanted to call your attention to the recently announced proposed
>>revision:
>
>Perhaps the best time for pursuing revisions to this document is 
>immediately after the nomcom has done it job.  That way you will 
>have a pool of very fresh suggestions to work from.
>
>(and this suggestion is coming from someone on the current nomcom 
>who is explicitly offering to participate on that basis, but also 
>feels that it would not be appropriate to participate in the middle 
>of the major nomcom deliberations.)

As someone who was on a previous nomcom, I fully agree with Dave. It 
would have been silly to think about this while in the midst of 
deliberations that could affect what I said.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: one copy sent to list but THREE returned

[Paul Hoffman / IMC]

At 5:11 PM -0500 1/6/02, Gordon Cook wrote:
>I sent but a single copy of 'empowering' to the list.  It returned 
>THREE to me.  If everyone else got 3, my apologies.  If anyone can 
>inform me as to what happened i'd appreciate it.

Er, a better question is why you spammed the IETF list at all.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Splitting the IETF-Announce list?

[Paul Hoffman / IMC]

At 4:02 PM -0600 11/13/01, Pete Resnick wrote:
>I am interested in getting all of the posts to the IETF-Announce 
>list *except* for the greatest bulk of those posts: Internet Draft 
>announcements. I find it hard to believe that I am the only one who 
>would prefer if the I-D announcements were on a separate mailing 
>list. Would it be possible to implement this? If I am correct and 
>there are an awful lot of people who are uninterested in I-D 
>announcements,

Pete, you really should get a mail client that has an easy-to-use 
filtering interface. :-)

>  it would cut down on outgoing mail of the secretariat substantially.

Ah, that might be a consideration. Unless it turns out that the 
secretariat's Internet connection bills are high, it seems worthwhile 
to keep the lists merged. To many of us, seeing the names and titles 
of new -00 drafts is as interesting as seeing RFC announcements. 
Further, waiting until a draft is in IETF Last Call before people 
notice it is not a good way to create protocols.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: participation in IETF meetings

[Paul Hoffman / IMC]

Going back to the original question about more multicast sessions:

The advantage of multicast vs. tape-and-archive is the real-time 
aspect for the viewer. However, this is rarely, rarely used. If it 
turns out that switching from multicast to tape-and-archive can get 
more camera operators in more rooms, that would be a win for more WGs.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Last Call: PIC, A Pre-IKE Credential Provisioning Protocol toProposed Standard

[Paul Hoffman / IMC]

At 3:56 PM -0400 10/11/01, Darren Dukes wrote:
>This may be  nit-picking but I have seen no mention on IPSRA, or any other
>list, or during any meetings that there are two interoperating independent
>implementations of this draft.  Is anyone able to confirm that
>implementations exist and interoperate?

Yes, it is nitpicking. This call is for PIC to go to *Proposed* 
Standard. The requirement for two interoperable implementations is 
for going to *Draft* Standard, which is the step after Proposed 
Standard. See RFC 2026 for the not-so-gory details.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: since drums is closed...

[Paul Hoffman / IMC]

At 12:00 PM -0500 5/22/01, Chip Rosenthal wrote:
>On Tue, May 22, 2001 at 05:00:49PM +0200, Maurizio Codogno wrote:
>  > I hope someone may give me an answer here, even if the topic is
>  > not quite in topic for the list.
>
>Don't have an answer to your question, but thought I'd point out
>that most of the DRUMS participants have moved over to the ietf-822
>mailing list hosted at imc.org.

The folks who want to talk about message formats have moved there. 
The folks who want to talk about message transport have moved to 
ietf-smtp. DRUMS was covering two different topics.

>IIRC [EMAIL PROTECTED] should work.

Yup, and [EMAIL PROTECTED] will get you the companion list.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Mailing list policy

[Paul Hoffman / IMC]

At 4:54 PM -0400 5/20/01, Perry E. Metzger wrote:
>When you are the maintainer of a list

That assumes that someone is the maintainer of the IETF mailing list. 
At this moment, that is not the case. You are asking that an 
additional  task be put on one of the IETF Secretariat folks. That's 
a reasonable request (and one that I would second), but it is not 
based in current reality.

>  > Quite a few IETFers have more than one email address.
>
>Which is why Majordomo lets you have a seperate list of addresses that
>can post but don't get the mail. Works beautifully.

No, it works clumsily. It requires that someone who wants to post 
from a different address than the one they are subscribed to must 
somehow register the alternate address with the list maintainer. Or 
that the list maintainer must write custom software that enhances the 
list of allowed-to-post addresses with guesses like "if there is a 
subscription for [EMAIL PROTECTED], also allow [EMAIL PROTECTED]; if 
there is a subscription for [EMAIL PROTECTED], also allow 
[EMAIL PROTECTED]". But that will still miss people who are subscribed 
from [EMAIL PROTECTED] but posting from [EMAIL PROTECTED]

(And, yes, I've written such code for the lists IMC and VPNC runs; it 
is available on request.)

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Deja Vu

[Paul Hoffman / IMC]

At 12:52 PM -0500 3/22/01, William Allen Simpson wrote:
>None of the Mac folks I've talked to have had any success with the
>wireless DHCP.  We have to hand configure.

You must run in a different circle of IETF Mac users. None of the 
many that I know (including me) had any problem.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Blast from the past

[Paul Hoffman / IMC]

At 10:30 PM -0500 1/24/01, J. Noel Chiappa wrote:
>PS: Those of you with sharp eyes will notice that everything has a class A
>address!

...and that some of those addresses still work, and appear to be used 
by folks directly related to the original owners. If only URLs could 
be so persistent...

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Again: Number of Firewall/NAT Users

[Paul Hoffman / IMC]

At 12:10 PM -0500 1/23/01, Frank Solensky wrote:
>One could ask a sample of administrators and extrapolate the results
>but, again, the problem becomes how confident you could be of the
>results if you don't get a very significant response rate

The problem is *much* worse than that. You have to be confident that 
your sampling method actually reflects enough of the Internet to be 
valid. Determining how you have reached a valid sample of 
administrators would be an interesting problem. Further, it is safe 
to assume that administrators for the largest networks are the least 
likely to reply, or to reply accurately.

And then there is the problem of assuming that they understand your 
question, and can even count the systems on their networks well 
enough to answer accurately...

--Paul Hoffman, Director
--Internet Mail Consortium

Re: internet voting -- ICANN, SmartInitiatives, etc.

[Paul Hoffman / IMC]

Ed, why do you insist on advertising your patent-pending voting 
solution on the IETF mailing list? It does not involve any IETF 
protocol work, does it?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: When presentations are a good idea (Re: IETF logistics)

[Paul Hoffman / IMC]

At 9:33 AM -0800 1/3/01, Dave Crocker wrote:
>1.  IETF meetings should not be used for transmitting "news" that is 
>relevant to the working group; use the list.

Right.

>2.  IETF meetings should not be used for introducing ideas or 
>specifications; use the list.

There are times where meetings can better for "introducing ideas" 
than the mailing lists are. If people in a WG think that the WG 
should attack a new problem, and many people have proposed solutions 
for that problem, hearing three different presentations of the 
problem and proposed solutions in a face-to-face meeting can be 
useful. On mailing lists, statements of problems that come with 
proposed solutions often devolve into confusion between the realness 
of the problem and the goodness of one of the proposed solutions. The 
IPsec WG dealt with this a few times last year with the keep-alive 
and the IPsec-through-NATs issues.

Agree on not using meetings for introducing new specs.

>3.  If there is confusion or contention about something discussed on 
>the list, THEN it is reasonable to make a presentation on the topic, 
>attempting to provide clarification and coherence and as a basis for 
>meeting discussion.

Right.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Bottom feeders

[Paul Hoffman / IMC]

At 1:54 PM -0600 12/20/00, Brian E Carpenter wrote:
>Hard  to say, but the newcomer's briefing and the Tao of the IETF are
>both on the web site.

It is important to note that the Tao is being substantially upgraded 
and has lots of new material specifically aimed at dealing with some 
of the problems discussed on this thread. Look for a revised version 
of the draft in the near future.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: IETF logistics

[Paul Hoffman / IMC]

At 9:44 AM -0800 12/20/00, Christian Huitema wrote:
>I have a simpler point about logistics. What we are doing in the IETF
>nowadays is downright dangerous. Prevalence of the laptops means that
>the room is criss-crossed with power cables. Lack of room means that the
>alleys are packed with standing or sitting listeners. If anything goes
>wrong and we have to evacuate a room, we are in for the headlines. In
>fact, if we continue breaking the fire code in every room of every
>meeting, this outcome is almost guaranteed.

"Every room"? "Every meeting"? This hyperbole is not justified. It 
happened in some of the meetings, but not others. And, in some of 
those overcrowded meetings, Steve Coya came in and made some of us 
leave so that the aisle was clear.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: IETF logistics

[Paul Hoffman / IMC]

Just to be clear, Pete's idea does not preclude giving newcomers to 
the meeting context. Instead of the 5 minutes for agenda bashing and 
then straight into presentations, the WG chair can spend 15 minutes 
saying what the group is doing, where the WG is and is not meeting 
its charter, and the status of the drafts in front of the group. At 
that point, viewers (as compared to participants) will know better 
whether or not they want to stay and will also have some idea of why 
the agenda looks like it does.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Congestion control

[Paul Hoffman / IMC]

WG chair says "OK, the room is now over-full. Who are there people in 
the doorway or outside who intend to work actively on drafts or 
forming the charter for this group? I see seven hands up. Could 
fourteen people who are currently sitting or jammed up against a wall 
who do *not* already plan to work actively on drafts or forming the 
charter for this group please be polite and leave? I will announce 
the mailing list address for this BOF on [EMAIL PROTECTED] if we get 
anywhere during this hour. Also, look for an announcement of a Bar 
BOF on the messages board later today. OK, about ten people have 
left. Thanks!"

This, of course, relies on the early sitters being polite and 
patient, but that has been known to happen at various times in IETF 
history.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Postel's razor applied to ACE

[Paul Hoffman / IMC]

One more time with feeling: please take this discussion to the IDN 
WG's mailing list. It has no place on the main IETF mailing list, and 
it needs to be discussed where the people working on the protocol are 
working.

Of course, one might want to read the WG's archive before posting to 
the list, given that many of the topics that have appeared here this 
week have already been discussed.

IDN WG info: 

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Diacritical application in the DNS

[Paul Hoffman / IMC]

At 7:06 PM -0500 12/5/00, Dan Kolis wrote:
>Now we are getting down to the nuts and bolts

No, we're not. This is a long re-hash of unfinished discussions 
happening in the IDN Working Group. As was requested earlier in this 
thread, please go read the archives of the IDN WG, and if you have 
something to say, say it there. The archives and all the drafts are 
at .

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Bake-off as trademark

[Paul Hoffman / IMC]

OK, we have now reached >20 messages from armchair lawyers on 
trademark law. Given the earlier threads this year from armchair 
lawyers on patents, that leaves us just two months for us to have a 
ponderous thread on trade secrets, and we will have covered the main 
parts of intellectual property law.

For 2001, I propose that we have at least one long thread with our 
expert opinions on international law, given that the IETF is a global 
community.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: can vpn's extended to mobility

[Paul Hoffman / IMC]

At 2:19 PM -0700 9/26/00, Dave Crocker wrote:
>At 07:56 PM 9/26/00 +0100, Lloyd Wood wrote:
>>Beg to differ. Encapsulation makes the VPN virtual.
>>Encryption ensures that the VPN is private.
>>
>>All networks are privately managed, whether virtual or not; referring
>>to that explicitly seems a bit pointless to me...
>
>
>while your explanation is entirely logical and reasonable, it does 
>not match the actual history of the term.

The "actual history" is not what is important here; what the "actual 
customers" expect is important. We are seeing more an more ISPs 
offering VPNs, some using IPsec, some not.

>the term vpn has always been independent use of encryption.

That was true up to about three years ago, but it shifted when IPsec 
became widely deployed. VPN-as-frame-relay pretty much fell out of 
the public mind. Now some ISPs are trying to resurrect the old 
"private management" definition because it is much cheaper for them 
than to offer actual privacy.

>historically there was -- and pretty much still is -- a distinction 
>between public (open) and private networks.  When the network runs 
>on top of another network, rather than using its own wires, it is 
>called virtual.  hence the composed term "virtual private".

This sounds a whole lot closer to Steve Kent's "virtually private". 
It makes sense in the old "we own the wires" world, but not in 
today's "we care about someone seeing our data" world.

--Paul Hoffman, Director
--Internet Mail Consortium

Interesting article on patents and standards

[Paul Hoffman / IMC]

A recent editorial in Microprocessor Report (a pricey but very useful 
newsletter) covers an interesting patent tussle in the RAM market. It 
is relevant to the IETF process in that the features that were 
patented were put into the standards process while the patent owner 
silently moved the patent forwards, something we have seen here. The 
editorial, titled "Ethical Standards", can be found at 
.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: rfc-editor?

[Paul Hoffman / IMC]

At 04:46 PM 4/14/00 +, Bob Braden wrote:
>There IS no dark conspiracy here, just people devoting CONSIDERABLE
>time and energy (without stock options, I might add) to making the
>internet work.

A great idea! Stock options in the RFC Editor function!

- A hot startup of about 25 years (in real time, not Internet time)

- Geekier than Slashdot

- Can change the definition of the Internet by themselves overnight

- Content is created for them by industry leaders for free

- Just look at the demographics of the people who come to their "standards 
portal"

- Imagine how much Cisco or Microsoft would spend to buy them

Re: 1601bis -03: Still Vague

[Paul Hoffman / IMC]

At 03:32 PM 3/3/00 +0800, Rahmat M. Samik-Ibrahim wrote:
>The role descriptions of section 2 remains vague. Thus, the relation
>with IANA and the RFC Editor will remain vague.

It seems quite clear to me. You might want to suggest alternative wording 
that you think is clearer.

>  No wonder, if the
>RFC Editor once has claimed:
>"The RFC Editor is chartered by the Internet Society (ISOC)
> and the Federal Network Council (FNC)"
>(http://www.faqs.org/rfcs/rfc-editor/what-is-rfc-editor.html)

That might have been true at one point, and things have changed. What's the 
problem with that?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Device upload for all platforms -- the official HTML WG position

[Paul Hoffman / IMC]

Why is this thread being run on the IETF mailing list? The IETF handed off 
responsibility for HTML to the W3C long ago. If the reason is to show 
people that someone has a beef with the way that the W3C is handling HTML, 
that point has been made.

(I can already picture certain IETF folks starting to deluge W3C mailing 
lists when IAB appeals don't go their way...)

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Question re: an Internet-Draft and testing/deployment

[Paul Hoffman / IMC]

At 10:49 AM 2/16/00 -0500, [EMAIL PROTECTED] wrote:
>Note: this protocol is quite experimental and should not be deployed in
>the Internet until it reaches standards track in the IETF.
>--- end excerpt
>
>Regarding the Note: - is there any coherent plan regarding testing/deployement
>in regards to moving this from Experimental to Standards Track?

As the draft author, let me assure you that it is far from being an 
Experimental RFC. I put these words in so that, if someone tripped across 
the draft and said "hey, let's implement this", they wouldn't think anyone 
else was. As others have said, there are a variety of IDN proposals at this 
time, and it would be downright silly for anyone to assume which, if any, 
of them will even look like the one that might be chosen down the line.

The note shouldn't be needed, given the definition of an Internet Draft, 
but it appears that many folks have forgotten that definition.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Announcement ivta.org

[Paul Hoffman / IMC]

At 12:32 PM 2/12/00 -0800, Ed Gerck wrote:
>Ross Finlayson wrote:
> > That's good, but why not undertake this within the existing IETF process,
> > rather than trying to emulate it?
>
>Because it is outside the scope of the IETF.

For once, Ed and I might be in agreement on something. The IETF has already 
done all the technical groundwork needed for the process. They've got 
OpenPGP or S/MIME for the format of the messages, TLS or IPsec for 
transmission of any unencrypted content, and PKIX for certificates. All are 
on standards track. They can give privacy and authentication.

The remaining questions might be what needs to be private or public, what 
needs to be authenticated, and who the authenticating authority is. This 
doesn't sound like a job for the IETF, although I'm sure many IETF folks 
will want to participate or at least watch. We might even pull out our 
sharpened sticks if any of the participants say things like "our 
proprietary technology which is more secure" or such things.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Paul Hoffman / IMC]

At 03:05 PM 1/4/00 -0800, Rick H Wesson wrote:
>The IETF does not need to publish broken implementations of one companies
>view of the shared gTLD registration process.

True. They don't need to do anything. They have the *option* of continuing 
the tradition of approving publication of Informational RFCs that document 
interesting (for some value of interesting) protocols that were not 
developed in the IETF but are of interest to the Internet community. In my 
mind NSI's RRP certainly qualifies. As long as the protocol does not 
directly harm the Internet on a technical level (not a political level; 
they all do that), the IESG might want to see it published.

Given the somewhat obvious nature of the protocol's faults, I would think 
that the community would welcome it being published openly and permanently; 
that way they can always refer to in while improving it.

>  Having an AD that sat on the
>RAB  promote the I-D

Sorry, but this is garbage. Nothing that Patrik said promotes the protocol.

>  and offer no reasoning as to why it
>*should be* published as an Informational RFC

He said that about three times; please re-read the past few messages with 
slightly clearer eyes.

>I would request that the IESG let this draft expire and create a WG to
>tackle the problem.

It is not clear that the IETF is the proper place to tackle this problem. 
 From the number of mistakes in the NSI RRP, I believe that a better way to 
create such a protocol is to start with a requirements document. A few 
folks have kicked around the idea of creating an IETF WG, but it became 
clear that the expertise to set down the *requirements* are more likely to 
be in the ICANN DNSO, not the IETF. That is, ask the registrars and 
registries, not a bunch of protocol-writers. After the requirements are 
settled, the IETF could probably help write the protocol.

Having those directly involved in the field set down the requirements first 
will delay the shipment of the new protocol, but it is very likely to cause 
the outcome to be much better for all involved. This has been shown again 
and again (with both positive and negative examples) in the IETF.

>The document exists as an I-D,
>the cat is out of the bag, why should it be an RFC?

To make it permanently and easily and freely accessible to the entire 
Internet community forever. There are many Informational RFCs that have 
been published for these reasons.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Paul Hoffman / IMC]

At 03:58 PM 1/4/00 -0800, Rick H Wesson wrote:
>In short you are suggesting that the I-D be published to document a
>bad but current practice?

A review of the Informational RFCs issued in the past few years would 
reveal a few RFCs that match that description quite well.

>  It seems counter-intutative but I am certainly
>not "in the know" as to how these things work.

It is a bit counter-intuitive until you look at the alternative. There 
isn't a good, central, free, open repository for these things other than 
RFCs. This isn't to say that every protocol should go there. I would say 
that only "important" (either due to politics or the number of 
implementations using the protocol) protocols should qualify.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Documents need to conclude

[Paul Hoffman / IMC]

At 05:07 AM 11/11/99 -0800, Dennis Glatting wrote:
>Therefore, I offer to you this rule to consider:
>
> Once something is committed to paper in a WG a timer
> starts. The document has 24 months (6 IETF sessions)
> to either be sent to the IESG for advancement or
> with WG consensus the Chair petitions the AD for a
> two session extension, which can be extended in the
> same manner again. Otherwise the document is
> withdrawn.
>
>I believe this rule to add something the IETF sorely needs but is
>unfair to impose: a little bit of project management. It's advantage
>is very low overhead.

It is not clear that this needs to be a "rule". It seems to me that, if an 
IETF member thinks that a WG draft has been alive too long, a letter to the 
WG chair with a Cc to the AD should be sufficient. I am hesitant to have a 
"rule" as compared to a "best current practice".

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Citation bug in RFC 2425

[Paul Hoffman / IMC]

At 03:16 PM 10/29/99 -0700, [EMAIL PROTECTED] wrote:
>Using a URL in a citation in an RFC seems like a bad idea.  There may
>be exceptions, e.g., an IETF.org or RFC-Editor.org URL might be less
>risky.  But expecting a URL in general to stay invariant for 25 years
>seems dubious.

Not to worry in this case: it wasn't a normative reference. In fact, that 
reference wasn't mentioned at all in the body of the RFC. :-) They did 
manage to get the URL correct in RFC2426, where it is also a non-normative 
reference.

--Paul Hoffman, Director
--Internet Mail Consortium