Subject: Re: New USEPRO path-identity text (Hello, Chair?)

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 3 Aug 2005 10:43:55 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> What is you position on MUST vs SHOULD for providing at least
>> one? Richard seems to be preferring SHOULD, and we all know
>> that MUST sends John into apoplexy :-(

>We can justify a MUST about news@ / usenet@ because that's how
>it always was, and NetNews is one of these very old systems
>where "interoperability problems" (aka errors) have to be fixed
>manually and are reported by mail (or phone).

Though I am not sure I really want MUST for that case.

>For the mail-complaints-to better avoid 2119 keywords, and as
>long as Scott doesn't catch you there is still the lower case
>"must" or similar words.  Actually I think you can omit abuse@,
>those who don't use mail-complaints-to (or its x-predecessor)
>will also ignore any "MUST abuse@".

OK, I think I have now heard enough to propose new text. But note that
there are still some questions at the end which need to be decided.

2.3.  Identification of news-servers

[new version]

   In order to record the passage of articles through the network, and
   to enable their administrators to be contacted, news-servers need to
   identify themselves by means of a <path-identity> (F-3.1.6), which
   can appear in Path, Injection-Info and Xref header fields. Whatever
   <path-identity> is used in the Path header field SHOULD be used also
   in any Injection-Info header field (and it would be normal to use it
   in any Xref header field also).

   <Path-identity>s can take the following forms (in decreasing order of
   suitability):

   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record identifying that news-server, or with an "MX" record
      through which its administrators can be contacted; alternatively
      an equivalent "CNAME".

   2. An encoding of the public [RFC 1918] IP address - <IPv4address> or
      <IPv6address> [RFC 3986] - of that news-server. This option SHOULD
      NOT be used if an FQDN for that server is available (however, such
      IP addresses are perfectly suitable for purely diagnostic
      identities [reference needed to later section]).

   3. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. The news-server administrator is responsible for
      choosing an appropriate name (and will bear the consequences of an
      inappropriate choice). This option SHOULD NOT be used unless the
      earlier options are unavailable (e.g. because the server in
      question is not connected to the Internet), or unless it is of
      longstanding usage and cessation would be unduly disruptive[1], or
      unless one of the earlier options is provided as well.

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefore be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

   There are two circumstances when news-server administrators may need
   to be contacted by email:

   1. (injecting agents only)
      For sending complaints concerning the behavior of the poster of an
      article, the correct address is
      o If there is an Injection-Info header field with a "mail-
        complaints-to" <parameter>, then the address in that
        <parameter>; otherwise
      o "abuse@" followed by the <path-identity> in that Injection-Info
        field; or, in the absence of any Injection-Info field, the
        <path-identity> inserted by that agent in the Path header field
        (which, for an injecting agent, should be the one followed by
        the keyword "POSTED"). Evidently, that <path-identity> needs to
        be an FQDN for this to work.
      Injecting agent administrators SHOULD[2,3] ensure that a working
      email address is obtained by this process.

   2. (all agents)
      For reporting technical problems concerning the operation of a
      news-server, the correct address is either "news@" or "usenet@"
      followed by a <path-identity> obtained from an Injection-Info or
      Path header field as above.  Administrators SHOULD[4] ensure that
      a working email address is obtained from at least one of the<path-
      identity>s inserted by themselves[5].

        NOTE: The mechanisms set out above are broadly compatible with
        the provisions of [RFC 2142].
[Notes]

   [1]  Now that we are agreed to allow a single server to insert
        several <path-identity>s to identify itself, do we really still
        need to mention that "unduly disruprive business"? Richard?

   [2]  That used to be "MUST", but recently expressed opinions appear
        to favour "SHOULD".

   [3]  Do we want to relax the need for an abuse address at small
        private servers, or even at all servers not offering a public
        service?

   [4}  That used to be "ideally should" (which is weaker that RFC 2142
        - which was "must"). Do we want it as strong as "SHOULD"?
        Obviously, it will not work if all you have is a UUCP-style
        name.

   [5]  If the server inserts several identities (e.g. a chain of hosts
        in its farm) it would suffice for one working MX record
        (hopefully an obvious one) to be in the list. Or do we really
        want to insist that it creates an MX record to match every
        individual host?

   [6]  That still leaves open the precise syntax of <path-identity> and
        the like, and whether we are going to have words like ".SEEN" to
        indicate diagnostice ones.  However, that issue should be
        discussed under ticket #1047.

-- 
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, 3 Aug 2005 13:42:48 +0100

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

>   in any Xref header field also).

