Subject: Re: ADMIN: Final warning to John Stanley

From: John Stanley <[email-masked]>
Date: Tue, 13 Sep 2005 10:01:12 -0700 (PDT)

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>I do not find you amusing.

I was not attempting to be amusing. I was attempting to point out that
this "diagnostic-thingy" is the same sort of duck a path-identity is, no 
matter if we call it a goose or a gondola. If a colon in a path-identity 
is forbidden for cause, then the same cause exists to forbid it in a 
diagnostic, because a diagnostic will appear in exactly the same place.

In fact, looking at your ABNF for this "path-diagnostic", I'll point out
to you that, unless the diagnostic starts with one of the punctuation
marks, or contains a colon, it is impossible to differentiate between a
"path-diagnostic" and a "path-identity". "a.example.com" is completely
ambiguous.

I was going to respond separately to your proposed text, but in for a 
penny:

> A <path-identity> is a name identifying a site. It takes the form of a domain
> name having one or more components separated by dots.

Incorrect. A path-identity can also be a single word, as in a UUCP name.  
This is historical usage that nobody is seriously thinking will stop just
because we say it should. Your own ABNF does not mandate a dot. Even your
own proposed text for path-identity allows single word (i.e.  'dotless')
names. (Item 3) There is no "domain name" requirement.

>A path-diagnostic is an item inserted into the Path header for purposes 
>other than to indicate the name of a site.

You've defined what purpose a path-diagnostic is NOT for; what IS it for?
"Other than the name". Well, ok, it's not the name of a site. Except 
sometimes it will be; it can be the "real" name of the site a server gets
an article from if there is a mismatch. Not only is it then indicating the 
name of a site, it is indicating a name of a site the article passed 
through. And that's how we define path-identity. Green is red. Red is 
blue. Blue doesn't exist.

There is just not enough difference between the two to justify this 
artificial differentiation. The time you are using to debate this and try 
to come up with correct ABNF and new definitions is wasted. The existing 
path-identity is more than sufficient to do what needs to be done, and by 
simply prohibiting colons in IPv6 addresses we solve the dead:beef 
problem. And yet it is more constructive at this point in the game to 
spend more time debating new definitions that aren't really definitions at 
all.

>The colon (":") is permitted in order to allow IPv6 addresses to be 
>inserted;

IPv6 addresses can be inserted without colons; it is only one method of 
encoding them that uses colons, and a different method has been proposed 
to accomplish the same goal without the following admitted problem:

>note that this will cause interoperability problems at older sites that 
>regard ":" as a path-delimiter ...

Interoperability is a key goal, no? Ok, I guess not.

>I will suspend your posting rights to this list the next time you post 
>something that I find equally non-constructive.

I find it non-constructive to pretend that text that cannot be entered
as a path-identity is suddenly acceptable in the same context only because 
we call it something else. What we call it is not the problem; the effect 
it has on existing implementations is.

I find it seriously non-constructive to ignore a simple solution to a 
problem that we keep debating and then writing into a standard 
explicitely. Your latest proposed text continues this non-constructive 
trend by admitting that existing software will break if a colon is used in 
an IPv6 literal, completely ignoring a trivial solution to the problem. 
Yes, we CAN define how an IPv6 address is encoded into a Path header. It 
is within our jurisdiction. No, this is NOT something that thousands of 
admins around the planet will have to enter by hand every day, it's 
entered automatically by software that can easily produce the required 
output. When it appears as a diagnostic thingy, it will be SOFTWARE that 
enters it there, not a human, and SOFTWARE can easily convert an IPv6 
address into 32 hexadecimal characters. 

I find it non-constructive to claim that something is a "given" when the
truth is that it might be a consensus belief. "Given" means that something
is an assumption from which discussion is started, not the (shaky) result
of a long debate. Removal of Charles's item 2 is NOT a given, even if the 
Chair pretends it is. It is a CHOICE made after long debate.

