On 7/16/22 6:02 AM, Miner wrote:
> I noticed you're abusing [skip] often. There was references on
> Message-ID.

I think the messages that you're referring to didn't make it to my news
server.

I now see only two messages from Ishmel on this thread.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> On 7/16/22 6:02 AM, Miner wrote:
> > I noticed you're abusing [skip] often. There was references on
> > Message-ID.
>
> I think the messages that you're referring to didn't make it to my news
> server.
>
> I now see only two messages from Ishmel on this thread.
>

PMFJI. It's the same on E-S.

[relurk]

--
^Ï^ My pet rock Gordon just is.

~ Slava Ukraini ~

Russ Allbery wrote:

> You've got a point that the answer to that question expressed
> rather more certainty about getting a feed than may be
> warranted. I've reworded it a bit:
>
> for news administrators to have different criteria for
> peering (specific hierarchies, geographic or network
> proximity, spam filtering, no binaries, binaries, specific
> network protocols; the variation is endless), so finding

Several criteria are missing: reveal a information (what
exactly?), promoting the commercial interests of a third party,
having an external IP address, buying a domain, setting up
additional software.

String "the variation is endless" need to be updated with
"including the insane".

--
Miner

Miner <invalid@invalid.invalid> writes:
> Russ Allbery wrote:

>> You've got a point that the answer to that question expressed
>> rather more certainty about getting a feed than may be
>> warranted. I've reworded it a bit:
>>
>> for news administrators to have different criteria for
>> peering (specific hierarchies, geographic or network
>> proximity, spam filtering, no binaries, binaries, specific
>> network protocols; the variation is endless), so finding
>
> Several criteria are missing: reveal a information (what
> exactly?), promoting the commercial interests of a third party,
> having an external IP address, buying a domain, setting up
> additional software.

I would add “don’t be high-maintenance” as a general rule.

--
https://www.greenend.org.uk/rjk/

Miner schrieb:

> Just the facts.
> 1. News.admin.peering FAQ does not exist or hasn't been posted in
> the past few months.

No problem. Create it, post it. Otherwise you'll cause a waste of time,
and your inaction could be regarded as disinformation. We wouldn't want
that, would we?

-thh

On Fri, 15 Jul 2022 12:04:20 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 7/15/22 5:23 AM, Matija Nalis wrote:
>> I agree. Also, many things are implied by common logic and it would
>> be waste of everybody's time to include.
>
> 1st "common logic" is both regionally and chronologically dependent. It
> used to be common logic that smoking on a plane was okay.

And it was okay back then, wasn't it? That is exactly my point.
Things change, and things are often different in different regions.

For example, back when I was still admining public news servers, e-mail was not
required for peering in this region. Instead, XMPP and IRC were often
alternatives, even preferred by some. At least in my region...

> 2nd given the above, I find it's better to clarify things, even if
> believed to be common logic, so that people that are in a different
> region or different time (years later) have a frame of reference from
> the document that no longer exists for them.

Sure. It would probably need to cover lots of regions (and maybe historical
information, as it would need to be kept up-to-date), or would need to be very
open-ended/vague, lest it possibly lead to more confusion than it solves.
It is likely much harder than it looks on first sight.

Even things like language and peering places used differ wildly.
(e.g. do high percentage of Chinese newsadmins choose to find peers by posting
in English on news.admin.peering? Neither did most newsadmins in .hr;
yet peer they did - and some still do. Not all news servers even carry Big8!)

While some peering requests on news.admin.peering and elsewhere might gain
much more traction because they have made popular choices, this does not
_per se_ invalidate the other (more quirky) peering requests.

There were several issues raised, none of which IMHO have *definite* answer,
only some *recommendations* iff one wants to get more exposure (which is not to
be taken as implied, either [1]):

- "you need to buy a domain / have a working domain name to peer" (not true at all)