This still mixes two very different things and it would be better to
separate them far more clearly:

Make this intro just say:

    In order to record the passage of articles through the network,
    news-servers need to identify themselves by means of a <path-
    identity> (F-3.1.6), which appears in the Path header field.

and then the next bit is OK, by me....

>      identities [reference needed to later section]).

... up to here, and then....

>      unless one of the earlier options is provided as well.

... and then there's still this vague threat which does not assist
anyone and encouragement for multiple entries (which I accept that some
systems do, but I don't see why it should be made to sound normal, it
just ought not to be forbidden):

so rewrite 3 as:

    Some other name believed to be unique and registered at least with
    all other news-servers sending articles directly to the given one.
    This option SHOULD NOT be used unless the earlier options are
    unavailable (e.g. because the server in question is not connected to
    the Internet), or unless it is of longstanding usage and cessation
    would be unduly disruptive.

>        solely from four (or less) hexadecimal digits.

THEN you should discuss the Xref header field along these lines (I've
recently been reading the Diablo source and it is clear from comments
there (and the effort they go to) that there are some news reading
programs that barf when the path identity in the Xref fails to match up
properly with the Path (and with the name of the server).

    The Xref header field is used to keep used to keep track of the
    <article-locator>s of crossposted articles so that reading agents
    serviced by a particular serving agent can mark such articles as
    read. When articles are being passed to a reading agent the <server-
    name> in this header field SHOULD match the left-most <path-
    identity> in the Path header field.

THEN you can move on to the stuff about contacting people. Since it
doesn't seem to harm the text much to put off saying email until it is
unavoidable I have done that in my suggested text. If there is any
consensus for other means of contact then it will make it easier to edit

>   to be contacted by email:

    There are circumstances when news-server administrators may need to
    be contacted. The optional Injection-Info header field MAY be used
    to provide specific contact information. If it is present then the
    <path-identity> within it SHOULD match the <path-identity> added to
    the Path header field.

    The following algorithm SHOULD yield a valid contact address.

>      article, the correct address is

recast more vaguely (and avoiding the "correct" word) as:

  1. (injecting agents only)
    For messages relating to the posting of a particular article, the

>        complaints-to" <parameter>, then the address in that

this small para OK by me

>        be an FQDN for this to work.

this one is not, needs to say "email", so rewrite as

  o an email address constructed as "abuse@" followed by the <path-
    identity> in the Injection-Info field; or, in the absence of any
    Injection-Info header field, the <path-identity> inserted by that
    agent in the Path header field (which, for an injecting agent, is
    the first one, reading from the left, to be followed by the keyword
    "POSTED").

>      identity>s inserted by themselves[5].

rewrite [see below for more about this paragraph] as

  2. (all agents)
    For reporting technical problems concerning the operation of a news-
    server, the address to be used is an email address constructed as
    either "news@" or "usenet@" followed by a <path-identity> obtained
    from an Injection-Info or Path header field as above.  

>        need to mention that "unduly disruprive business"? Richard?

yes, just because !demon! also adds another entity does not mean that
other long-standing users of UUCP names do the same

>        want to insist that it creates an MX record to match every

a) in the real world you don't need MX records to send email

b) I don't see how anyone could have anything sensible to report about
anything other than the left-most machine to appear in the path

c) we don't insist, it's a SHOULD, which means that adults can decide
that there are overriding reasons for failing to provide the email
addresses.

Personally, I'd still rather drop the whole of #2 in the algorithm (ie
ANY mention of news@ or usenet@ and leave RFC2142 to sink or swim by
itself without ANY comment here.  viz: we just write the text about how
to use Injection-Info information to build an abuse@ address and leave
it at that. Anyone with a problem with their peer is going to use the
sysadmin address established when the peering arrangement was set up;
and problems with machines further away are either non-urgent (low
volume) or it's hardly rocket-science to work out who to contact

