Subject: ISSUE: USEPRO 3.2.1 - Number of path entries per site

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 15 Jan 2007 20:48:46 GMT

ISSUE Number requested. This was #18 and #19 in my list or protocol problems.

In 3.2.1 we have:

   If a relaying or serving agent receives an article from an injecting
   or serving agent that is part of the same news server, it MAY leave
   the Path header field of the article unchanged.  Otherwise, every
   injecting, relaying, or serving agent that accepts an article MUST
   update the Path header field ....

That allows prepending a <path-identity> to be omitted only when the
relaying/serving/injecting agents are all part of the same news server and
any relaying that is done is essentially in the internals of that server.
So you only expect to see one entry in the Path.

But the original intention, when we discussed this in connection with the
Path header in USEFOR (and as reflected in Usepro-06) went further than
this. Essentially, we did not want to REQUIRE more than one
<path-identity> per site (even though the article might get relayed
between several hosts at that site because the admins considered it more
efficient to split things up that way).

One quite often sees that, for example
	!fu-berlin.de!uni-berlin.de!individual.net!
which are all the University of Berlin in various guises, and
	!feed4.jnfs.ja.net!jnfs.ja.net!
and, unless it is really helpful for the site concerned for sorting out
problems later, does not need to be seen by the rest of the net.

I therefore wish to see a wording which gives the site discretion to omit
some of those surplus entries if they are not otherwise useful.

The wording I had in Usepro-06 was "Except possibly when relaying to other
hosts on the same site, it then MUST ....". That could be adapted to the
present text by writing:

   Except possibly when relaying to other hosts on the same site, every
   injecting, relaying, or serving agent that accepts an article MUST
   update the Path header field ....

which also has the advantage of being shorter. It does also suggest that
it is the final agent before it leaves the site that is the one to
include.

Which brings me to my next point, which is where a site, far from reducing
the number of identities it adds, chooses to add some extra ones.
Currently, that is covered by:

   4.  The agent MUST then prepend its own <path-identity> to the Path
       header field content.

   5.  The agent MAY then prepend additional <path-identity>s for itself
       to the Path header field content, following each <path-identity>
       so added with either "!!" or "!".  This is permitted for agents
       that have multiple <path-identity>s (such as during a transition
       from one to another).  Each of these <path-identity>s MUST meet
       the requirements set out in Section 3.2.

Yes, I know Russ has just changed that text slightly, and his changes
should stand, but my concern is with another aspect of the text.

Essentially, as I indicated in a reply to Richard, a site has need of two
identities (mabye even more):

1. It needs to tell its downstreams
      "Articles that I relay to you will come from the following IP
      address(es)/domain name(s): news1.example.net, news2.example.net
      ..., and those are the name(s) which you will see in our leftmost
      <path-identity>."
and then it's downstream can do MISMATCH checks properly.

2. It needs to tell its upstreams
      "Articles already passed through this site will contain one or more
      of the following <path-identities>: example.net, example_net....
      Please do not relay to us any articles with those already in the
      Path."

