Subject: Re: #1047 (was: Old ticket status - USEFOR - Jan 3, 2006)

From: John Stanley <[email-masked]>
Date: Tue, 10 Jan 2006 18:24:51 -0800 (PST)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>We have already agreed that we can tolerate the occasional dead:beef
>problem,

No, "we" have not. The Chair may have declared a consensus to exist, but 
that does not imply agreement. I do not find it acceptable to create a 
problem for sites when the solution is trivial. It is patently trivial for 
a non-colon containing IPv6 encoding to be used for news headers. There is 
no reason not to require it.

>>If a server chooses to identify itself by IPv4 address, there is no
>>problem.

>We have already agreed not to permit sites to identify _themselves_ with
>IP addresses

There is no problem if they do so; that string is no better or worse than
a fabricated alphanumeric string. (The same "problem" that occurs if a 
server changes IP address occurs if a server changes name, so if it's a 
problem in one case it's a problem for both.)

>Our drafts have had diagnostics for the past umpteen years.

Wrong. The word "diagnostic" does not appear in as recent a draft as 
draft-ietf-usefor-usefor-04. In draft 04, there is something called 
"path-keyword", which is limited to two very specific strings. In fact, 
draft 6 still has the same two "path-keywords" and has ADDED the 
path-diagnostic, so claiming that "MISMATCH" is a diagnostic is false.
MISMATCH has been and still is a path-keyword.

>All we are doing now is considering whether to tidy up
>some existing usages which don't currently have a keyword to identify
>them.

Well, prior to that, someone needs to define what a diagnostic is, why it 
is important enough to differentiate it from anything else in the path, 
and then HOW it is differentiated. Even before that, someone needs to 
figure out why it is so important to record things OTHER than the path an 
article travels in the header field defined to record the path an article 
travels. Do we want to record the weather at the injecting site in the 
date header field, too? Or maybe the process id of the injecting agent in 
the date header field.

Draft 6 is completely open-ended in how a path-diagnostic is defined: "an 
item inserted ... other than to indicate the name of a site." (And it is 
the rest of that paragraph that creates the problem that could be 
trivially solved.)

Currently, the only way to identify a "path-diagnostic" (without being
able to know what it means) is to see a colon in it. There are a lot of 
potential diagnostics that don't contain a colon. As it stands, every 
path-identity can be a path-diagnostic, and even the two "path-keywords"
could be path-identities.

The question which  I replied to was:

>>  Still open whether USEFOR should specify syntax that allows one to
>>  tell the difference between a path-identity and a diagnostic.

And nothing in your response contradicted my answer of "YES, if 
diagnostics are important enough to create a definition for, they are 
important enough to be able to detect." That begs the question of what the
definition IS, and then why it should be in the path header field.

This situation is almost as bad as trying to enforce structure on a 
completely unstructured header. Path-identities have very little 
structure, and what little they do have overlaps in very great part with
path-diagnostics and path-keywords. If the difference is significant 
enough to spend time debating like this, then it is important enough to
define and differentiate. If not, why are we doing this?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 11 Jan 2006 07:42:34 +0100

--On tirsdag, januar 10, 2006 18:24:51 -0800 John Stanley 
<[email-masked]> wrote:

> problem for sites when the solution is trivial. It is patently trivial
> for a non-colon containing IPv6 encoding to be used for news headers.
> There is no reason not to require it.

John, welcome to the world of rough consensus; I believe your disagreement 
with the declared consensus on the topic is already well known.

You're reopening a closed issue, something that is only supposed to be done 
if you have new technical information to contribute.

Standard warnings apply; we've been here before.

                    Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 11 Jan 2006 12:17:32 GMT

>definition IS, and then why it should be in the path header field.

Your response seemed more intent on saying that diagnostics should be
outlawed entirely than on saying that, if present, they should be
identifiable as such.