- "you need a working e-mail / MTA to peer" (not true, see above about my experiences
with other communication methods, as well as recent threads in news.admin.peering,
I still prefer XMPP to this day for things I care about - it is faster, and things
tend to actually reach intended recipient much more reliably than e-mail, which is
IME getting borderline useless these days due to spam and antispam issues).
It might impact your access to moderated groups, though (in addition to
getting less potential peers)

- "you need public IP address to peer" (not true; e.g. I started my peerings via
UUCP on private SLIP dial-up links back in the day. In fact, *lack* of always-on
internet connectivity and public IP addresses was main factor of interest in
setting up my own news server initially. It would still work today, provided you
find interested peers). There was also interesting discussion of privacy TCP/IP
layers lately in news.admin.peering, for example.

- "you must not be commercial news server" (not true either; although it would
*also reduce* the size of group of peers that are interested in your request - just
like the other *suggestions* mentioned above)

- "your peering request must have all of the following information (XXXXX, email, ...)
and be posted at news.admin.peering" (not true either, see above)

It would be less problematic if all of "need" / "must" / "should" etc. in such
potential FAQ were replaced with "In order to enhance your chances of finding
many peers, you might want to consider" (or similar) phrase.

> Perhaps some of these things don't need to be /in/ the INN FAQ itself.
> But I do think it would be good to have a pointer in the INN FAQ
> referencing some of these things. E.g.
>
> Q: What do I do now that my INN server is up and running?
> A: See the Peering FAQ document for more details.

I agree it should be _kept out_ of *INN* FAQ, and have said as much.

Note that "Peering FAQ" would likely only offer help on News peering; while the
OP seemed to me to have much wider range of general computing issues.
That's why I originally suggested:

>> There is absolutely no need to specify those in *INN* FAQ. Perhaps is some "computing 101" FAQ...

[1] e.g. only peering proposal I considered lately was quite esoteric (which is
why it piqued my interest, in fact).

--
Opinions above are GNU-copylefted.

On Fri, 15 Jul 2022 12:15:35 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 7/15/22 12:02 AM, Miner wrote:
>> Before asking for a peering:
>> * administrator must register the domain and probably should pay for it
>
> I can't support "/must/ register a domain name". I see zero problems
> with using a hostname in an existing domain name.

.... that could probably be simplified as "FQDN", but...

> I can support "/must/ use a /registered/ domain name".

.... why do you see that as a "MUST", though?
Which part of news peering *cannot possibly work* without valid public domain name?

It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD" (or even "MAY", depending).

> I agree that using an email address in the same (parent) domain is
> preferred. But I don't think that preference even qualifies as a SHOULD.

Why even that? It would be at best "MAY", if it even warrants a mention (it
does not, IMHO - it is pointless policy minutia, like requiring that email
addresses must always be in form "firstname.lastname@company.tld" or some such)

--
Opinions above are GNU-copylefted.

On 7/18/22 4:38 PM, Matija Nalis wrote:
> And it was okay back then, wasn't it? That is exactly my point.
> Things change, and things are often different in different regions.

I feel like we're talking past each other.

I'm saying that things should be documented, even if they are common
logic to some people. Because they may not be common logic to everyone
now or at some point in the future. Hence the value in documenting what
is common logic so that there is no doubt in another location or another
time.

Said another way, simply writing the common logic removes any ambiguity.

> For example, back when I was still admining public news servers, e-mail
> was not required for peering in this region. Instead, XMPP and IRC were
> often alternatives, even preferred by some. At least in my region...

That sounds like an example of a good thing to document that was
probably common knowledge to you / those around you but not as common to
others.

> Sure. It would probably need to cover lots of regions (and maybe
> historical information, as it would need to be kept up-to-date),
> or would need to be very open-ended/vague, lest it possibly lead
> to more confusion than it solves. It is likely much harder than it
> looks on first sight.

I think we're talking about two different things. I'm talking about a
subset of what I think you are talking about. I'm specifically talking
about people documenting what they are doing / using / expecting in a
way that will remove ambiguity for others later.