I've been constructive, I've provided the solution to a problem that you
don't seem interested in doing anything about. I'm now simply reminding
you that you've chosen to ignore the constructive comments, and that this
entire discussion about what a "diagnostic" is and is not is a waste of
time and effort.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Sep 2005 11:14:59 +0200

NOTE: I don't have much hope of John's behaviour to change based on this 
note. But it may be useful for other people to see it.

Unlike John, I will reply to the administrative portion, dealing with 
behaviour, separately from the technical portion, dealing with the actual 
proposal and objections to it. This is the administrative bit, and only 
refers to the technical bit when required to illustrate the point.

--On 13. september 2005 10:01 -0700 John Stanley <[email-masked]> wrote:

> as a path-identity is suddenly acceptable in the same context only
> because  we call it something else. What we call it is not the problem;
> the effect  it has on existing implementations is.
>
> trend by admitting that existing software will break if a colon is used
> in  an IPv6 literal, completely ignoring a trivial solution to the
> problem.  Yes, we CAN define how an IPv6 address is encoded into a Path
> header. It  is within our jurisdiction. No, this is NOT something that
> thousands of  admins around the planet will have to enter by hand every
> day, it's  entered automatically by software that can easily produce the
> required  output. When it appears as a diagnostic thingy, it will be
> SOFTWARE that  enters it there, not a human, and SOFTWARE can easily
> convert an IPv6  address into 32 hexadecimal characters.

You have proposed this solution. I, and others, have observed that the same 
debate on how to format an IPv6 address has been had in multiple other 
fora, including in URIs, and the conclusion has always been to stick with 
standard notation.

You have not replied to this.

The group has discussed the size of the problem (dead:beef:cafe) caused by 
using standard IPv6 notation, and my reading of the consensus (without an 
explicit poll for it) is that the group does not regard the problem as a 
big enough problem to worry about.
No example of an active site with a 4-letter hex-only name has been brought 
to the attention of the working group.

You have not replied to this by anything I can see but "I disagree", and 
formulations that I interpret as "it's obvious that I'm right".

> Chair pretends it is. It is a CHOICE made after long debate.

Yes. And that choice is a given that we base the next steps on.
You may choose to think that the group's choice is wrong, but this does not 
give you the right to endlessly harp on the issue, and insist that your 
disagreement be acknowledged somehow every time the issue is referred to.

> entire discussion about what a "diagnostic" is and is not is a waste of

You've made proposals. You've had objections raised to them. You've not 
responded, but have insisted that you have presented "the solution".

I'm not saying none of your messages to the list are constructive. But your 
failure to respond to criticism, and the vituperative tone of your 
messages, including the "green is red" non-sequitur you keep on inserting, 
is simply not acceptable behaviour for a WG participant.

                   Harald

---

From: Richard Clayton <[email-masked]>
Date: Wed, 14 Sep 2005 10:41:02 +0100

In message <E943132E910A141B32C6C6C0@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[email-masked]> writes

>to the attention of the working group.

I've checked my data from last year, I find that there were just four
4-letter path entities in use at that time (I would not expect the
number to increase, rather the opposite).

They were

        news, mail, iraf, qmul

and the first two are clearly poor choices for a peering server

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Richard Clayton <[email-masked]>
Date: Wed, 14 Sep 2005 12:09:37 +0100

In message <[email-masked]>, Richard Clayton
<[email-masked]> writes
>and the first two are clearly poor choices for a peering server

