Subject: Re: #1415 USEPRO 3.2.1 - Number of path entries per site

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 20 Feb 2007 16:17:16 GMT

In <[email-masked]> Russ Allbery <rra@xxxxxxxxxxxx> writes:

>Charles Lindsey <chl@xxxxxxxxxxxxxxxx> writes:

>>    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 ....

>I don't think this is necessary.  There are two possibilities: the site is
>using the Netnews protocol within the site or not.  If it is, it needs to
>fill out the Path header field for the same reasons that any other Netnews
>servers need to.

Not necessarily, if it leads to a long string of identities for machines
on the one site which takes up much Path space without assisting in
preventing loops or enabling the detection of anomalies. I understood that
the WG had agreed to that principle, which is why it was in Usepro-06. But
it is not a huge deal if the WG prefers otherwise. So we need other
opinions (so far I count just +1 from me and -1 from you).

>Nothing in the document should be requiring the components of a news
>server be running on a single system.

Agreed. Your wording ensured at least that. My wording went a little
further.

>> 2. The present Steps 4 and 5 of 3.2.1 are just plain wrong.

>You're reading more into steps 4 and 5 than is actually there.  :) ...

>   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.

The wording seems (to me, and hence possibly to others) to be
distinguishing between
   "its own <path-identity>"      {i.e. the one, true identity}, and
   "additional <path-identity>s"  {i.e. less important ones}

>Nothing *requires* it, either, so we should look at that.

OK, I think we are agreed that the wording needs to change.

>> Note that such "extra" identities are only put there because that site
>> does not want to receive articles with any of those identities already
>> present from its upstreams, and for historical reasons it needed more
>> than one identity for that purpose.

>That's one possible reason.  Another reason for appending such extra
>identities is because an ISP with independent news servers wants to add a
>common identity to the Path for statistical purposes. ...

Good point.

>> My suggested fix was to replace both those steps by

>>    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, separated by either "!!" or "!". 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.

>This language requires mind reading; you may have no idea what other sites
>expect.

Presuably they "expect" whatever was negotiated at the time the peering
arrangement was set up (which may, of course, amount to more than one
IP-address/domain-name/whatever).

>  It's also hard to satisfy this MUST during a transition where
>some peers may expect one ordering and others may be expecting a different
>one.

I think all sites will currently be assuming (insofar as they bother to
assume anything) that the leftmost identity in the Path as received is the
place the article claims to have come from.

>    If the agent prepends additional <path-identity>s, the leftmost
>    <path-identity> SHOULD be the one advertised to other news servers as
>    the expected <path-identity> for this agent.

Yes, something like that conveys the right idea.

>> Note. There is some confusion as to whether a "!" belongs to the
>> identity/diagnostic to its left, or to its right,...

>The present wording doesn't consider "!" to belong to any identity and
>instead treats it as a delimiter, so it's not following either of those
>conventions.  The precise steps seemed to read more clearly to me doing it
>that way.

I found that I had to read the wording *very* carefully, and more than
once, to convince myself that you had got your delimiters in exactly the
right places (as indeed you had).

>> So some further tidying up of the whole wording might be a good idea.

>Please do suggest other wording if you think there's a clearer way to
>explain it.

OK. I shall put my deputy editor's hat on and see what I can come up with.

>> And, for my final niggle, please can we have a definition of the term
>> "expected" which is used at several places in 3.2.1.

>I don't think we gain much from this.  This checking is not particularly
>formal, so I think more specification implies more rigorous verification
>than we're actually specifying.  "Expected" feels to me like it captures
>about the level of checking and formality we're getting.  The definition
>of the term is the standard English definition of the word.

I think my main concern here is to make it clear that relaying agents
have an obligation to know where articles have come from and to insert
diagnostics accordingly. I think it is now agreed that this is at a SHOULD
level.

-- 
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: Russ Allbery <[email-masked]>
Date: Tue, 20 Feb 2007 09:33:29 -0800

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <rra@xxxxxxxxxxxx> writes:

>> I don't think this is necessary.  There are two possibilities: the site
>> is using the Netnews protocol within the site or not.  If it is, it
>> needs to fill out the Path header field for the same reasons that any
>> other Netnews servers need to.

> preventing loops or enabling the detection of anomalies.

If having accurate Path entries doesn't assist in preventing loops or
enabling the detection of anomalies, wouldn't that be the definition of
"not using the Netnews protocol"?  Since when using the Netnews protocol,
that's exactly what the Path header does do.

> I understood that the WG had agreed to that principle, which is why it
> was in Usepro-06. But it is not a huge deal if the WG prefers
> otherwise. So we need other opinions (so far I count just +1 from me and
> -1 from you).

I agree that other opinions would be useful.

> OK, I think we are agreed that the wording needs to change.

Well, that's stronger than my feeling about it, but I'm not adverse to the
addition of some statement about this.

> IP-address/domain-name/whatever).

Right, but let's just say that rather than leaving it as a presumption.
In other words, let's make the language entirely about what that site
does, rather than about what other sites will do.

>> It's also hard to satisfy this MUST during a transition where some
>> peers may expect one ordering and others may be expecting a different
>> one.

> assume anything) that the leftmost identity in the Path as received is
> the place the article claims to have come from.

I think you missed my point, since as near as I can tell your sentence
isn't related to my sentence.  So let me expand a little.

Suppose that my current Path identity is fooco.com.  fooco just got bought
out by bigbar.com and for various corporate political reasons is being
absorbed.  So my news server and everything else is switching from being
in fooco.com to being in foo.bigbar.com.