Now the <path-identity>s in both those two cases will often be the same,
but it is not necessarily so. Moreover, in case #2 it may be necessary to
add and specify more than one identity (say a domain-name and a
<path-nodot>, as in Richard's 'demon' example).

However, it is _essential_ that the leftmost <path-identity> that is added
be the one known to the upstreams (case 1); otherwise, the MISMATCH
checking is not going to work. So any that are put there for purely case 2
purposes MUST be prepended first (i.e. to the right).

But the present USEPRO wording suggests the exact opposite of that, and
will therefore lead to MISMATCH problems. So I think what you need is a
single step something like:

   4.  The agent MUST then prepend one or more <path-identity>s
       identifying itself (as set out in section 3.2) to the Path header
       field content, following each <path-identity> so added with either
       "!!" or "!" {OK, that needs Russ' revised '!'  wording, which I
       don't have in front of me right now}. However, the last (leftmost)
       such <path-identity> so appended MUST be one that is expected by
       the destination site when it in turn comes to apply Step 3 above.

{That will also require some shuffling around of prepended "!"s in Steps 1, 2
and 3 to ensure that the right number of "!"s get prepended in the right
places.}

That could be followed by the present

       This is permitted for agents that have multiple <path-identity>s
       (such as during a transition from one to another).

although that may already be clear enough from 3.2.

And please, can we have a definition of "expected" as referring to the
"verified source" from which the article had been received.

-- 
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: Tue, 16 Jan 2007 20:18:07 +0100

>    update the Path header field ....

An s/MAY/SHOULD/ in the -07 text might also do what you want.  If that's
not your intention I fail to see the difference from the MAY.

> it is _essential_ that the leftmost <path-identity> that is added
> checking is not going to work.

Yes.

> the present USEPRO wording suggests the exact opposite of that

Yes, that could need a note, or a similar minor tweak.  It's to some
degree obvious.  In your example there's no unique way to get it right
for all peers.  Picking a legacy identity as leftmost path identity is
probably a bad idea (wrt simple MISMATCH checks).

>        However, the last (leftmost) such <path-identity> so appended
>        MUST be one that is expected by the destination site when it
>        in turn comes to apply Step 3 above.

Can that fly if different peers expect different leftmost identities ?
If not you can only say SHOULD.

Frank

---

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

>not your intention I fail to see the difference from the MAY.

The essential difference in what I am proposing is the replacement of "the
same news server" by "the same site", thus allowing more flexibility to
omit identities that are not serving any useful purpose. But no, I don't
waht to say you SHOULD omit them. It is just a mater of allowing some
discretion to the site.

>If not you can only say SHOULD.

That would be an unusual situation. Why should it happen? But in any case,
it is a matter for negotiation between the peers concerned. It might even
be necessary to add diferent identities to the Path according to which
peer you were relaying it to, which would be horribly messy.

But if MISMATCH problems are to be avoided, I think that MUST is needed,
and if ingenious site admins dream up bizarre schemes which still obey
that MUST, then they are welcome to do so.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 00:36:24 +0100

Charles Lindsey wrote:

  [multiple path identities]
>> I fail to see the difference from the MAY.
 
> The essential difference in what I am proposing is the replacement
> of "the same news server" by "the same site", thus allowing more 
> flexibility to omit identities that are not serving any useful purpose

Okay, I missed that, distracted by the removal of a MAY in your version.
The "same site" idea might make sense, I can't judge it.  Whenever Russ
talked about "slaved servers" all I can say that it sounds interesting,
and he obviously knows what this really means ... ;-)

 
> That would be an unusual situation. Why should it happen?

You example was about "upstream" vs. "downstream" peers.  These terms
aren't yet defined, one scenario could be that the "downstream" peers
are on the other side of a firewalll and see a non-public IP.  In that
case it would be more important for "!!" to match the path-identity on
the "upstream" side with a public IP.

> in any case, it is a matter for negotiation between the peers concerned

That doesn't sound like a MUST, or does it ?

> if MISMATCH problems are to be avoided, I think that MUST is needed,

If they can.  "Swap the order of your path identities depending on the
peer" could be tricky.  That's a question for folks who have actually
implemented such schemes or at least looked into sources - I didn't.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Jan 2007 20:08:17 GMT

>and he obviously knows what this really means ... ;-)

What I am suggesting is not necessarily related to 'slaved servers',
though it might well apply there.

>peer" could be tricky.

It would, which is a good reason why admins should avoid putting
themselves in a position where that might be needed. All I am saying is
that they MUST put in their leftmost <path-identity> something that the
downstream agent can readily use for MISMATCH checking. If they want to
make life unnecessarily complicated for themselves in order to achieve
that, then that is their problem :-( .

And note that MISMATCH checking does not necessarily have to be related to
the IP address from which the relayed article was received, It can just as
well be based on the SASL authentication identity that was used when the
relaying NNTP connection was set up in the first place.