my humble apologies, I checked the wrong list :( I should also add from
"the peering core" of Usenet the following four letter words

        VISP, apex, esel, frgp, jpix,
        ktts, ornl, rice, spin, srcc,
        sws1, tino, torn

and add to these the following path identities from machines (actually I
think most of these will be usernames, which the POSTED requirement
would hide away) which only passed articles _to_ the peering core (ie
never receiving articles from the core and passing them on)

        -ro-, 1010, 3576, 4908, 5849, 6441, 6800, 7338, AAVN, acox, 
        act1, alan, alee, alex, alya, andy, anna, anon, anti, APSY, 
        asya, aton, ba52, bams, bbs3, bbty, bdl5, bill, BJPU, blah, 
        blbl, BORG, boyd, bram, brc4, bull, BUPT, cab4, carl, cbon, 
        CDPA, cet1, cew2, CGSH, chet, chib, Ckit, cold, cool, cpla, 
        Cran, crux, cung, cunt, d158, dade, dani, Dave, dave, DCMA, 
        dd21, deep, dell, denx, dgw2, dirk, dlit, DMCC, donn, doug, 
        dre1, drum, duck, dude, earl, ecik, efbe, elis, emyr, eric, 
        erud, evil, FISH, Fool, fort, free, frey, fttk, fuck, gck2, 
        gdfs, geb3, gene, ggrl, gjba, goon, gruu, gssm, gull, hace, 
        Hace, HCHS, hill, ihug, ikke, iraf, iret, iron, itcz, J0lt, 
        JAR1, jimd, jmac, jml4, john, jori, js54, jv11, jw35, jyri, 
        k235, K3UD, kami, ke10, KHHS, kibo, kiko, kirk, KMSH, kuff, 
        kulu, KYXK, laki, lala, ldjy, leif, liam, Life, Lion, LMM8, 
        loes, lota, luca, luna, lyle, lynn, macs, MANA, Mark, MAYA, 
        mbt2, MDJS, mevk, mgh3, mhg3, mike, miou, mivo, mjtg, mLog, 
        mlsh, Mr.X, mrr1, MSIA, MYTH, name, NCIT, NDHT, need, nemo, 
        neo1, ng56, nide, njtc, nmm1, NNRP, nono, nosp, NTUA, null, 
        OCSA, ORCH, oreo, otto, pane, pang, papa, parc, paul, PCCU, 
        pest, pete, PMSH, poka, pooh, prod, ps10, ptt2, QKMJ, rab4, 
        raff, rb28, rhps, rick, ronn, root, ross, rune, rz10, samc, 
        sara, sbor, SCAU, SCSC, shhh, shs7, SIEC, sino, sis4, Siyu, 
        SJTU, SLee, slim, SMTH, sole, spln, spok, spot, STAN, Star, 
        STAR, sven, Swan, swps, teej, thug, timl, tobi, tolo, tony, 
        towb, tr0x, trio, truc, TTSX, tusk, USTC, vans, vitt, WaBu, 
        wgrb, will, wing, wish, WOLF, woof, ws21, xman, XOOz, xp24, 
        yeah, YKVS, yt50, YTHT, zang, zbeg, zero, Zero, zygo, ZZXY

of this latter group, only these could be hex

        1010, 3576, 4908, 5849, 6441, 6800, 7338, ba52, cab4, d158,
        dade, dd21, efbe

where, one might flippantly ask, is the beef?

(betya all the people with naughty word filters won't see this message!)

- -- 
richard                                              Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Sep 2005 14:22:54 GMT

>"path-diagnostic" and a "path-identity". "a.example.com" is completely

John

_You_ know that the proposed syntax is a nonsense, and _I_ know that the
proposed syntax is a nonsense. But the WG has voted against us.

I have to live with that. I suggest you do the same.

>to accomplish the same goal without the following admitted problem:

Yes, but I believe that using a non-standard notation for IPv6 addresses
is a worse evil than putting up with the minor inconvenience of the
dead:beef problem (which is most unlikely to arise in practice, and is
easily worked around by any sysadmin who gets caught by it).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Sep 2005 02:08:27 +0200

>         ktts, ornl, rice, spin, srcc,
[...]

Thanks for info, it's always good to spice theoretical
debates with a bit of reality.... :-)  Do you also have
some statistics about "<bareword> starts with a DIGIT" ?

Based on your four-letter-<bareword>s it's apparently no
issue, <bareword> required to start with ALPHA is okay
when used as <path-identity>.

But not for <tail-entry>.  All proposals to use exactly
the same syntax in <tail-entry> did not pass this quick
reality check.  "We" were stupid, of course <tail-entry>
should be the same as <id-local> / <id-left> minus what
RfC 1036 considered as "punctuation".

                        Bye, Frank

---

From: Richard Clayton <[email-masked]>
Date: Thu, 15 Sep 2005 10:33:40 +0100

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>some statistics about "<bareword> starts with a DIGIT" ?

there are some domains starting with a digit, 4ax.com should be a clear
enough example of this to indicate the scale of that issue :)

