[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



In <87abz8enti.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:

>Charles Lindsey <chl@xxxxxxxxxxxxxxxx> writes:

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

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

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


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

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.

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

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

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

-- 
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: chl@xxxxxxxxxxxxxxxx      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