If I'm in the midst of such a transition and I've informed some of my
peers of the new Path identity and haven't been able to reach others,
there's no way for me to satisfy a MUST here without generating different
Path headers for different peers.  Some peers will be expecting one thing
and some will be expecting another.

>> conventions.  The precise steps seemed to read more clearly to me doing
>> it that way.

> right places (as indeed you had).

That's probably the case.  However, that reading isn't the one that I'm
the most concerned with, since it's only us in this working group who have
to do that careful check.  I'm more concerned with an implementor blindly
following the text ending up with the correct result without stumbling
over or missing some delimiter.

I intentionally sacrificed minor difficulty of verifying the correctness
of the text for what felt to me like more straightforward and harder to
misread text from an implementor perspective.

Of course, something that works for either is the best.

>> I don't think we gain much from this.  This checking is not
>> particularly formal, so I think more specification implies more
>> rigorous verification than we're actually specifying.  "Expected" feels
>> to me like it captures about the level of checking and formality we're
>> getting.  The definition of the term is the standard English definition
>> of the word.

> diagnostics accordingly. I think it is now agreed that this is at a
> SHOULD level.

I'm not adverse to sticking something in, although I'm not really sure
what to say.

To give others an idea of how this generally goes, I'd estimate (back of
the envelope guess) that at around half of my peers are using a Path
identity other than the FQDN of the news server from which I get the
article, but 90% of my peers told me their Path identity when
communicating with me about peering.  So in practice, the best way (and
probably the only feasible way) to establish these Path identities is
through out-of-band communication.  If you try to guess them based on
FQDN, you'll get it wrong about half the time.

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

---

From: Richard Clayton <[email-masked]>
Date: Tue, 20 Feb 2007 17:41:02 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>preventing loops or enabling the detection of anomalies. 

Russ is, I believe, saying it prevents loops within the "site" if
they're using NNTP in an off-the-shelf way.

Preventing loops within the site seems like a good idea to me, and so it
will seem to the newsadmins, who would ignore instructions not to add
all relevant names :)  Essentially it's not a site at all, just
ownership of multiple machines.

However, it may also help when the site has s1.example.com and
s2.example.com for peering purposes. Adding s2.example.com into the Path
header field, even it was only handled by the s1 machine, ought to
prevent it being offered back by a peer that only talks to s2.

It would be better to add a generic site-wide name (example.com) and
ensure that peers understood that s2 was also "example.com" and
shouldn't be offered articles with that generic identity as well as a
specific one, but it seems to me that's merely a matter of what is
neater, not an interop issue

- -- 
richard                                              Richard Clayton

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 20 Feb 2007 09:48:37 -0800

> neater, not an interop issue

Note that this is sometimes the case and sometimes isn't.  For example, I
have two external relaying agents, and I want each to receive articles
even if they'd been processed by the other since it gives me more
redundancy.  If something goes wrong between the two relaying agents, this
gives me more assurance that I won't miss articles.

In nearly every case, the other relaying agent will immediately decline
the message anyway (since it will have already gotten it from the first
relaying agent), so the additional work required for my peers is minimal
and since the two relaying agents don't feed the same peers, it would
rarely even be noticable.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Feb 2007 17:07:14 GMT

>they're using NNTP in an off-the-shelf way.

OK, we are talking about a site which passes articles through a succession
of machines:
 s3.example.com!s2.example.com!s1.example.com!...

If there is some risk of looping inside that site, then a newsmaster would
be stupid to omit s2.example.com from the list. But that is really his own
(internal) problem. My point was that s2.example.com was unlikely to be of
interest for preventing loops in the rest of the net, and hence that site
should be allowed to omit it (MAY) if it was not otherwise useful for its
own purposes.

>prevent it being offered back by a peer that only talks to s2.

Sure. Newsmasters need to be aware of all such matters, and to set their
Paths accordingly.

>ensure that peers understood that s2 was also "example.com" 

And that also may be useful, again depending on the particular
circumstances. Your 'demon' case was a good example of that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Feb 2007 17:48:21 GMT

>does, rather than about what other sites will do.

Yes, but what a site does is heavily constrained by what it has agreed
with its peers.

>and some will be expecting another.

If you start putting foo.bigbar.com as your leftmost <path-identity> (and
if you don't go to the complication of generating different Paths for
different peers), then the peers which haven't been informed yet are going
to start putting !.MISMATCH.fooco.com! to the left of your Path, and there
is nothing you can do to stop them without speaking to them. I think that
is inevitable.

Obviously you try to avoid getting into that situation, but if your peers
just aren't interested in reconfiguring what they expect, then either you
live with it, or you stop feeding them.

>Of course, something that works for either is the best.

OK, I shall try and suggest a rewording as I said, but not this week :-( .

---

From: Russ Allbery <[email-masked]>
Date: Fri, 23 Feb 2007 21:47:50 -0800

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> there's no way for me to satisfy a MUST here without generating
>> different Path headers for different peers.  Some peers will be
>> expecting one thing and some will be expecting another.

> If you start putting foo.bigbar.com as your leftmost <path-identity>
> (and if you don't go to the complication of generating different Paths
> for different peers), then the peers which haven't been informed yet are
> going to start putting !.MISMATCH.fooco.com! to the left of your Path,
> and there is nothing you can do to stop them without speaking to them. I
> think that is inevitable.

Right, which is why doing so can't be a violation of a MUST.  I think
we're actually agreeing here (unless you feel that using the identity that
you advertised to your peer should still be MUST instead of SHOULD).