as to bareword, there's 188 of these, ranging from "1", through "42" and
"666" to a whole lot which are clearly hex representations of IP
addresses, eg "40344AD0". In one case there is what may be a phone
number, "208-59-181-145". In all of these cases, the entity is outside
of the peering core, so I'd strongly suspect that these are all
identifications of posting agents and not of peering agents...

>when used as <path-identity>.

It won't break anything, and it would reflect current usage, but I don't
think "3com" will be amused though

>RfC 1036 considered as "punctuation".

I think it is pretty clear that <tail-entry> is currently free-form.

This isn't surprising, it started as an email address, morphed into a
tracing mechanism and has long been superseded in both roles by other
header fields....

... SO.... if one is redesigning the Path: header field to contain all
of these "!!" and MISMATCH values then it is probably worth wondering if
the <tail-entry> actually serves a useful purpose of any kind ?

Why exactly are we keeping it ?

The answer might be to avoid discarding too much when an article is re-
injected by the clueless, but this is rare and quite frankly I suspect
that the article-ID is quite sufficient. So is there another reason ?

BTW: I note that almost every instance of MISMATCH in my dataset is
attached to an IPv4 address ("130.133.1.3.MISMATCH"), there are a
handful of exceptions ("newsfeed2.easynews.com.MISMATCH") almost all
involving major sites (ie that might most easily be persuaded to change
their behaviour) and one IPv6 ("2001:770:10:300::86e2:510d.MISMATCH").