A corollary: I've heard / read multiple times / places that scientists
are unable to build rocket engines using plans from the '70s & '80s,
despite having full blue prints, /because/ the knowledge of /how/ to do
some things was lost because it wasn't documented. Either for
intellectual property / trade secret reasons or simply because everybody
thought it was common knowledge, thus they didn't need to document /how/
they did things. Instead they only documented /what/ they did.

I hope that makes sense.

> Even things like language and peering places used differ wildly.

Sure. Hence why providing some background on what some consider to be
common knowledge will help those that are translating the languages and
having to deduce things.

> (e.g. do high percentage of Chinese newsadmins choose to find peers by
> posting in English on news.admin.peering? Neither did most newsadmins
> in .hr; yet peer they did - and some still do. Not all news servers
> even carry Big8!)
>
> While some peering requests on news.admin.peering and elsewhere might
> gain much more traction because they have made popular choices, this
> does not _per se_ invalidate the other (more quirky) peering requests.

Agreed.

> It would be less problematic if all of "need" / "must" / "should"
> etc. in such potential FAQ were replaced with "In order to enhance
> your chances of finding many peers, you might want to consider"
> (or similar) phrase.

I believe that most of the SHOULD / MUST / et al. are borrowing from RFC
standards and meanings therein.

--
Grant. . . .
unix || die

On 7/18/22 4:57 PM, Matija Nalis wrote:
> ... that could probably be simplified as "FQDN", but...

My concern is that FQDNs can be locally / privately resolved.

I take the spirit of the requirement to be that whatever name is used
can be externally / publicly resolved.

> ... why do you see that as a "MUST", though?

I was restating the previous comment with a modification. E.g.

s#register a#use a /registered/#

> Which part of news peering *cannot possibly work* without valid public
> domain name?

I agree that it can. I was seeking what I could support, even if I
thought it was a bit of an over reach.

> It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD"
> (or even "MAY", depending).

I like should better than must. But I was focusing on a different part
of the statement.

> Why even that? It would be at best "MAY", if it even warrants
> a mention

How about refactoring / simplifying from email to an out of band
communications method that both peers are happy with?

--
Grant. . . .
unix || die

On Mon, 18 Jul 2022 17:38:15 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 7/18/22 4:38 PM, Matija Nalis wrote:
>> Even things like language and peering places used differ wildly.
>
> Sure. Hence why providing some background on what some consider to be
> common knowledge will help those that are translating the languages and
> having to deduce things.

Yes, there I agree with you.
Documenting current (and even historical) state is good.

I was more targeting the angle that *extra care* should be taken so that
resulting document does not end up being US/EU-English-region-centric
(or even more narrow: Big8-centric).

Which it quite probable result, if it would be created by collecting input from
Big-8 news.* groups only; even if some of cross-polination of newsadmins from few
different countries who roam here (mostly western EU and US, it looks to me).
Thus my comment about it being hard to document things correctly without
introducing such strong bias.

>> It would be less problematic if all of "need" / "must" / "should"
>> etc. in such potential FAQ were replaced with "In order to enhance
>> your chances of finding many peers, you might want to consider"
>> (or similar) phrase.

Ah, I was refering to common conversentional style as was used my own bullet
points that were above that paragraph and might end up in such document
(e.g. "you need public IP address to peer" etc.)

> I believe that most of the SHOULD / MUST / et al. are borrowing from RFC
> standards and meanings therein.

Agreed - and they should be in all uppercase then. I doubt there would be much
(or any) of MUST, mostly "MAY" and perhaps a few "SHOULD". "NEED" is not BCP14,
but is AFAICT common in conversational style used in such documents.

>> Which part of news peering *cannot possibly work* without valid public
>> domain name?
>> It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD"
>> (or even "MAY", depending).
>
>I like should better than must. But I was focusing on a different part
>of the statement.

Oh, OK then. I was confused by MUST part, as it clearly is not a "MUST".