>        discussed under ticket #1047.

Summary: (to assist the chair if no-one else)

Charles has taken on board the notion of saying how to use Injection-
Info and then leaving it to the admins to build it to be useable (rather
than having a lot of didactic stuff about how to build it). This elides
a number of contentious words -- albeit not yet all of them. I like this
approach and endorse it. My, necessarily, detailed suggestions above
address what still concerns me.

There's a further issue, that RFC2142 documents a scheme for using news@
and usenet@ that is of limited practical use in a world where almost
everyone operates behind an abuse@ address. Some complication in this
document is avoided by failing to say anything about this (it either
works or doesn't work today, and what we say will not change that or
make anything more obvious). Avoiding any mention here has the benefit
that any future revision to 2142 in this area can be done orthogonally
to this document

- -- 
richard                                              Richard Clayton

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

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 3 Aug 2005 20:00:37 -0400

On Fri July 29 2005 17:03, Frank Ellermann wrote:

> Forrest's 2119 quote is important:
> 
> | they must not be used to try to impose a particular method
> | on implementors where the method is not required for
> | interoperability.
> 

Inconsistent.  "mail (or phone)" means that "MUST about news@ / usenet@"
is "used to try to impose a particular method on implementors where the
method is not required for interoperability".  Phone use does not
require an email address.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 4 Aug 2005 13:14:07 GMT

>require an email address.

Hold on! Nobody has said you MUST send your complaint (whatever) by email
to that specified address. All it has ever said is that administrators
MUST provide that address, so that everybody has at least one known way to
contact them.

And that "MUST" was "SHOULD" when last seen, and will finally be whatever
comes out of Harald's poll.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 4 Aug 2005 12:22:58 GMT

>    identity> (F-3.1.6), which appears in the Path header field.

Since this is an introduction to what <path-identity>s are provided for,
it would be odd not to mention all of their uses. The question of whether
you use the same one in all headers could be indeed be addressed later on,
so I now have:

   In order to record the passage of articles through the network, and
   to facilitate contact with their administrators, news-servers need to
   identify themselves by means of a <path-identity> (F-3.1.6), which
   can appear in Path, Injection-Info and Xref header fields. Whatever
   <path-identity> is used in the Path header field SHOULD be used also
   in any Injection-Info header field (and it would be normal to use it
   in any Xref header field also).
[Maybe that last sentence moves elsewhere.]

Note the word "facilitate", which hopefully addresses some of your
concerns lower down.

>just ought not to be forbidden):

Yes, that is overly verbose and I knew it would need further discussion,
but I am being pulled in different directions by different people.

In particular, Bruce is upset that we provide no machanism to guarantee
the uniquness of these names (despite the fact that no mechanism is
possible, and the system is currently working fine without such a
mechanism). He demands that we admit to a "known technical omission".