If one considers how a mismatch is detected, and what can actually be
usefully recorded, I think one can see why an IP address is almost
inevitable (and I suspect that the ones involving names are using subtly
different semantics ("it was supposed to be news.example.com and it
wasn't" as opposed to "this is where is came from")

- -- 
richard                                              Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Sep 2005 15:32:33 GMT

>never receiving articles from the core and passing them on)

If you are saying that many of these were <tail-entry>s, then they can do
no harm, because relayers are supposed to ignore the <tail-entry> (i.e.
you can happily use "dead" or "beef" as your <tail-entry>).

Does your data enable you to distinguish and remove such <tail-entry>s
from your list? If not, you have still shown that the problem is hardly
significant.

---

From: Richard Clayton <[email-masked]>
Date: Thu, 15 Sep 2005 19:31:10 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>from your list? 

I have the raw data still and could remove the last entry in the Path:
but in the real world there tend to be several entries at the end of the
path which serve a similar purpose (purporting to identify the poster)
and there is no algorithmic method of distinguishing them

ie: the results would not be much more illuminating

>If not, you have still shown that the problem is hardly
>significant.

the whole thrust of all of my data is that there is no problem. The
chair seems to be trying to move on re dead:beef & I'm backing that

However, having thought about the issues a little more, my current
challenges are for someone to explain what purpose the <tail-entry>
serves in the revamped Path: header field, and secondly to explain a
scenario when a diagnostic such as MISMATCH could ever be attached to
anything other than an IP address.

These seem to still be relevant open issues (but if the chair feels
otherwise I'll be quiet since it isn't going to break anything I care
about)

- -- 
richard                                              Richard Clayton

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Sep 2005 07:48:15 +0200

Richard Clayton wrote:

>> <bareword> required to start with ALPHA is okay when used
>> as <path-identity>.

> It won't break anything, and it would reflect current usage,
> but I don't think "3com" will be amused though

I've removed <bareword> from my last attempt - if we really
want to allow "underscore before a last dot", then it makes
no sense to introduce FQDN vs. bareword details in the ABNF:

<bareword> degenerates into "<path-identity> without dot".

If that's all nobody cares, because it's obvious.  Add note
"you better pick a FQDN <path-identity> with a dot", ready.

 [tail-entry]
> it is probably worth wondering if the <tail-entry> actually
> serves a useful purpose of any kind ?

> Why exactly are we keeping it ?

Actually we're "introducing" it, it was optional in RfC 1036:

| Normally, the rightmost name will be the name of the
| originating system.  However, it is also permissible to
| include an extra entry on the right, which is the name of the
| sender.  This is for upward compatibility with older systems.

If we require it (like s-o-1036) it's at least clear that the
right-most entry (e.g. "not-for-mail") is _always_ irrelevant.

> So is there another reason ?

Guessing:  ordre, contreordre, desordre.  We can't forbid it.
Making it optional (again, like 1036) is worse than required ?

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 16 Sep 2005 11:32:37 GMT

>and there is no algorithmic method of distinguishing them

Sure, but if a site adds foo!bar!tail-entry to the Path before injecting,
then "foo" and "bar" are likely to be identities of hosts within the
poster's site, or deliberate attempts to keep the article from appearing
at some sites (the 'cybercancel' convention, for example), or similar. So
it may well be less likely for them to consist of four (or less) hex
digits.

>anything other than an IP address.

The <tail-entry> is a historical oddity. But it has to be there, because
present practice (and USEPRO) is that it should be ignored by relaying
agents when checking for peers in the path-list. (Or, if you like,
everything after the last "!" is to be ignored).

I agree its form could be freer than my syntax makes it (so long as it
contains no "!"), but there might be problems in allowing it to be empty
(i.e. a path-list ending in "!") since I know of no surrent practice like
that.

How about:

   tail-entry = 1*( alphanum / "-" / "_" / "." )

i.e. pretty much anything that is clearly not a delimiter?

As to things other than IP-addresses preceding MISMATCH (in either of my
syntax versions), I think you have to allow <bareword>s (for UUCP
connections, and for where the "true-identity" which didn't MATCH was
obtained from some SASL authentication rather than the IP of the incoming
packets).  And if the site detecting the MISMATCH has been kind enough to
reverse-lookup an incoming IP address and give you the result of that,
then you (as a human peruser of the Path) should be grateful that it has
saved you the trouble of doing it yourself. Since many sites currently
seem to do just that, then we should allow the practice to continue.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 13:31:09 GMT

>Making it optional (again, like 1036) is worse than required ?

Exactly so. Current practice is that it is always present, but is ignored
when deciding which peers to relay to (as in s-o-1036). That has been in
all our drafts (last discussed about 7 years ago), and is best left so.

---

From: Richard Clayton <[email-masked]>
Date: Tue, 20 Sep 2005 14:43:02 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>The <tail-entry> is a historical oddity. 

yes indeed, and serves no further useful purpose

>But it has to be there, because
>agents when checking for peers in the path-list. 

OK, I see that's unavoidable for reasons of interworking

>(Or, if you like,

Why not insist that modern servers (who follow the new rules) just put
!POSTED into the Path: header field and tell them that if they wish to
record other information into the article for Traceability reasons to
use the new header field provided specially for that purpose ?

>packets).  

that would be rare, but I accept it's possible... however, it seems odd
that such a connection would fail to match (SASL doesn't normal permit
the wrong person to connect)

>And if the site detecting the MISMATCH has been kind enough to
>saved you the trouble of doing it yourself. 

no, you should curse it for failing to understand a key principle of
making traceability robust :(   see the LINX BCP document of
Traceability (or my PhD thesis) for a longer explanation of why :(

>Since many sites currently

I rather suspect, as I said before, that they may have subtly different
semantics in that they are recording who it was supposed to be, rather
than who it was :(

- -- 
richard                                              Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 21 Sep 2005 10:14:53 GMT

>use the new header field provided specially for that purpose ?

Because there may be some useful information preloaded into the Path
before it reaches the injector (pseudo-identities such as 'cybercancel'
for example, or some record of paths traversed inside the posting site
before it reached the injector). There is also the rare case of a
reinjection, where there may already be several genuine <path-identity>s
followed by a POSTED (the reinjecting site is supposed to preserve these,
and add a further POSTED, so that everyone can see what has happened).

Also, the injecting site might choose to insert a <source-identity> after
the POSTED:
    injector.example!POSTED!123.123.123.123.SEEN!not-for-mail
(though a posting-host parameter in the Injection-Info would be a more
usual place to do that - but it does happen).

What you propose would in fact work (the 'POSTED' gets ignored just like
'not-for-mail') but it is confusing two concepts, so I would not want to
recommend it.

>the wrong person to connect)

If FRED identifies himself to good.guy.example (correctly) via SASL, but
shows himself as BILL in the <path-identity> he inserts (because he seeks
to hide the fact the article passed through him, or he wants to shift some
blame onto BILL), then the good,guy site should make the Path look like:

    good.guy.example!FRED.MISMATCH!BILL!...

and FRED's duplicity is exposed.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 21 Sep 2005 12:39:04 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>and FRED's duplicity is exposed.

and once again you have no hope of identifying FRED without looking at
the system configuration (and probably also the system logs) at
good.guy.example

- -- 
richard                                              Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>

Frank's. He also omits the MATCH keyword (#2 above).

>This has the interesting feature that it removes keywords, and changes the 
>!! delimiter from a "delimiter" to "the introduction to a path-diag".

It essentially does the keywords in style (b). The meaning of "!!" is
exactly the same as the present USEFOR (modulo possible bugs concerning
[FWS], which can be fixed).

>---- Charles' first proposal of Sept 15:

This essentially takes style (a) of #1, and the minimal set from #2.

There are some small changes arising from recent discussions which I have
not published as a full set yet. I also want to put the [FWS] before the
'!' rather than after (as Russ suggested). I will probably simplify the
<path-entry> to be more like Frank's (see above). There remains the issue
of [FWS].

>--- Charles' second proposal of Sept 15:

This essentially takes style (b) of #1, and the maximal set from #2 (and
these are my personal preferences). Other remarks as above,

>------ My proposal of September 13:

This takes style (a) of #1, and the minimal set from #2.

The main differences are that it does not relate the various objects to
FQDNs, IP-addresses and barewords, it allows that ':' in places other than
IPv6addresses (hence more scope for dead:beef problems), and it contains
more ambiguities. OTOH, it is a fair representation of what servers will
in practice recognize (as opposed to the others which show what should be
generated).

>This version needs an update to deal with the consensus to split barewords, 
>tail-entries and domain-based identities, as sketched above.

Which would actually bring it closer to the style of the others.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Sep 2005 12:00:37 GMT

>the system configuration (and probably also the system logs) at

Sure, but we don't expect to be able easily to identify sites that use
<bareword>s, which is why we encourage the use of domain-names wherever
possible.

So even if I cannot persuade good.guy.example to divulge the identity of
FRED, the fact that he appeared in the MISMATCH is quite useful, because
I can identify him in other Paths, find out who his peers are, see whether
he is regularly in the habit of impersonating BILL (or other people), and
if necessary I can choose to filter out articles with FRED in the Path
(which could be very useful if the malpractice that FRED is engaging in is
some form of hipcrime-like spew or other DOS attack).

[email-masked]> <[email-masked]>  <[email-masked]> <[email-masked]>  <[email-masked]> <[email-masked]>
Date: Thu, 22 Sep 2005 12:00:37 GMT
Lines: 40
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

>the system configuration (and probably also the system logs) at

Sure, but we don't expect to be able easily to identify sites that use
<bareword>s, which is why we encourage the use of domain-names wherever
possible.

So even if I cannot persuade good.guy.example to divulge the identity of
FRED, the fact that he appeared in the MISMATCH is quite useful, because
I can identify him in other Paths, find out who his peers are, see whether
he is regularly in the habit of impersonating BILL (or other people), and
if necessary I can choose to filter out articles with FRED in the Path
(which could be very useful if the malpractice that FRED is engaging in is
some form of hipcrime-like spew or other DOS attack).