>> Why even that? It would be at best "MAY", if it even warrants a mention
>
>How about refactoring / simplifying from email to an out of band
>communications method that both peers are happy with?

Yes, that sound like a good idea to me. Few popular examples of such OOB might
then be mentioned in parenthesis ("e.g. email or various instant messaging") to
give some context to the user, without sounding too prescriptive.

--
Opinions above are GNU-copylefted.

Thomas Hochstein wrote:

> Miner schrieb:
>
> > Just the facts.
> > 1. News.admin.peering FAQ does not exist or hasn't been
> > posted in the past few months.
>
> No problem. Create it, post it.

rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
rejecting[*] <dcomm.20220719225404.1069@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
rejecting[*] <desd.20220719225404.1070@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
rejecting[*] <dcomm.20220719225404.1071@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
rejecting[*] <dcomm.20220719225404.1072@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
--
Miner

Am 20.07.2022 um 11:20 schrieb Miner:
> Thomas Hochstein wrote:
>
>> Miner schrieb:
>>
>>> Just the facts.
>>> 1. News.admin.peering FAQ does not exist or hasn't been
>>> posted in the past few months.
>>
>> No problem. Create it, post it.
>
> rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
> rejecting[*] <dcomm.20220719225404.1069@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
> rejecting[*] <desd.20220719225404.1070@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
> rejecting[*] <dcomm.20220719225404.1071@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
> rejecting[*] <dcomm.20220719225404.1072@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.

KI seems to made great progress the last years. :)

With best regards
MM

--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Miner schrieb:

> Thomas Hochstein wrote:
>> Miner schrieb:
>>> 1. News.admin.peering FAQ does not exist or hasn't been
>>> posted in the past few months.
>>
>> No problem. Create it, post it.
>
> rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.

Yep, that's what I thought.

The author of the INN 2.x FAQ Russ Allbery continues to spread
disinformation. I express my contempt for all organizers of
disinformation.

Miner wrote:

> Russ Allbery wrote:
>
> > You've got a point that the answer to that question expressed
> > rather more certainty about getting a feed than may be
> > warranted. I've reworded it a bit:
> >
> > for news administrators to have different criteria for
> > peering (specific hierarchies, geographic or network
> > proximity, spam filtering, no binaries, binaries, specific
> > network protocols; the variation is endless), so finding
>
> Several criteria are missing: reveal a information (what
> exactly?), promoting the commercial interests of a third party,
> having an external IP address, buying a domain, setting up
> additional software.
>
> String "the variation is endless" need to be updated with
> "including the insane".

--
Miner

Miner <invalid@invalid.invalid> writes:

> The author of the INN 2.x FAQ Russ Allbery continues to spread
> disinformation. I express my contempt for all organizers of
> disinformation.

In case anyone was wondering, this followed apparently the same person
trying to harass me in direct email about not wording the FAQ answer in
the way that they'd prefer. I'm not really sure what they expected the
outcome to be.

This is not the weirdest hill that I've seen someone try to die on, but it
certainly has flashback early 2000s Usenet kook energy.

Anyway, go write your own FAQ if you don't like this one. I'm not going
to change it further for your weird obsession.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery wrote:

> In case anyone was wondering, this followed apparently the same person
> trying to harass me in direct email about not wording the FAQ answer in
> the way that they'd prefer.

Who would have thought that?

> Anyway, go write your own FAQ if you don't like this one.

I fear that makes you "Insolent or mentally retarded." ...

-thh

Thomas Hochstein <thh@thh.name> wrote:
> Russ Allbery wrote:
>
>> In case anyone was wondering, this followed apparently the same person
>> trying to harass me in direct email about not wording the FAQ answer in
>> the way that they'd prefer.
>
> Who would have thought that?
>
>> Anyway, go write your own FAQ if you don't like this one.
>
> I fear that makes you "Insolent or mentally retarded." ...
>
> -thh
I thought the faq was good so yeah.
go pound sand.
Don't let those people get you down.