Subject: DNS pollution

From: Keith Moore <[email-masked]>
Date: Wed, 11 Oct 2006 13:03:24 -0400

In the past month or so I've run across two separate ISPs that are 
apparently polluting the DNS by returning A records in cases where the 
authoritative server would either return NXDOMAIN or no answers.  The A 
records generally point to an HTTP server that will display 
advertisements, but I've also seen more sinister things happen.

Is there anything that IETF as an organization, or IETF participants, 
can do to discourage this?  To me this is fraud and unfair trade 
practice in addition to being a security threat (as people give their 
passwords when trying to connect to the wrong site) and harmful to 
applications (either because they do connect to a protocol engine on the 
wrong server, or they try to connect to a nonexistent protocol engine on 
the wrong server and treat the "connection refused" or "connection timed 
out" condition as a temporary error).  I've also seen this break 
applications that speak both IPv4 and IPv6 by failing to return the AAAA 
records.

I'm willing to write a draft explaining in detail why this is harmful, 
but somehow I think it will take more than just an RFC to get this 
practice stopped.

Keith

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Oct 2006 21:59:26 +0200

On Wed, Oct 11, 2006 at 01:03:24PM -0400,
 Keith Moore <[email-masked]> wrote 
 a message of 28 lines which said:

> apparently polluting the DNS by returning A records in cases where
> the authoritative server would either return NXDOMAIN or no answers.

Today, it is quite common and it becomes more and more common.

> Is there anything that IETF as an organization, or IETF
> participants, can do to discourage this?

Producing a RFC 4084bis is, IMHO, the best way to go. Currently, RFC
4084 does not address this issue, only a related issue:

>   o DNS support.
>      Are users required to utilize DNS servers provided by the service
>      provider, or are DNS queries permitted to reach arbitrary servers?

So, there is IMHO a good reason to upgrade the RFC.

> To me this is fraud and unfair trade practice in addition to being a
> security threat

I agree but I believe it may be difficult to have a rough consensus on
this one. The RFC 4084 approach (naming things, in a standard way, so
that users can at least choose) may be better. Do note that, in some
cases I know about (such as Club Internet, the T-online subsidiary in
France), the ISP provides a set of normal name servers to the users
who want, so they can claim that the user has a choice.

Another approach, not incompatible with this one, would be indeed to
produce a "Wildcards in DNS *resolvers* considered harmful" RFC. Any
volunteer for the first I-D? IMHO, this should be sent to the dnsop
WG and discussed there. A starting point may be (do note it addresses
wildcards in authoritative name servers, a related, but different,
issue) http://www.icann.org/topics/wildcard-history.html where the
technical papers raise the various concerns.

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Oct 2006 16:08:54 -0400

>> To me this is fraud and unfair trade practice in addition to being
>> a security threat
> 
> I agree but I believe it may be difficult to have a rough consensus
> on this one.

if we can't, that's a sad commentary on the state of IETF competence.

> The RFC 4084 approach (naming things, in a standard way, so that
> users can at least choose) may be better. Do note that, in some cases
> I know about (such as Club Internet, the T-online subsidiary in 

giving the user a choice is of little value when the user is actively
lied to about the consequence of that choice.  I'll bet they're not
asking users "do you want our DNS servers to lie to your applications?"

> produce a "Wildcards in DNS *resolvers* considered harmful" RFC.

unfortunately, the practice doesn't seem to be limited to just putting 
in wildcard A records, so focusing attention on wildcards might miss the 
mark.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Oct 2006 16:43:47 -0400

--On Wednesday, 11 October, 2006 21:59 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

>> In the past month or so I've run across two separate ISPs
>> that are apparently polluting the DNS by returning A records
>> in cases where the authoritative server would either return
>> NXDOMAIN or no answers.
> 
> Producing a RFC 4084bis is, IMHO, the best way to go.
> Currently, RFC 4084 does not address this issue, only a
> related issue:
> 
>>   o DNS support.
>>      Are users required to utilize DNS servers provided by
>>      the service provider, or are DNS queries permitted to
>>      reach arbitrary servers?
> 

I think there are several other reasons as well.   If we were
doing 4084 over again based on what I think we know today, I'd
recommend putting less emphasis on email issues --or even moving
them to a separate, supplemental, document-- and doing more work
on DNS tricks, the behavior of hidden and/or mandatory proxies
(if I recall, 4084 doesn't go further than a requirement that
they be identified), and preferential treatment of customers,
content providers, or applications (more or less the "net
neutrality" discussion, plus some issues about who gets hurt if
QoS options are provided to some customers and the relevant
network starts getting short of capacity or other resources).

But, while I could get up the energy to cheer if someone else
felt like doing the work, I'm personally disinclined to reopen
4084, or to try to persuade the IESG to do so, unless someone
can show where it is actually being used enough to do some good
and/or provide a persuasive argument about where it would be
used if identifiable changes were made.
 
best,
   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Oct 2006 16:43:47 -0400

best,
   john

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Oct 2006 21:51:02 +0200

Keith Moore wrote:

> this is fraud and unfair trade practice in addition to being a security
> threat (as people give their passwords when trying to connect to the
> wrong site) and harmful to applications (either because they do connect
> to a protocol engine on the wrong server, or they try to connect to a
> nonexistent protocol engine on the wrong server and treat the
> "connection refused" or "connection timed out" condition as a temporary
> error)

+1

> I think it will take more than just an RFC to get this practice stopped.

If users are not more free to pick a trustworthy DNS server very easily
it's bad.  With my vintage '94 setup I'm still forced to configure the
IPs manually, that's hilarious, but it also has some advantages, I know
which servers I (try to) use.  If there's anything that could be done in
the PPP RFCs please do.

More random thoughts:  Wrt to search.travel ICANN ran or runs a poll how
to deal with this wannabe-museum-site-finder reincarnation.  Then there's
an RFC about "full Internet providers", maybe that has to be updated with
a statemement why lying DNS servers won't do.  Outside of the IETF maybe
some kind of "dns-ignorant.org" could offer a public hall of shame (?)

Frank

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Oct 2006 11:14:24 +1000

> but somehow I think it will take more than just an RFC to get this 

	This is very similar to the situation covered by RFC 1535.

Network Working Group                                          E. Gavron
Request for Comments: 1535                            ACES Research Inc.
Category: Informational                                     October 1993

              A Security Problem and Proposed Correction
                   With Widely Deployed DNS Software

	In that case it was a bad search list.  You got a response
	you wern't expecting.

	The correct response for a name that does not exist on
	the Internet is Name Error.  Any ISP that returns anything
	else is committing fraud.  They are not providing the product
	that they advertised.

	If my ISP in Australia tries this I will be contacting ACCC
	http://www.accc.gov.au/ if I happen to notice.  I run my own
	nameservers.

	Note: I don't consider that this covers signin screens as you
	havn't at that point reached a agreement to provide Internet
	access.

	Mark

--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Oct 2006 08:40:00 +0200

dust off the IAB wildcard statement, and say "it's not any better when 
YOU do it"?

http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

While we're at it, let's say "blocking SRV records in your DNS proxy is 
harmful too".

Keith Moore wrote:
> authoritative server would either return NXDOMAIN or no answers.  The 
> A records generally point to an HTTP server that will display 
> applications (either because they do connect to a protocol engine on 
> the wrong server, or they try to connect to a nonexistent protocol 
> engine on the wrong server and treat the "connection refused" or 
> "connection timed out" condition as a temporary error).  I've also 
> seen this break applications that speak both IPv4 and IPv6 by failing 
> to return the AAAA records.
>

---

From: Stephen Casner <[email-masked]>
Date: Wed, 11 Oct 2006 23:37:48 -0700 (PDT)

> applications that speak both IPv4 and IPv6 by failing to return the AAAA

I agree.  For me personally, this was not hypothetical.  The Pine mail
user agent that I use began to intermittently fail to connect to the
IMAP server even when there was no evidence of problems with network
connectivity.  The problem turned out to be DNS fraud.

I use ssh to connect over DSL service from Earthlink, and port
forwarding to get to the IMAP server.  That means Pine needs to
connect to 127.0.0.1 on the forwarded port number.  I don't know why,
but Pine does a DNS lookup on 127.0.0.1.  My problems arose when the
Earthink DNS servers began returning A records for a host that, if
accessed via http, provides a "helpful" message that the web site
address I had entered could not be found.  The DNS exchange, as
displayed by ethereal:

DNS  Standard query A 127.0.0.1
DNS  Standard query response A 209.86.66.92 A 209.86.66.93 A 209.86.66.94 A 209.86.66.95 A 209.86.66.90 A 209.86.66.91

This caused Pine to attempt an IMAP connection directly to that host
rather than connecting to my intended IMAP server through the ssh port
forwarding.

Why the behavior was intermittent I have no idea, but the problem was
baffling.  I was able to figure out the answer because I am able to
run tcpdump and interpret the results.  Someone with less knowledge
would just have to suffer.

                                                        -- Steve

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Oct 2006 00:58:56 -0700

One thought:

every time we encounter one of those problems, we should report an issue 
to the ISP's helpdesk.

If the opex of the "feature" is high enough, even accountants may get 
the point....

---

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Oct 2006 07:49:32 -0500

>but Pine does a DNS lookup on 127.0.0.1.  My problems arose when the

Sounds like an application layer implementation defect.  The problem 
could be solved by reporting the bug to the developers.

Of course I am against "fraud" of any kind, but I don't see the IETF 
having a hand in this issue.  Outside of explaining that the problem 
lies in that the DNS query does not convey the intent of the query 
(like, "it's to get a web page"), there isn't a much of a role to 
play.

Ironically - in the past year, the DNSOP WG considered a proposal 
called "white lies" in which falsified negative answers were to be 
used to prevent someone from using DNSSEC records to discover all of 
the contents of a zone.  "Falsified" became "synthesized" and at 
least one RFC got produced (http://ietf.org/rfc/rfc4471.txt).

There's a fine line between record synthesis and fraud.[0]  We can 
talk about the synthesis, but fraud isn't a technical issue.

[0] Derived from 
http://www.brainyquote.com/quotes/quotes/s/stevenwrig105995.html.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

---

From: Peter Koch <[email-masked]>
Date: Thu, 12 Oct 2006 16:03:13 +0200

> used to prevent someone from using DNSSEC records to discover all of 

What Ed didn't say but could have to avoid myth spread: the schemes described
in RFC 4471 and RFC 4472 (dnsext's work, btw, but never mind ;-) require the
zone maintainer's consent, so they are applied by the person in technical
control of the relevant part of the name space. At best it's the protocol
that is 'cheated', not the user.

> talk about the synthesis, but fraud isn't a technical issue.

Authenticated denial _is_ a technical issue. See keyword in the last line
of the first quote.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 12 Oct 2006 16:03:13 +0200

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Oct 2006 11:17:56 -0500

>that is 'cheated', not the user.

Looking at this as a protocol analyst, how can the receiver 
distinguish between an answer that is generated by the authoritative 
source (whether a "true" answer or an obfuscated answer or an 
otherwise synthesized answer) or is generated (usually synthesized) 
by an interloper?

In the base DNS protocol, it can't reliably do so despite RFC 2181's 
trustworthiness measures.  That's why DNSSEC was defined.  Three 
times,  repeatedly so in response to adoption experiences.  And maybe 
a fourth time (NEC3).

What else can the IETF do?  Can the IETF force adoption of it's 
products? Can it penalize those that operate in ways not imagined at 
the start?

>Authenticated denial _is_ a technical issue. See keyword in the last line

I'm not sure what is meant by that...I know I've had arguments for 
authenticated denial with those that oppose it as "too much work."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Oct 2006 09:36:10 -0700 (PDT)

> used if identifiable changes were made.
 
Agreed on all points. But another and IMO more serious issue with attempting to
address this in RFC 4084bis is that a document entitled "Terminology for
Describing Internet Connectivity" isn't where I'd be inclined to look for rules
regarding DNS operations.

IMO this is a sufficiently serious issue that it needs to be dealt with in a
separate document that addresses it specifically. I'd be happy to try and
contribute to such a document.

				Ned

---

From: Stephen Casner <[email-masked]>
Date: Thu, 12 Oct 2006 15:44:01 -0700 (PDT)

> could be solved by reporting the bug to the developers.

I have now been informed that if I had enclosed the 127.0.0.1 in
square brackets then Pine would not looked it up as a name.

This potential for misinterpretation has probably not been seen as a
problem because on many systems the DNS resolver will recognize the
string as an address rather than a name and not do a forward lookup.
The system on which this problem was observed was Windows-98.

                                                        -- Steve

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Oct 2006 09:27:29 +1000

> The system on which this problem was observed was Windows-98.

	getaddrinfo() and getnodebyname() are both defined to accept
	literal addresses and return them.  As far as I am aware
	there is no such requirement for gethostbyname() though
	some implementations do detect when addresses are passed
	in.

	The original way to detect a IP address was to look for digit
	as the first character.  This changed with RFC 1123 which extend
	the hostname syntax to allow zeros at the start of labels.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 13 Oct 2006 08:28:58 +0200

On 11Oct 2006, at 7:03 PM, Keith Moore wrote:

> the authoritative server would either return NXDOMAIN or no  
> answers.  The A records generally point to an HTTP server that will  
> display advertisements, but I've also seen more sinister things  
> happen.
>
> participants, can do to discourage this?  To me this is fraud and  
> unfair trade practice in addition to being a security threat (as  
> people give their passwords when trying to connect to the wrong  
> site) and harmful to applications (either because they do connect  
> to a protocol engine on the wrong server, or they try to connect to  
> a nonexistent protocol engine on the wrong server and treat the  
> "connection refused" or "connection timed out" condition as a  
> temporary error).  I've also seen this break applications that  
> speak both IPv4 and IPv6 by failing to return the AAAA records.
>
> I'm willing to write a draft explaining in detail why this is  
> harmful, but somehow I think it will take more than just an RFC to  
> get this practice stopped.
>

Dear colleagues,

The IAB is working on a draft on transparency issues. It will appear  
shortly in the I-D repository. That document contains a paragraph  
about this issue:

2.5.  DNS Namespace Mangling
    In [RFC2826] the technical arguments for a unique root were
    presented.
    One of the premises in [RFC2826] is that a common symbol set, and
    common semantics applied to these symbols, is needed for effective
    communication between two parties.  The document argues that this
    principle can only be met when one unique root is being used and  
when
    the domains are maintained by single owners or maintainers.
    Because [RFC4084] targets only on IP service terms and does not talk
    about namespace issues, it does not refer to [RFC2826].  We stress
    that for proper IP service the use of a unique root for the DNS
    namespace is essential.
    Since the publication of [RFC2826] there have been reports that
    Internet service providers implement recursive nameservers and/or  
DNS
    forwarders that replace answers that indicate that a name does not
    exist in the DNS hierarchy by a name and an address record that  
hosts
    a webservice that is supposed to be useful for end-users.
    In a way the effect of these modifications are similar to placement
    of a wildcard in top-level domains.  Although wildcard labels in  
top-
    level domains lead to problems that are described elsewhere [Advs]
    they do not strictly violate the DNS protocol.  This is not the case
    for the above example where the modification of answers takes place
    in the middle of the path between authoritative servers and the stub
    resolvers that provide the answers to applications.
    [RFC2826] section 1.3 states:
       Both the design and implementations of the DNS protocol are
       heavily based on the assumption that there is a single owner or
       maintainer for every domain, and that any set of resources  
records
       associated with a domain is modified in a single-copy  
serializable
       fashion.
    In particular the DNSSEC protocol [RFC4035] has been designed to
    verify that DNS information has not been modified between the moment
    they have been published on an authoritative server and the moment
    the validation takes place. Since that verification can take  
place at
    the application level, any modification by a recursive forwarder  
will
    cause validation failures.

On a similar but slightly different topic: We also send out a comment  
to the relevant ICANN committee about the proposal to ad a wildcard  
to the travel TLD. (Should appear on the correspondence area of the  
IAB site shortly).

I think it may be a good idea to also create an IAB document that  
documents all these DNS issues that have to do with namespace tricks.  
The IAB comment on Sitefinder [1] could act as the core of that  
document. I'd be happy to work with a few volunteers to make that fly.

--Olaf Kolkman

[1] http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 13 Oct 2006 10:31:57 +0200

> document. I'd be happy to work with a few volunteers to make that fly.

Please do.  There's also the opposite problem, servers forced to lie
(in a German state).  And please withdraw...
 
http://tools.ietf.org/html/draft-kolkman-appeal-support

...it's just wrong.  I didn't try to find three "paying members" to
support that opinion, and nobody else is "qualified" to support it :-(

Frank

P.S.:  I know that "paying member" isn't a politically correct term.

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Oct 2006 10:03:01 -0400

> And please withdraw...

have to agree here.  the cost of IETF attendance these days (meeting 
fees, hotel, and travel) is such that few can afford to regularly attend 
meetings at their own expense, and there are many technically qualified 
people with a history of significant contributions to IETF whose 
employers don't regularly fund IETF trips.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Oct 2006 10:03:39 -0700

On Fri, Oct 13, 2006 at 10:31:57AM +0200, Frank Ellermann wrote:
> ...it's just wrong.

I think he's got a good idea.  It maybe could use some tweaking.

The IETF should stop doing things that are not relevant to its
constituency and serve only to waste its (donated) time-dollars.

This includes but is not limited to: appeals from total nuts.

One perfectly acceptable tactic, which Olafur has codified in this
draft, is to limit appeals to only those made by mixed nuts.

I think it would be more productive to suggest alternative tactics
than to ask Olafur to withdraw his draft.  We would all like to
know what other options there are.

> I didn't try to find three "paying members" to

...nor would you have had to.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Oct 2006 13:16:53 -0400

yeah, I sympathize with the desire to be less vulnerable to asymmetric 
attacks, and also with the general notion that if your appeal has 
sufficient merit to sway the iesg, iab, etc then you can probably find 
some people outside those bodies who think your appeal has merit.

I also believe that if "just anyone" can declare that an appeal has 
merit, the nutcases will band together to support one another.

I just don't think that IETF meeting attendance is an appropriate way to 
  decide who is a nutcase and who isn't.

-------- Original Message --------

> ------------------------------------------------------------------------
>

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Oct 2006 11:05:53 -0700

>  decide who is a nutcase and who isn't.

Appropriate or not, it's not an effective way to distinguish nuts,
as it should not surprise you to learn that most of the people who
come to IETF meetings are nuts as well.

Nor does it have to be if the goal is to reduce the frequency of
incidence rather than a complete shut-out.  By asking for a 'conspiracy
of mixed nuts' rather than a 'single nut acting alone', the frequency of
incidence should be drastically reduced.

But, we mustn't let nuts use their mom as a supporter, or else such
conspiracies of mixed nuts would ultimately be the rule.  So, some
limitations must be made.

The definitions in Olafur's draft for qualified supporters shouldn't be
considered exclusionary.  People in that position can still participate
by expressing opinions, or possibly might convince someone else to offer
their support in proxy.

Perhaps Olafur might even be convinced to produce text in his draft
that encourages individuals to provide their support in proxy, or to
allow IAB/IESG members to waive.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Oct 2006 11:13:12 -0700

> One perfectly acceptable tactic, which Olafur has codified in this

s/Olafur/Olaf/g

How embarrassing.  Sorry, Olaf.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Oct 2006 19:25:49 +0100

>  decide who is a nutcase and who isn't.

Me too. That'd be a move towards paid membership IMO and as was shown
with the recent NomCom selection, the record keeping involved can
lead to disputes.

If we take this apporach, (and I don't care really), then something
based on ever having written an RFC or an expired WG I-D would be
better; maybe combined with not having been barred from posting to an
(unrelated to the appeal) IETF list in the recent past. The person
could still be a nutcase, but at least they'd be a bona-fide IETF
nutcase:-)

S.

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Oct 2006 11:03:20 -0700 (PDT)

> I think he's got a good idea.  It maybe could use some tweaking.

A lot of tweaking is needed IMO. I have no problem with the idea of requiring
some measure of support for an appeal, but as usual the devil is in the 
details, and I think the current draft is badly off the mark in this regard.

The problem with using NOMCOM-eligibility is that there are plenty of serious
IETF participants who don't attend enough meetings to qualify. I'm already
uncomfortable that lack of attendance precludes NOMCOM participation, but there
is at least some justification in the NOMCOM case in that certain social skills
are needed by the various nominees, and good luck on assessing those in the
context of the IETF without having attended some meetings, and preferably
recent ones.

When it comes to appeals of IESG and IAB actions I don't think serious
participants who happens not to attend meetings should be placed at any sort of
disadvantage in regards to partipication.

I would be tempted to suggest a weaker version of the NOMCOM criteria,  e.g.,
having attended at least 3 out of the last 9 meetings, or even having attended
at least one meeting, were it not for the fact that there are some valuable
contributors who have never attended a meeting, period. Heck, this category
even includes the chairs for some _successful_ WGs. So I don't believe this
works either.

And weakening the criteria to simply be some form of participation, e.g. a
posting to some IETF list means you qualify, makes them effectively useless.

Perhaps the way to go is to simply says that you have to have some number of
identifiable supporters, never mind the qualifications of those supporters. But
would this actually reduce the number of bogus appeals? Others have suggested
that this will cause the people filing these appeals to band together. I
honestly have no idea if that would happen or not.

In any case, I think there is far more danger associated with excluding the
wanted than there is to including the unwanted.

> constituency and serve only to waste its (donated) time-dollars.

I don't think there's a lot of disagreement about this. The question is how to
get this effect without causing other, possibly worse, damage.

> draft, is to limit appeals to only those made by mixed nuts.

IMO it is not "perfectly acceptable" as presently described.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Oct 2006 05:49:00 +0200

David W. Hankins wrote:

> The definitions in Olafur's draft for qualified supporters
> shouldn't be considered exclusionary.

That's precisely how I understand them, and it's not hard to
guess which cases this tries to address.  It's also not hard
to guess which _unrelated_ 3.5 appeals I have in mind.

IIRC Brian mentioned that they need an open and transparent
dispute resolution process for the legal insurance.  And if
that's more expensive with the "paying-member-model" it's
even counterproductive.

> Perhaps Olafur might even be convinced to produce text in
> his draft that encourages individuals to provide their
> support in proxy, or to allow IAB/IESG members to waive.

Perhaps he could be also convinced to trash his draft.  I've
trashed an "3710-obsolete" draft (before publication - luck).

Frank, <http://purl.net/xyzzy/home/test/senderid-appeal.htm>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Oct 2006 09:05:32 +0200

Ned,

I am torn with the proposal.  On the one hand, I am sympathetic to DDOS
attacks on the process.  On the other hand, I agree with you that
serious contributors need a way to appeal decisions.  In particular, I
don't like the need to require support from additional serious members,
and I would only support that if other avenues failed.

If we look by analogy at the legal system (always a hazardous thing), we
see that there are often special rules in place when it comes to access
to the courts for those who have been judged vexatious litigants.  We
could do something similar.  While that alone doesn't prevent me from
creating an anonymous email address and filing an appeal, some rule
around that plus some indication of previous participation would be
useful.  So I would include a very liberal set of people, like those who
have ever attended an IETF or produced an RFC or have been published in
ACM, IEEE, USENIX, SAGE, and or some other list of credited networking
organizations.  If you've shown that you've contributed to the community
in some meaningful way then we should give you the benefit of the doubt.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Oct 2006 04:52:08 -0400

--On Saturday, 14 October, 2006 09:05 +0200 Eliot Lear
<[email-masked]> wrote:

> Ned,
> 
> I am torn with the proposal.  On the one hand, I am
> sympathetic to DDOS attacks on the process.  On the other
> hand, I agree with you that serious contributors need a way to
> appeal decisions.  In particular, I don't like the need to
> require support from additional serious members, and I would
> only support that if other avenues failed.
> 
> If we look by analogy at the legal system (always a hazardous
> thing), we see that there are often special rules in place
> when it comes to access to the courts for those who have been
> judged vexatious litigants.  We could do something similar.
> While that alone doesn't prevent me from creating an anonymous
> email address and filing an appeal, some rule around that plus
> some indication of previous participation would be useful.  So
> I would include a very liberal set of people, like those who
> have ever attended an IETF or produced an RFC or have been
> published in ACM, IEEE, USENIX, SAGE, and or some other list
> of credited networking organizations.  If you've shown that
> you've contributed to the community in some meaningful way
> then we should give you the benefit of the doubt.

Eliot,

It seems to me that, if there is a "right track" here --and that
is not obvious to me-- that you are on it or at least on a
parallel one.   I suggest that implies several changes to the
draft, YMMD:

	(1) The "supporter" procedure/requirement should be
	triggered only is someone shows symptoms of being a
	vexatious appellant.  People who are entering their
	first appeals don't trigger it.  People whose last
	appeal was successful, even in part (that would need to
	be defined, of course, and that might not be easy) don't
	trigger it.   The only folks who need to look for
	supporters are those who have appealed before and whose
	appeals have been rejected as without merit.
	
	(2) The definition of someone permitted to be a
	"supporter" must, as several people have pointed out
	(Ned, IMO, most eloquently), be broad enough to include
	active IETF contributors who don't attend meetings.
	One class of action that might need appealing would be a
	procedural decision that would [further] impede the
	ability of those people to effectively get work done in
	the IETF and they _must_ have standing to appeal such
	measures by themselves or in conjunction with others who
	are similarly impacted.

	I would have no problem with a requirement that someone
	actually be a human being with some active interest or
	involvement in the IETF -- what some other standards
	bodies describe as a "materially concerned party".  But
	requiring meeting attendance as proof of that seems to
	violate all sorts of IETF principles.
	
	(3) The idea that, if someone successfully appeals, or
	supports an appeal, on one action, they should be
	permanently barred from supporting similar appeals in
	the future is seriously broken.  It could only have a
	chilling effect on the generation of appeals, legitimate
	ones as well as bogus ones, because one would want to
	save endorsements for important-enough occasions.  It is
	also at variance with a principle that has been
	discussed recently on the IETF list wrt mailing list
	behavior and complaints: how an appeal is processed and
	considered should depend on its substance and merits,
	not on the identity of the submitter.  This is
	particular important if someone who is relatively more
	familiar with IETF processes and fluent in English is
	asked to prepare an appeal on behalf of someone who is
	not -- a situation that, if anything, we want to
	encourage since I believe that well-drafted appeals tend
	to take less IESG and IAB time than ones in which those
	bodies have to spend time figuring out what the real
	problem is or what is wanted.

Now, clearly, the above has the implication of "one free appeal
per customer".  If the bad guys whom Olaf is trying to protect
against got themselves organized into a cabal, they could manage
a denial of service attack.   But I'm not sure that is a real,
as distinct from theoretical risk and, more important, I think
it is a risk we have to run if we want to have a viable appeals
process.

However, as I read the above, I wonder if the model of the I-D
is backwards and your observation about "vexatious litigants"
should be carried a bit further.  Suppose we consider this
situation as somewhat more like the mailing list abuse issue
than one in which we assume that every person filing an appeal
is the enemy until proven otherwise.  If we adopt a model of
that sort, then:

We change the possible responses to an appeal from, broadly,
"yes" or "no" to "yes", "no", and "no, and this is irrational
and/or obviously totally without merit".  The latter, which
could itself be appealed but not by the subject (only by someone
else on his, her, or its behalf),  would imply something
analogous to posting restrictions: a period in which the person
was barred from appealing, or needed supporters, or something
else.  Similar to posting restrictions, the requirements/
barriers could be escalated if they needed to be applied
additional times.

That is obviously just an outline with a number of details that
would need filling in, but it seems to me it has the important
property of shifting the balance from "everyone who considers
filing an appeal is presumed to be an attacker on the process"
to "those who abuse the appeals process get their leashes
shortened".  Since I believe that the ability to easily appeal
silly or inappropriate actions is a key part of our process
model --one that wards off the need for much more heavyweight
and complex procedures-- it seems to me that is the right way to
balance things.

     john

p.s. for those who have had in-the-hall discussions with me
about appeals and prevention of DoS attacks in the last few
years.  Yes, I have changed my mind.   Making things harder for
those who use the appeals mechanisms to insist that the IETF
follow its own procedures and conventions about proper review
does not seem to me to be in the community's best interest.
And, of course, if the IETF leadership --the IESG in
particular-- wants to avoid appeals of that variety, that can be
accomplished by the rather simple expedient of following the
procedures.   One might even assume that the relative sparseness
of such appeals indicates that they mostly do that... or that
the barrier to appeals is already too high.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 14 Oct 2006 11:49:10 +0200

> trashed an "3710-obsolete" draft (before publication - luck).
9/10 of all drafts are trashed by the quite effective mechanism of 
waiting 6 months... no need for dramatic action.....

that said, I'd be happy if the requirements were:

- supporters are distinct human beings
- supporters are willing to offer proof of identity to a secretariat 
function of the IETF

I might even toss in "has contributed to at least one IETF mailing list 
he's subscribed to".

The important point (to me) would be to shift appealants from a mode of 
"I am the lone voice of reason - if I am allowed to carry my arguments 
forward in front of a higher body, Truth and Justice will prevail" to a 
mode where appealants think "I need to check with a few other people 
that I'm right before progressing - perhaps my arguments are not 
compelling, or perhaps I even might be wrong".

It may cause reasonable people who are upset to think twice, and should 
rarely block an appeal where there's a real dissent in the community.

(I leave it up to people's memories to recover which specific cases the 
conditions above are intended to address...)

                Harald

---

From: Michael Thomas <[email-masked]>
Date: Sat, 14 Oct 2006 09:37:25 -0700

>	appeals have been rejected as without merit.

   Can an appeal be rejected with merit?

       Mike

---

From: Sandy Wills <[email-masked]>
Date: Sat, 14 Oct 2006 13:13:12 -0400

Michael Thomas wrote:

> John C Klensin wrote:
>> ...The only folks who need to look for supporters are those who 
>> have appealed before and whose appeals have been rejected as 
>> without merit.
> 

Certainly.

A simplistic created-on-the-spot example:

The IETF publishes RFC 8214, on "Lessons Learned About Hosting an IETF
Social", whereupon Ima Complainer appeals specification 8.3.2a
"Construction of Corkscrews"  because it includes the verbage "Threads
must be right-handed, ie, the screw must travel INTO the cork when the
handle is turned clockwise."

Appeal one:
   "I represent Bob's Hardware Company (henceforth BHC), which has been
making left-handed corkscrews for 300 years, and they work fine.  All of
our customers prefer them, saying that our tools are the best they have
ever found.  Why are you suddenly making our standard product
'non-standard'?"

Rejection of Appeal one:
   "The IESG has determined that BHC is a traditional supplier of tools
designed specifically for left-handed users.  As such, we find that BHC
is an exception to the "general use" of these standards.  The appeal has
merit, but is rejected."

Appeal two:
   "Everyone in the IETF Social Planning Work Group has blue eyes, and as
such cannot be trusted.  Please push RFC 8214 back until we can get some
brown-eyed engineers on this WG."

Rejection of Appeal two"
    "The IESG has reviewed several personality to eye color studies, and
has been unable to find any correlation between eye color and integrity.
  The appeal is rejected as being without merit."

It might make sense to have a ruling something like, "any participant
can appeal any IETF document or decision, with the following limit:  The
  body appealed to may, at it's discretion, refuse to accept an appeal if
the appealer has had more appeals rejected without merit than all other
results."

This means that, if more than half of your appeals were RWOM, they _may_
refuse to hear you.  Nothing keeps you from getting someone else to
appeal for you.  It's just that, if someone with no history does this
for you, and it is RWOM, then they are 1 to 0, themselves.

Are we simply formalizing a reputation system here?  Don't we have
better things to do?

-- 
Unable to locate coffee.
Operator halted.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Oct 2006 22:43:35 +0200

Harald Alvestrand wrote:

> 9/10 of all drafts are trashed by the quite effective mechanism
> of waiting 6 months... no need for dramatic action.....

Depends, that 3710-thingy was quite spicy, and all I know about
"cancels" in the tools.ietf.org archive is that it's possible.

> - supporters are distinct human beings

WP:SOCK is okay...

> - supporters are willing to offer proof of identity to a
> secretariat function of the IETF

...difficult, it reminds me of Usenet CSVs.  What do you have
in mind, a phone number offered for a verification call ?  They
would need to support different plausibility checks wrt WP:SOCK

> I might even toss in "has contributed to at least one IETF
> mailing list he's subscribed to".

That's simpler.

> The important point (to me) would be to shift appealants from
> a mode of "I am the lone voice of reason - if I am allowed to
> carry my arguments forward in front of a higher body, Truth 
> and Justice will prevail" to a mode where appealants think 
> "I need to check with a few other people that I'm right before
> progressing - perhaps my arguments are not compelling, or 
> perhaps I even might be wrong".

> It may cause reasonable people who are upset to think twice,

MAY as in "maybe not" ;-)  Maybe it's simpler today if folks
find the "procdoc-roadmap" with some bloody details not covered
by the new Tao.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 15 Oct 2006 00:17:12 +0200

> would need to support different plausibility checks wrt WP:SOCK
In a quite specific situation I was involved with, several supporters of 
an "alternate" viewpoint offered to make verification calls.
Unfortunately they all had the same telephone number.....

I find that generally the reaction from claimed identities falls into 
one of three distinct categories:

- "No problem, here's the pointer to my CV, here's 5 people who know 
both of us personally, if you need a copy of my driver's license just 
send me the fax number to send it to, what else can I do to help?"
- "For religious/political/conscience reasons I refuse to give out my 
identity to anyone, so rather than violate my r/p/c belief, I'll 
withdraw from the case. However, I understand your reasoning and respect 
your refusal to admit me as a party to the case."
- "mumble, mumble, mumble, civil rights, mumble, mumble, mumble, of 
course I am a separate person, mumble, mumble, mumble, what do you mean, 
how do you prove that you're not Bill Clinton, mumble mumble, what is 
this identity thing anyway?"

What I draw as conclusions from these 3 case should be obvious; I'm a 
little unhappy about not getting the full value of the input from the 
second class of people, but to the third class I say "good riddance".

                      Harald

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 15 Oct 2006 23:48:02 +0200

> send me the fax number to send it to, what else can I do to help?"

That "no problem" is a problem.  If I manage to create a JPG of some
obscure document and send it to the IETF secretariat, what are they
supposed to do with it ?  For a German passport I could attach an URL
with "roll your own ID" instructions.  Otherwise I could send them some
Google search results "indicating" that I'm at least persistent, with a
slight preference for two "n" at end of my name.

If the secretariat goes to that trouble it should have more benefits,
e.g. coupled with a NomCom "population" list of all folks who went to
one of the last three IETF meetings.  Or with a list of mail addresses
used to submit I-Ds.  Or a way to send messages to authors using a
persistent URL or address (published in the I-D or RFC) and working
ten years later if the author still cares.

"Single login" could be used for lots of IETF services, but it's not
cheap.  Known services could cover "has a banking account" (but as long
as they don't try money laundering sock puppets can have many accounts)

> "For religious/political/conscience reasons I refuse to give out my
> withdraw from the case.

Well, I've given up my Wikipedia account, deciding that their system is
not good enough for my believes, and that it can't be fixed.  The draft
in the subject line is worse.  On the other hand improving Brian's I-D
should be simple:  It might need something more substantial against any
"vexatious litigation", and one statement trying to forbid other ways
to appeal dubious decisions should be removed.

BTW, folks trying to write appeals can also learn to write drafts, if
you want to throttle appeals you might also need something similar for
publication requests (?)  Maybe simply demand that appeals - and while
we're at it interop reports - have to be formatted and published as I-D,
huge PDFs with the decent charme of "I could print my mail" are a pain.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Oct 2006 14:35:07 +0200

John C Klensin wrote:
...
 > 	appeals have been rejected as without merit.

That's roughly why I put a section in draft-carpenter-ietf-disputes
called "Single Dispute per Topic." We certainly need to create a
disincentive to repetitious appeals IMHO. Requiring supporters
may be a way to do that. John raises good points in his message.

Michael Thomas wrote:
...
 >   Can an appeal be rejected with merit?

Sandy gave you the caricature response, but the short answer
is yes, if the IESG (or IAB) feels that the technical point in
the appeal is valid, but not serious enough to invalidate the
document. That's really what technical appeals are all about:
someone who believes that a valid technical issue has been
set aside when it shouldn't have been, and wants the IESG
(or IAB) to take another look.

Ditto, if a process violation is not felt serious enough
to overturn a decision. As in: yes, we made a mistake,
but the end result is the same anyway.

    Brian

---

From: Sandy Wills <[email-masked]>
Date: Mon, 16 Oct 2006 10:15:13 -0400

Brian E Carpenter wrote:
> Sandy gave you the caricature response...

Well, if I wanted to give a technical example that was clear to all 
readers, I had to pick a technology that all readers were familiar with, 
right?  You use the tools appropiate for the job.

>, but the short answer

Which, I believe, is what I said. :)

-- 
Unable to locate coffee.
Operator halted.

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Oct 2006 11:45:20 -0400

> may be a way to do that. John raises good points in his

Hmm.  Brief reflecting on this comment suggests something else
in line with my comment above.  I would see it as much more
reasonable to require supporters, endorsement, or even requiring
that a second party generate the formal appeal if an appeal is
lodged with the IESG, the IESG says "no, and without merit", and
the person involved wants to appeal to the IAB.

The trick here, I think, is to try to keep the number of appeals
that are either designed to create disruption or that have that
effect to a minimum while recognizing that it is very much in
the interest of the IETF to have an easily-exercised appeal
process for those who are acting in good faith to try to reverse
a misunderstanding, oversight, or process abuse that could not
be handled at an earlier stage.   One might even want to
separate the rules for technical appeals from those applicable
to appeals about process or abusive behavior, especially abusive
behavior at the WG level (i.e., without IESG members being
directly involved) and create a slightly higher bar for the
latter after ADs and the IETF Chair conclude there is no
problem... or maybe not.

Again, I think there are tradeoffs here but that we need to try
to understand the kinds of appeals we really want to have, and
have quickly and efficiently.  And then, whatever else we do, we
should be sure we don't create unintentional obstructions to
those types of appeals as side effects of making repeated and
disruptive abuses more difficult.

    john

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 16 Oct 2006 19:20:02 +0200

Thanks to all that replied (and thanks to David for spawning a new  
subject header).
Below are a few thoughts and replies to things people brought up.

---

In a private communication somebody suggested that this draft is  
targeted to one or two specific individuals. That is not the case.

---

> And please withdraw...
If this turns out a extremely bad idea then I'll leave the draft be  
and we have the archive to proof that this idea has been raised and  
shot. You just shot the first bullet :-) .

---

> wanted than there is to including the unwanted.

As for my motivation to choose NOMCOM eligibility for supporters.

My underlying requirement is that supporters should understand the  
IETF culture and its structures. Besides, IETF participants should  
know the supporters. The idea behind that is that it creates a  
certain level of accountability between peers. All in all, supporters  
should individuals that can be clearly identified as stakeholder in  
the IETF (John used "materially concerned party").

I hope that we agree on that requirement; now we only have to define  
what makes a stakeholder (the devil in the detail)...

It is clear that anybody in a 'leadership' role can be clearly and  
unambiguously identified as stakeholder that understand IETF culture  
and structure. (All present and past WG-Chairs, IESG and IAB members,  
the draft should be clarified on this).

For non-leadership roles identifying stake-holders is more difficult.  
As far as I know there is only one _existing_ somewhat formal method  
to establish that; nomcom eligibility. I too, am hesitant with  
respect to using the nomcom criterion is the only  mechanism for  
which there is running code.

The immediate and obvious problem with the Nomcom criterion is that  
it excludes people that everybody knows are stake-holders  but never  
go to meetings, or go to them on less regular basis.  If there is an  
easy and unambiguous way to identify those IETF stakeholders I would  
want to include them. I've seen a few suggestions:
  - I have a feeling that writing an I-D puts the bar to low.
  - Having written an IETF-track document is a clear and unambiguous  
criterion. (Note that I used IETF-track here)
  - I do not think that membership of USENIX, IEEE, or other  
organizations helps to identify IETF stakeholders.

Have I missed suggestions?

----

In private communication it was also suggested that the supporters  
may should also take a role as mediator. I think that is not a  
requirement but I suppose that having the appellant talk to  
supporters may cause beneficial side effects.

----

John argued:
> 	triggered (...)

The problem I have with it is that it is a patch upon the patch.  
Besides, having an appeal denied is not always a _bad_ thing. I could  
imagine cases where one appeals because having the appeal denied  
actually clarifies how our procedures work.

> 	active IETF contributors who don't attend meetings.

I agree; see above.

> 	measures by themselves or in conjunction with others who

I understand your concern, but I think/hope it is academic.

I hope that it is clear from the I-D that _anybody_ can appeal as  
long as there are two people willing to say "the appeal body should  
put time into looking at this". And I actually trust there will be  
sufficient people in the pool that understand that their default  
response should be "support" of the appeal. That trust, I realize, is  
not hardcoded in the process.

> (...)	
> 	the future is seriously broken.

That is not what I intended, I mend to say:
If a supporter has supported an appellant, that same supporter cannot  
support that particular appellant again. The supporter can support  
other appellants.

> 	It could only have a
> 	save endorsements for important-enough occasions.

As long as the pool of supporters is sufficiently large compared to  
the number of appeals from one appellant I do not think that will  
happen. We could set a time-out on the "supporter not being able to  
support the same appellant".

I do not have the exact size of the nomcom eligibles but it is around  
a 1000 people.

> allow IAB/IESG members to waive.

_Olaf_ :-) wrote in the I-D:
"  Note that the appeal body may choose to consider an appeal even when
    there are not sufficient supporters."

Frank wrote:
(...)

> Maybe simply demand that appeals - and while

I think this that formatting is a  different issue, draft-carpenter- 
ietf-disputes is the place where it should be.

----

I hope the above clarifies where I came from and what my attentions  
are.... I must say that I find John's as quoted below pretty  
appealing too...

> barriers could be escalated if they needed to be applied

As a first response: I do not think that the outcome of appeals are  
limited to "yes" and "no" currently and that the appeal bodies in the  
IETF can actually say "sorry, no merit". However I think that it is  
time-consuming to actually make that assessment.

--Olaf
   (no hats)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Oct 2006 11:10:41 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> John C Klensin wrote:
    >> (1) The "supporter" procedure/requirement should be triggered
    >> only is someone shows symptoms of being a vexatious appellant.
    >> People who are entering their first appeals don't trigger it.
    >> People whose last appeal was successful, even in part (that
    >> would need to be defined, of course, and that might not be
    >> easy) don't trigger it.  The only folks who need to look for
    >> supporters are those who have appealed before and whose appeals
    >> have been rejected as without merit.
    >> 
    >> 

    Michael>   Can an appeal be rejected with merit?

Yes.  I think Robert's recent appeal was rejected that way.  I
personally think that Jefsey's appeal against the LTRU registry doc
set was a reasonable appeal although we declined to make any changes.
I suspect many people may disagree with me and argue that this appeal
was without merit.

I think the SPF and Sender ID appeals clearly had merit.  I'm not sure
whether we rejected them though.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Oct 2006 12:33:05 -0400

--On Tuesday, 17 October, 2006 11:10 -0400 Sam Hartman
<[email-masked]> wrote:

> personally think that Jefsey's appeal against the LTRU
> registry doc set was a reasonable appeal although we declined
> to make any changes. I suspect many people may disagree with
> me and argue that this appeal was without merit.
> 
> I think the SPF and Sender ID appeals clearly had merit.  I'm
> not sure whether we rejected them though.

Sam,

For me, the bottom-line question in each of those cases is
either:

	(1) Whether you think the IETF and its program and
	processes were injured or improved by the questions
	being raised on appeal, and
	
	(2) Whether you think the appellants intent was negative
	enough, relative to general IETF functioning, that you
	think measures should be taken to discourage them from
	filing further appeals or to make it more difficult for
	them to do so. 

You pick which question you like.  To me, they are essentially
equivalent.  And, to me, unless the answer to the chosen
question is "yes", then Olaf's proposal, as written, either adds
bureaucracy without accomplishing anything or, worse,
discourages the filing of appeals that are actually beneficial
to the community --in terms of the discussion they cause if not
in changing a particular decision.

If "without merit" doesn't describe the condition I'm looking
for well, then let's work on devising a different term and test.

And, if deciding which appeals are vexatious and which ones are
ok is too burdensome --especially relative to hearing a few more
appeals-- then, IMO, we shouldn't be spending time on trying to
figure out ways to make appeals harder.

To me, discouraging behavior we want (and, IMO, need) to
encourage in order to make things a little bit more difficult
for a few bad guys is a fairly poor tradeoff.  If we had a lot
of bad guy-induced problems that were paralyzing us and no other
ideas, then it might be worth it.  But, if we  don't have that
level of obviously bad behavior, we should be considering
options that focus on the behavior we consider unacceptable, not
on making things more difficult for everyone.  I guess that, if
we could figure out a way to do it, that would make me a
supporter of Mike's suggestions -- either the "community
service" version or the "orange jumpsuit" one.

Of course, as suggested in earlier notes, I'd find the idea of
endorsements ("supporters") completely acceptable and even a
good idea (i) if anyone in who participates actively in the IETF
could do an endorsement, (ii) if there were no restriction on
repeat endorsements, (iii) if the endorsements were expected to
contain analysis and information that actually contributed to
the consideration of the appeal, and (iv) if the whole
endorsement idea had been sufficient thought through that we
could have confidence that requests for endorsements did not set
off discussions firestorms on the IETF list.   I haven't seen
that proposal yet, and, for me, trying to design it falls under
the moratorium on process work I'm trying to enforce on myself.

regards,
     john

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Oct 2006 13:58:32 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> And, if deciding which appeals are vexatious and which ones
    John> are ok is too burdensome --especially relative to hearing a
    John> few more appeals-- then, IMO, we shouldn't be spending time
    John> on trying to figure out ways to make appeals harder.

I agree with you.

I think for several recent IESg appeals, there would be unanimous
support on the IESG for the proposition that considering the appeal
did not help the IETF or its processes.

In cases like that, it seems like having a fast track to get rid of
appeals is beneficial.  The main question in my mind is what mechanism
we use to prevent the appealed body from abusing this mechanism.

I don't think fast track mechanisms are needed for appeals to WG
chairs or ADs.  If the appeal is without merit, it takes the AD very
little time to write up a brief note denying the appeal.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Oct 2006 03:08:38 +0200

Sam Hartman wrote:
 
> I think the SPF and Sender ID appeals clearly had merit.

One decision said "we have found merit", and the other said
"we thank"...

> I'm not sure whether we rejected them though.

...the latter was in essence accepted, and the former also
had some effect, together resulting in the longest IESG note
I've seen anywhere so far.  The IAB decided that conflicting
IETF experiments are allowed if there's an appropriate IESG
disclaimer.  A kind of "kids, don't try this at home" maybe.

Frank