But if you are agreeing that, if/when present, they should be
identifiable as such, then thank you. That makes two of us who have
expressed that opinion. If nobody disagrees, then perhaps we can now
proceed to implement that feature (by adding a "SEEN" keyword, or any
other mechanism people may care to suggest).

>define and differentiate. If not, why are we doing this?

There I agree with you, and I have indeed proposed syntax to do just that
(though maybe I had overdone 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: Richard Clayton <[email-masked]>
Date: Wed, 11 Jan 2006 17:48:24 +0000

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

>other mechanism people may care to suggest).

At present [though my database of sightings is almost 18 months old], a
very small number of sites are adding diagnostics.

The main diagnostic appears to be "this article arrived from an IP
address which does not seem to match the way I have been configured".
This is expressed as "MISMATCH".

Of course, as I and others have observed before, the most likely
explanation is that the configuration is wrong rather than that some
wickedness is occurring. However, when wickedness has been detected in
some other way and its source is being sought then doubtless the
MISMATCH will be one of the clues that is examined.

There does not appear to be any evidence of MISMATCH being treated as
something that is worthy of anyone's attention when no wickedness has
occurred.

Nevertheless, there are sites which are adding MISMATCH and they (or
their software author) clearly thinks it might be useful. Therefore this
group needs to either document the practice (because the aim is to put
what is being done on a formal basis) or fail to document it (hoping
that it will die out naturally and our disapprobation will hasten that).

However, it appears to be thought that adding the reverse of MISMATCH,
viz "I am prepared to vouch for this article arriving from where it says
it does" will be of value.

I cannot understand where the value arises :( and I think a very clear
case for that value must be made before we add this to the document.
There do not appear to be any sites that are currently adding this
marker (either as !! or !SEEN!) at present, so it's Yet Another Rfc
Invention That Will Confuse Implementors For Decades.

The reason it has no value, so far as I can see, is that it is
impossible to determine who added the diagnostic (someone who handled
the article afterwards can forge it).  Even if everyone is honest, then
a site that adds !SEEN! is just saying "I didn't add MISMATCH" so you
can deduce the value from the lack of the MISMATCH and finally, in order
to understand what exactly is being attested to...

        which might be: did the article come from a pre-ordained IP
        address? did it come from somewhere my local DNS resolver told
        me matched the name I am configured for? did it come from
        somewhere who could produce name/password credentials? did it
        come from my mother (who I trust implicitly)? etc etc

.. then you need to interview the sysadmins at the site which added the
marker to determine what their policy was a week last Tuesday when the
article passed through their system. And if you are going to all that
trouble then I expect they could look at some logs and tell you what you
needed to know anyway... in so far as anyone "needs to know" the source
of a Usenet article.

I fear, sorry chair, that I've just repeated myself -- since I am sure I
have wrote something similar some other year :(

To try and add value, I'd propose that since so few systems add MISMATCH
and it's basically valueless, we just document the 1036 scheme and hope
that the existing (pretty trivial) usage dies away.  As a fallback from
that, just document what we see in the wild  "IPv4address.MISMATCH" and
leave it at that.  YARITWCIFDs are the bane of Usenet. Why another ?

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Jan 2006 20:44:14 +0100

Richard Clayton wrote:

> To try and add value, I'd propose that since so few systems
> add MISMATCH and it's basically valueless, we just document
> the 1036 scheme and hope that the existing (pretty trivial)
> usage dies away.

What _exactly_ would that be, something like the following ?

path            =  "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list       =  *( path-identity "!" [FWS] )

> As a fallback from that, just document what we see in the
> wild  "IPv4address.MISMATCH" and leave it at that.

Same question about the (following) variant:

path            =  "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list       =  *( path-identity "!" [ path-mismatch "!" ] [FWS] )

path-mismatch   =  IPv4address ".MISMATCH"

Common stuff for both variants:

path-identity   =  ( 1*( label "." ) toplabel ) / path-legacy

path-legacy     =  1*( ALPHA / DIGIT / "-" / "_" )
tail-entry      =  path-legacy                   ; allows underscore

label           =  letdig [ *( letdig / "-" ) letdig ]
letdig          =  ALPHA / DIGIT                 ; compare RFC 3696

toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

Note that an IPv4 doesn't qualify as <path-identity>.  If you
want IPv4 as <path-identity> remove <toplabel> and replace its
one usage by <label>
                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 12 Jan 2006 17:28:14 GMT

>This is expressed as "MISMATCH".

I think that is sites running DNEWS.

But there is also a signficant quantity of sites inserting the IP of where
they received the article from (and there may also be sites inserting the
domain name thereof, but there is no way we can identify how much this
happens). Hence the proposal for a further keyword such as "SEEN"

>MISMATCH will be one of the clues that is examined.

Yes, I have a NOTE in USEPRO somewhere to the effect that such
misconfigured sites should clean themselves up.

And yes, the detection of assorted forms of wickedness is the main purpose
of diagnostics (though it may also help to expose interesting routeing
anomalies).

>Invention That Will Confuse Implementors For Decades.

There are sites effectively using "SEEN", but without indicating it as
such (see above). But it would be better if they only did so when what
they "SAW" differed from what the sending site claimed, and just used "!!"
when it matched. Yes, "!!" is a new feature, and it will not appear in use
overnight. But it is now around 6 or 7 years since this WG decided that
such a feature was needed (all we are doing now is fiddling with the
details).

>the article afterwards can forge it).

Yes, but the wicked guys do not have the ability to add bogus diagnostics
"afterwards", and certainly not to make their bogosity visible at all
sites receiving the article. The purpose is to make it easier to spot
whereabouts in the Path the bogosity started. If the Bad Guy really wants
to cover his tracks, then he has to subvert some news server somewhere,
and a news server that regularly exhibits Rogue behaviour will soon be
spotted and be leant on by its peers, or UDPed, or whatever.

---

From: Richard Clayton <[email-masked]>
Date: Mon, 16 Jan 2006 13:46:16 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>>very small number of sites are adding diagnostics.

I appreciate that things have moved on a little to a poll, but I thought
some figures would be useful (and it's taken a couple of days to find
the time to create them).  I hope the figures I have come up with means
that the chair will excuse any further flogging of this horse.

>happens). Hence the proposal for a further keyword such as "SEEN"