Essentially, you ask me to omit the whole sentence about administrators'
responsibility and inappropriate choice. But that was there to draw
attention to the risk (as near as I wanted to get to "known technical
omission", though I doubt Bruce would accept it as such). I still think
that we need to point out this risk, and would welcome suggested wordings.
In the meantime, I have replaced it with a NOTE:

        NOTE: A news-server administrator who chooses a name which turns
        out not to be unique will have to bear the consequences.

>properly with the Path (and with the name of the server).

I find that rather bizarre. What harm arises, or what security hole is
opened, if the Xref header uses a different identity? Russ has already
said, in these threads, that it does not matter. And why should Diablo
(which is a server, not a reader AIUI) care about the incoming Xref, which
it is supposed to be discarding anyway? And why are reading agents even
looking at the Path?

>    read.

The place to say that is USEFOR, where it is in fact already said.

>    When articles are being passed to a reading agent the <server-

And the place to say that would be in "Duties of a Serving Agent", though
I would want to hear a lot more support before saying so.

>    <path-identity> within it SHOULD match the <path-identity> added to

I now have:

   There are various circumstances when news-server administrators may
   need to be contacted. To facilitate this, the following email
   addresses are provided:

However, I don't think it is wise to describe a "SHOULD" feature as
"optional". Yes, this may be a better place to say that the Injection-Info
identity address SHOULD match the Path one, but let us see what comes out
of the Xref business before changing it.

>    The following algorithm SHOULD yield a valid contact address.

That depends on whether the "abuse" and "news/usenset" are both going to
be "SHOULD". I wrote separate "SHOULD"s for the two cases so that we could
adjust them independently (Harald's poll will decide that). If they
finally turn out to be the same, then the wording can be simplified.

>recast more vaguely (and avoiding the "correct" word) as:

The first part of the sentence was copied verbatim from USEFOR. We need to
be consistent, so I don't want to change that unless USEFOR changes (and
the word "complaint" is firmly built into the name of the <parameter>
concerned). But I accept your

>  ........, the address to be used is:

>    the first one, reading from the left, to be followed by the keyword

I now have "an address consisting of ...". Likewise in the "all agents"
text further down. But it is already clear from the revised context that
is it email addresses that are meant.

And one cannot rely on the presence of "POSTED" since it is a new feature
of our standard (hence my parenthetic "which ... should be..."). Yes, if
there are two "POSTED"s it needs to be the leftmost, but that is rare and
I did not want to complicate what was only a parenthetic remark.

>other long-standing users of UUCP names do the same

But they probably SHOULD. And if we say they SHOULD, then there would be
no need for that longish "disruptive" sentence.

>a) in the real world you don't need MX records to send email

I don't think I implied anywhere that you did.

>anything other than the left-most machine to appear in the path

If one observes, from study of of many Paths, that some relaying site is
consistently munging articles, or duplicating them, or otherwise
interfering with propagation, then one would indeed need to contact them.

>that there are overriding reasons for failing to provide the email

I agree. But its a "MUST" (or "must") for all cases in RFC 2142, which is
why I want to weaken it.

>volume) or it's hardly rocket-science to work out who to contact

For sure, people will know who their peers are. The news/usenet addresses
are provided for non-peers. If RFC 2142 had been written in an
intelligible manner, it would have been fine. But it is too strong in some
places and too vague in others. "news/usenet" are comparable to "postmaster"
in email, and RFC 2821 saw fit to define it afresh (even as a MUST) rather
than rely on 2142.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 04 Aug 2005 17:14:12 -0400

> MUST provide that address, so that everybody has at least one known way to

Are you seriously making this argument?  Do you really understand RFC2119
"implementors" to include "everybody"?

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Aug 2005 14:05:11 GMT

>"implementors" to include "everybody"?

Eh? I understand "everybody" to include "implementors", and I expect
"everybody" to be able to find whatever usenet/news/abuse addresses we
finally agree to mention.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 08 Aug 2005 14:28:49 -0400

> finally agree to mention.

RFC2119:

     For example, they must not be used to try to impose a particular
     method on implementors where the method is not required for
     interoperability.

You said
     All it has ever said is that administrators MUST provide that
     address, so that everybody has at least one known way to contact them.

...which is in plain conflict with the RFC2119 statement.

How do you maintain they are not in conflict?