I've looked at my database (Jun-Oct 2004) and what was present at that
time in the Path headers.

Looking at who passed articles to whom (and using some heuristics to cut
off the "tail" of the paths [to the right of where POSTED might be])
then, as I have posted before, there are 2556 machines in the "peering
core" (these are machines that pass articles to each other) and 8507
"first class" machines that passed articles to two or more machines in
the peering core (but they were never given articles by the core, so
they are in some real sense "at the edges" of Usenet).

Note that these are machines, NOT sites (which may run multiple
machines). Reduce by about 10-15% for that.

Of the peering core:

        289 recorded a MISMATCH diagnostic at least once

         65 were immediately to the left of an IPv4 address

Of the first class machines

         31 recorded a MISMATCH diagnostic at least once

          5 were immediately to the left of an IPv4 address
        
I also found 820 other machines (which were also "at the edge") which
had IP addresses to the right of their identity.

The analysis so far does not of course reveal how many of these machines
were recording IPv4 addresses of diagnostics and how many were being
passed articles by machines that used an IPv4 address as their site
name.

However, looking at the 65 peering core machines whose identity was
immediately to the left of an IPv4 address, then only 5 of them were to
the left of more than one IPv4 address, and there were so few
occurrences that I can list them all !

        ash.uu.net, 198.5.241.25
        ash.uu.net, 198.6.0.7
        ash.uu.net, 198.6.0.85
        ash.uu.net, 198.6.0.86

        lnewsoutpeer00.lnd.ops.eu.uu.net, 195.129.110.7
        lnewsoutpeer01.lnd.ops.eu.uu.net, 195.129.110.8

        newshub1.wanet.net, 198.6.0.85
        newshub1.wanet.net, 198.6.0.86

        ngpeer.news.aol.com, 205.188.226.97
        ngpeer.news.aol.com, 64.12.151.225
        ngpeer.news.aol.com, 64.12.151.230

        uunet, 198.6.0.115
        uunet, 198.6.0.123
        uunet, 198.6.0.8