Is it because you mis-read that RFC2119 statement as a requirement to
disallow implementors imposing a particular method (of complaints) on
everybody?  (E.g. by saying "We only take web-form complaints, and
don't run SMTP here.")

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 9 Aug 2005 10:35:18 GMT

>...which is in plain conflict with the RFC2119 statement.

I see no conflict whatsoever. Implementors can provide lots of email
addresses and web forms as well for all I care. So saying that they
MUST/SHOULD/whatever include one particular address is not "imposing a
particular method".

>everybody?  (E.g. by saying "We only take web-form complaints, and

There are too many negations in your sentence for me to be able to
decipher any meaning in it.

But I see that RFC 2821 uses "MUST" in connection with the "postmaster@"
address. That certainly rules out "We only take web-form complaints", but
it does not outlaw web-form complaints as an additional mode of contact,
so it has not "imposed" any particular method. Moreover, there is no
interoperability issue attached to the provision of "postmaster@", though
there is certainly a potential for harm if it is absent.

So if you are claiming that the things I have suggested writing in our
draft are contrary to RFC 2119, then please exaplain how those words in
RFC 2821 are not contrary to RFC 2119.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Tue, 09 Aug 2005 08:44:26 -0400

> MUST/SHOULD/whatever include one particular address is not "imposing a

You are saying that RFC2119 sentence

     For example, they must not be used to try to
     impose a particular method on implementors
     where the method is not required for interoperability.

actually means

     For example, they must not be used to try to
     limit implementors to one particular method
     where the method is not required for interoperability.

That makes the RFC2119 sentence meaningless, so that interpretation
of RFC2119 is wrong.

I think WG participants mis-interpreting RFC2119 is a matter for
the Chair.  Either RFC2119 means what you say, or I am correct.
It can't be both.

Chair?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 09 Aug 2005 22:08:47 +0200

> Chair?

Somewhere in Paul's slides that's called "go to daddy
syndrome" (or similar).  Please don't do this.  Whatever
Alexey or Harald think about 2119, it has the same value
as Bruce's or Charles' interpretation.

Unless they declare "rough consensus" about a particular
USEFOR question of course.  But finding the one and only
way to read 2119 is not - USEFOR is not creating 2119bis.

UseNetizens incl. admins are not required to have Web
access.  Therefore it follows that all participants must
have a working e-mail address - and of course that's an
interoperability issue, it's the way how problems are
reported and hopefully fixed.

Ordinary users might get away with TLD .invalid in some
cases, but admins and moderators must offer a working
e-mail address, otherwise they have no business on this
planet, let alone in Usenet.
                               Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Tue, 09 Aug 2005 15:57:08 -0700

> reported and hopefully fixed.

I don't understand why this follows.

The way that problems are quite frequently reported and fixed is that
they're mentioned in a public forum and one of the peers of the site
having problems uses their knowledge of contacts at the offending site to
track down a solution.

I don't believe I have ever reported or fixed a Usenet problem by
prepending news@, usenet@, or abuse@ to a Path entry and mailing that
address.

> planet, let alone in Usenet.

If someone wants to arrange a peering relationship via the telephone, I
think that's their business.

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 10 Aug 2005 05:16:13 +0200

> Frank Ellermann <[email-masked]> writes:

[oops, I really posted it, for some time I thought that I've
 confused Re:Mail and Re:News again, unusual delay on my side]

> The way that problems are quite frequently reported and fixed
> is that they're mentioned in a public forum and one of the
> peers of the site having problems uses their knowledge of
> contacts at the offending site to track down a solution.

If there is a forum for such problems.  E.g. when clara.net
didn't get nanas for obscure reasons I asked in a local group
what's going on, and some time later it was fixed.

If there's a problem with hamburg.* bothering clara.net admins
with it would be less promising, I'd need some old paths from
more than one server, and then I'd try to guess where the real
problem might be, and contact the corresponding admin.

Generally I stay away from problems where I'd be forced to
interpret paths correctly.  But if it's about rogue cancels or
other cases of net abuse it might interest me.  Posting in say
de.admin.net-abuse.news is not the same as a mail to usenet@,
the former is often more or less qualified public whining.
 
> If someone wants to arrange a peering relationship via the
> telephone, I think that's their business.

Sure.  And if they offer no working address to report problems
the next entity in the path will be hold responsible.  At that
point I'd also consider to publish whatever-it-is in a relevant
group.  But first I'd try to settle it by mail.  Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Tue, 09 Aug 2005 20:34:51 -0700

> group.  But first I'd try to settle it by mail.  Bye, Frank

I think what you're saying above is supporting my point that being able to
reach any individual transit news administrator via e-mail isn't really
required.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 10 Aug 2005 15:39:01 GMT

>That makes the RFC2119 sentence meaningless, so that interpretation

I do not see how that sentence is "meaningless". It is indeed a reasonable
interpretation of the sentence actually written (and the sentence was only
an "example" anyway).

>the Chair.  Either RFC2119 means what you say, or I am correct.

RFC 2119 is so badly written that it might even be both :-( .