so unless you believe that any of these machines only peers with two,
three or four other machines, then there is NO EVIDENCE of any
widespread addition of IPv4 addresses as diagnostics except in the case
of adding MISMATCH

Perhaps Charles could substantiate his "significant quantity of sites"?

I would agree that many sites do currently add IPv4 addresses, but ONLY
in the "tail" of the Path header field (to the right of where POSTED
would occur).  ie: they're not doing it for propagation diagnostics

>of diagnostics 

This isn't very precise thinking.

Detection of wickedness is done by the site that receives the article
and concludes that it has not come from where it is supposed to come
from.  Putting this information into the path is more about promulgating
the presence of the wickedness -- for the community to consider on its
merits (such as they are). And I don't think the community is able to
form much of an opinion of that wickedness because of the policy issues
I mentioned before ("what does the diagnostic mean"?) and which have
been snipped by Charles

>(though it may also help to expose interesting routeing
>anomalies).

In what sense "interesting" ?

I cannot see that the diagnostics add anything to the information
already present in valid Path header fields. If there is no wickedness,
but merely some suboptimal routeing, then all that is provided is a
handy mapping between machine name and IPv4 address. Since that mapping
could well be many to one or sometimes one to many, it is hardly going
to illuminate anything :(

>such (see above). 

I'm afraid that I can find no evidence of that in my database.

Of course things may have changed in the past 18 months. Perhaps a
pointer to the code fragments in a current news peering program would
help to illuminate when such a change occurred ?

>But it would be better if they only did so when what
>when it matched. 

it would certainly be shorter, but doesn't make it more useful

>Yes, "!!" is a new feature, and it will not appear in use

and in that time, no-one has added it.

I could only join a consensus that it was a Good Thing if I saw a
committment from some (many?) of the NNTP server authors to add it to
their code.  If Russ said that it would definitely be in INN, then that
would make me considerably happier

In fact at the moment, most of the time when I have seen !! it can be
put down to incompetent forgery attempts (failing to preload a Path
header field correctly) and as such, !! could be seen as making existing
mechanisms fail :(

>whereabouts in the Path the bogosity started. 

It doesn't do that :(

If every site uses the diagnostics then the best that the wicked person
can arrange for you to see is this:

 Path: a!!b!1.2.3.4.MISMATCH!!d!5.6.7.8.MISMATCH!f!!g!!h.POSTED.i

and you conclude that he injected the article at "b" while pretending to
be "c". However, if "b" is misconfigured (and the IP address actually
belongs to "d" then the injection point was "d"). The only way to
distinguish these is to examine "1.2.3.4" and form an opinion as to what
it is currently being used for. This can be tricky :(

However, if only _some_ sites use the diagnostics then you will see

 Path: a!b!c!d!!e!!f!1.2.3.4.MISMATCH!g!!h!!5.6.7.8.MISMATCH!i.POSTED.j

and you can only conclude that the article was injected at

        a, b, c, d, e, f, etc

because the Path may be preloaded with fake !! or fake MISMATCH info

A mechanism that only works when almost everyone adopts would have to be
fairly impressive to work toward -- and I don't think this proposal is
especially impressive even when we get there :(

>If the Bad Guy really wants

there's much simpler ways to "cover his tracks" as a glance at the
headers from Google News articles would tell you.

This scheme is dealing (somewhat imperfectly) with a problem from 1999

>spotted and be leant on by its peers, or UDPed, or whatever.

There's even less evidence of this :(  In the past few weeks a case came
to light where it took a month to prevent someone injecting fake
moderator approvals. This sort of "Rogue"ness is an order of magnitude
of less concern :( 

- -- 
richard                                                   Richard Clayton

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Jan 2006 17:01:18 +0100

Richard Clayton wrote:

>> overnight. But it is now around 6 or 7 years since this WG
>> decided that such a feature was needed (all we are doing now
>> is fiddling with the details).
 
> and in that time, no-one has added it.

This can't be six years old.  My oldest article mentioning "!!"
(2004-11-09) is apparently <[email-masked]> or
<http://mid.gmane.org/[email-masked]>
  
In <http://article.gmane.org/gmane.ietf.usenet.format/27783>
(2004-11-04) Charles summarized the WG history of this issue.

Anything before 2004 that's not closely related to the first
WG Last Call in 2002 is somewhat outside of my radar, I've no
idea how prior incarnations of this WG arrived at the former
"path punctuation" syntax.

> I could only join a consensus that it was a Good Thing if I
> saw a committment from some (many?) of the NNTP server
> authors to add it to their code.  If Russ said that it would
> definitely be in INN, then that would make me considerably
> happier

[...] 
> A mechanism that only works when almost everyone adopts would
> have to be fairly impressive to work toward -- and I don't
> think this proposal is especially impressive even when we get
> there :(

In anti-spam communities "worldwide adoption" is an instant
killer argument (as a special kind of FUSSP).  But with your
statistics of about 12,000 machines in the "core plus first
class" it's not completely impossible.

If different folks apparently tried to invent essentially the
same "feature", and we manage to _offer_ one "official" way to
achieve what they want, then this might be better then letting
them re-invent the same fifth wheel in different ways.

Your argument "it doesn't really help to analyze a path" (at
least not now) is convincing, but you also said that you used
some heuristics to get rid of tail-entries in your statistics.

With !.POSTED that task might be a bit easier.  We discussed
that IP addresses within the path might be dubious, you found
that that's rare, less that 3% of the "core" in your sample.

A new syntax offering a way to get this "right" for those who
insist on it is not necessarily a bad idea.  Of course we can
also decree that IPs in the path are always "deprecated", and
cover this rare practice by <path-legacy> - then nobody knows
what it is, an unnamed server or some wannabe-diagnostics.

In your fallback plan you offered ip.MISMATCH.  And IIRC Russ
proposed to add something like "SEEN" for cases where a server
doesn't want to verify what it got (neither MATCH nor MISMATCH)
but still wants to record what it believes.

In another article you wrote:
| sites called "dead" or "beef" can have some problems not of
| their making... but since they don't seem to exist, I can
| live with a scheme that disadvantages them.

That disadvantage should be limited to cases where their peers
don't support the s-o-1036 Path syntax published 12 years ago.
I'm all for adding that point to appendix B and then forget it.

                              Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 17 Jan 2006 12:09:47 GMT

><http://mid.gmane.org/[email-masked]>

The basic idea is 6 or 7 years old, but the original notation used
assorted special delimiters such as '%', '*', '/'. The "!!" is a
more recent syntactic sugar arising from complaints by Bruce that some
legacy site somewhere might regard (or disregard) those special delimiters
(together with much theological argument about what delimiters 1036
actually allowed, and whether the actual implementation of BNews should be
taken into account). So we stopped the theological argument by going for
"!!", "MISMATCH" and "POSTED".

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 17 Jan 2006 12:38:15 GMT

>Perhaps Charles could substantiate his "significant quantity of sites"?

In the cases I looked at, the IP address had clearly been added by the
site to the left (since the site to the left always appeared with some IP
address to its right - which is essentially what you are reporting).

However, on doing a reverse DNS, it was always clear that the IP address
quoted always related to the site to the right. So it seemed that the site
to the left was routinely reporting (diagnostically) the IP address from
which it had received the article (without apparently checking whether it
MATCHed or MISMATCHed), and Russ then confirmed that this practice was
fairly common.

I found no case where an IP address seemed to have been added by a site in
order to indicate its own path-identity (though my sample was small), and
on the strength of that the WG decided to disallow IPaddresses as
Path-identities, reserving them for diagnostics only.

>be "c".

I do not see any "c" in your example.

> However, if "b" is misconfigured (and the IP address actually

Detecting wickedness is always tricky, but the more clues that are
provided, and the more sites implement those clues, the easier it becomes.
If site b or site d (whichever was the true injector) had added a
"POSTED", then it would have been much easier to spot.

>moderator approvals. This sort of "Rogue"ness is an order of magnitude

Yes, I saw that case. A month looks like par for the course. You certainly
cannot organize a UDP in less than that.

---

From: Richard Clayton <[email-masked]>
Date: Fri, 20 Jan 2006 13:31:20 +0000

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

[ delayed response, I fear that USEFOR is not a top-priority item in a
busy week :( ]

>address to its right - which is essentially what you are reporting).

I see IPv4 addresses a lot as well...  but only right at the edge of
network (at the far right of the path)  Usually there is something else
nearby in the Path header field which is equivalent to POSTED.

My analysis generally tries to discard tails because they don't tell you
much useful information about Usenet size & structure

>MATCHed or MISMATCHed), and Russ then confirmed that this practice was

I didn't see that in my data (but this may be common in tails)

>order to indicate its own path-identity (though my sample was small), 

There are some sites doing this, they're relatively rare

>and

and of course because it is straightforward for sites to address the
problem by finding some sort of textual identity

>I do not see any "c" in your example.

apologies, I reworked it a few times to prevent wrapping, "d"

>provided, and the more sites implement those clues, the easier it becomes.

it is never easy unless the person doing it is clueless :(

- -- 
richard                                                   Richard Clayton

---

From: Richard Clayton <[email-masked]>
Date: Fri, 20 Jan 2006 13:55:33 +0000

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>"path punctuation" syntax.

OK, so it's relatively new.

My impression remains that although there may have been some reinvention
of wheels for reporting mismatches, there's been far less enthusiasm for
reporting matches.

>them re-invent the same fifth wheel in different ways.

If we end up documenting existing practice for mismatches, or something
that is so close that DNews (or whoever) can make trivial changes to
embrace it, then my objection that this is inventing systems for the
sake of it falls, and I shall be quiet.

However, I remain unconvinced by the need for reporting matches -- but
there seems little value in reiterating that any further.

If we take up another suggestion of just providing a generic system in
USEFOR and leave the actual recommended usages for later then I can live
with that (and I can then argue against the ongoing folly of inventing
usages for the sake of it at a later stage)

>With !.POSTED that task might be a bit easier.

yes indeed

but what I was doing was processing millions of articles in an automated
manner for the purpose of estimating the current size of Usenet; and
having POSTED makes that much easier.

However, if you are examining a single dubious article to assess where
it has been injected into the system then you can apply extremely
complex reasoning (and all sorts of other databases) to the analysis of
the header fields. Where there is wickedness and the forging of core
server identities, I would expect the POSTED to be entirely misleading!

So it's a snare and a delusion.

Usenet injection points are hard to ascertain. Adding syntax to the Path
header field is only going to catch out the clueless.

>  We discussed

I thought we already closed the issue of IPv4 addresses (and the use of
UUCP names)  :(

- -- 
richard                                                   Richard Clayton

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Jan 2006 18:49:01 +0100

Richard Clayton wrote:

> My impression remains that although there may have been some
> reinvention of wheels for reporting mismatches, there's been
> far less enthusiasm for reporting matches.

Same here.  Russ said that servers won't like to check matches,
but maybe still want to insert what they "see" from their POV.
That's how we got SEEN.

Something like site!.SEEN.peer!peer!... would be excessively
verbose, obviously "site" and "peer" agree on the name "peer",
and site!!peer"... would be shorter.  Short is good for paths,
less reasons to fold it.

And !.MATCH!peer! is still shorter than !.SEEN.peer!peer! (or
a similar !.SEEN!peer!peer! - the question of "visibility" is
not yet settled).

If you say that that's all bogus, then the shortest solution
is of course to get rid of _all_ variants with SEEN or MATCH.

OTOH you say some sites use various kinds of MISMATCH.  These
sites should know when they have a match, but they can't say
so at the moment.  That's how we got Henry's (?) proposal WSP
as path separator for matches, later replaced by "!!".

Back to square one.  That's perfectly logical from my POV, if
you want MISMATCH you should also offer MATCH, and from there
you arrive at SEEN for sites wishing to use something that's
(not really) better than only "!".

> I remain unconvinced by the need for reporting matches -- but

I was surprised that A or B got much more support than C or D
in Harald's poll.  If all this "diagnostical" stuff is more or
less bogus, why don't we just kill it ?  Maybe keeping POSTED
if that's uncontroversial.

OTOH if we apparently want A or B, then we also should get it
right (syntactically), and not allow just anything determining
all details later in USEPRO.

>> With !.POSTED that task might be a bit easier.

Okay, apparently we could live with POSTED, let's keep it, and
move the rest to <old-path-diagnostic> or rather <path-legacy>
together with IPv4address literals and other demons.

> if you are examining a single dubious article to assess where
> it has been injected into the system then you can apply
> extremely complex reasoning (and all sorts of other
> databases)

When there still was a public peering database I could at least
try to analyze a path, but today I'd give up immediately (if it
is not the question "how does clara.net normally get de.all ?")

As you said a "MISMATCH" in the path does not really help, and
at best it's an unintended warning "not only this is dubious"
for clueless folks.

> I would expect the POSTED to be entirely misleading!

We can remove the complete diagnostics idea, and just stick to
"legal" (FQDN) vs. "legacy" (IPv4, demon, etc.) syntactically:

>> Of course we can also decree that IPs in the path are always
>> "deprecated", and cover this rare practice by <path-legacy>

> I thought we already closed the issue of IPv4 addresses (and
> the use of UUCP names)  :(

We had "at least one dot and toplabel" as syntactical solution.

Russ said "no dot" is not good enough for the legacy side of
things.  Without that trick we're forced to use an ABNF hack,
any future legal "demon.cat" would beat any legacy "demon.cat".

That's a reason to say "legacy" plus/minus "SHOULD NOT".  The
owner of "demon" would know why this doesn't affect his name
(= it's a bare word without dot).
                                     Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Fri, 20 Jan 2006 11:25:41 -0800

> and site!!peer"... would be shorter.  Short is good for paths,

The idea of .SEEN is not for !.SEEN.peer!peer!, but rather for something
like !.SEEN.feeder1.foo.com!news.foo.com! without carrying the implication
of MISMATCH that the server was actually configured with the right Path
header for foo.com and received the wrong thing.  In other words, it's a
way of saying "I don't know what the right Path identity for this server
is, so I don't know if the one it inserted (which didn't match its
configured hostname) is actually wrong or not, but just in case here's my
idea of what its hostname is."

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 23 Jan 2006 14:53:42 GMT

>> far less enthusiasm for reporting matches.

I think that is just because the issues raised recently have related to
the other cases. Back when Brad sold the basic idea to the WG Way Back,
reporting matches was seen as THE way to make life harder for the Bad
Guys (together with indicating the POSTED point, of course).

>as path separator for matches, later replaced by "!!".

There were various notations proposed en route. "!!" was seen as the
shortest (for what was expected to be the commonest case), and the safest
(as not conflicting with present usage).

>(not really) better than only "!".

The only benefit of MATCH is to make a tidy and consistent set of
keywords. For practical purposes, the shorter "!!" is much better, for the
same meaning.

-- 
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 A    Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 23 Jan 2006 14:53:42 GMT

ve, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5