Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Nail -> Head <- Hammer

Well put ! I don’t know if it could have been put better than that.

-- 
J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 23, 2021, at 10:57, Emil Pfeffer  wrote:
> 
> On Tue, Mar 23, 2021 at 09:20:14AM -0500, Mike Hammett wrote:
>> "But why it should or shouldn't be clicked..."
>> Sorta like most man pages.
> 
> They both need prior knowledge to use. 
> We tend to simplify things in order to save time but then the new generation 
> comes
> in and thinks the simple things it's all there is and have no willingness to 
> go
> back in time and accumulate "useless" knowledge. It is useless because the 
> problems
> it fixes were already fixed but it is paramount in understanding whats behind 
> the 
> simple things. Knowledge can only be simplified so much and there's no 
> shortcut to
> accumulating it. (hence why most people will prefer to just use the tools)
> 
> The generational gap is not an issue it is how things need to be. The network
> engineering the younger generation deals with is not the same networking the 
> old
> generation deals with but built upon this old networks. This two generations 
> do
> not need the same knowledge and it is in each others best interest that they 
> stay
> separated. Although we would gladly help someone that is obviously putting in 
> the
> effort and is looking to learn we have not volunteered to be teachers and 
> some people
> need to understand that we prefer to keep it simple because we have no time 
> to waste.
> 
> It is easy to believe that the method you are using is the one but eventually
> the good ones will have to pass the test of time which mailling lists and a 
> plethora
> of the old tools successfully did. 
> --

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Andy Ringsmuth]

>>> I am not going to lament much, either. It is just how it goes. On the
>>> brighter side, there will also be a minority, who will come to email
>>> exactly because they will be aspiring power users. I think there will
>>> always be some aspiring power users, so it is not going to be only bad.
>> 
>> There will be, but they will keep dwindling.
> 
> Things may be coming to this but they do not have to. I understand
> that being a power user involves talking to computer with some kind of
> a language, as opposed to pointing with finger. One example is unix
> commands, where "ls /usr/bin/ /sbin /usr/sbin/ | wc -l" gives me well
> over four thousand "words". So the question is, if in a future there
> will be systems which allow "talking to computer with words", allowing
> to make complex descriptions of "what to do".
> 
> Talking to "siri" is not what I am thinking about, because just like
> "desktop metaphore", the "assistant metaphore" is trying to hide too
> much of underlying complexity to allow "power usage”.

Obligatory:

Scotty: Computer! Computer? 
[He's handed a mouse, and he speaks into it]
Scotty: Hello, computer. 
Dr. Nichols: Just use the keyboard. 
Scotty: Keyboard. How quaint. 


-Andy

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Martin Hannigan]

Agree. I’ve had it filtered to a casual folder for 5 years now. I
appreciate the banter. Abilities to sort and shred would be great.

While I miss mail, I’m OK using browser code if it can make nanog-l more
relevant.

$0.02 only




On Thu, Mar 18, 2021 at 18:31 Matthew Petach  wrote:

>
> On Thu, Mar 18, 2021 at 10:37 AM Tom Beecher  wrote:
>
>> CC back to the mailing list for visibility, since I ate the CC list.
>>
>> On Thu, Mar 18, 2021 at 1:31 PM Tom Beecher  wrote:
>>
>>> Rod-
>>>
>>> Please refer to the usage guidelines found here.
>>> https://nanog.org/resources/usage-guidelines/
>>>
>>> 14. Posts that encourage or facilitate an agreement about the following
 subjects are inappropriate: prices, discounts, or terms or conditions of
 sale; salaries; benefits, profits, profit margins, or cost data; market
 shares, sales territories, or markets; allocation of customers or
 territories; or selection, rejection, or termination of customers or
 suppliers.
>>>
>>>
>>>  I would tend to agree that while most of your posts to the list are
>>> within the guidelines, there have been occasions where a reasonable person
>>> could think you might be skirting the line a bit. In this case :
>>>
>>> - Your company works as a broker to procure capacity for others.
>>> - You sent an email to the list that wording wise would be exactly the
>>> same as many of us might send to someone they were looking for capacity
>>> from.
>>>
>>> I think most would agree this is pretty clearly against both the usage
>>> guidelines and the spirit of what this mailing list is about.
>>>
>>> I would also like to remind you that this list is administered by the
>>> NANOG organization. You have no authority to tell others to 'cease and
>>> desist', and insult someone as 'underemployed' is also not well tolerated
>>> here.
>>>
>>> I have looped in the list admins here. It would probably be a good idea
>>> to refrain from future messages that are clearly commercial in nature, or
>>> that contain unnecessary insults.
>>>
>>
>
>
> If only we had some way to segregate out different topics
> of interest or disinterest, so that people who weren't interested
> in questions about bandwidth availability could unsubscribe
> from those topics, and only subscribe to the topics that *did*
> interest them...
>
> #AFewDaysTooEarly
>
> ^_^;;
>
> Matt
>
>
>

Re: OAuth for RIRs - There is already any Idea like that?

[George Michaelson]

The two proposals for RPKI signed attestatations, RSC and RTA, look
candidates for a role this. The primary question is not "who are you"
which OAuth is about, it is "what resources do you control, which
would inform what we're doing here" -which is what RPKI is about.

it's important to be clear, the RSC/RTA activity can't say who you
are. They don't provide identity. But, they do make a strong, provable
assertion of control over the INR in question.

If you want specifically what OAuth does, you're in a different place.
Its about who you are.

-G

On Tue, Mar 23, 2021 at 10:01 PM Douglas Fischer
 wrote:
>
> For me, every day it becomes more evident the need to validate information 
> managed by the RIRs / NIRs / LIRs on separate information platforms.
>
> A very simple example is PeeringDB itself, which requires confirmation of 
> correlation between the ASN whois contact and the account that is registering 
> the organization.
>
> P.S.1: At least for me, this is more evident when it comes to numerical 
> resources, but without going much deeper into the analysis, I believe that 
> this is also applicable to name resources.
>
> I was wondering how complex it would be for RIRs / NIRs to implement some 
> mechanism similar to the OAuth of NIC-Handler accounts to, through a 
> delimitation protocol, allow accounts between information platforms to be 
> correlated, information to be confirmed and maybe even inserted and updated.
>
> Still dreaming a little bit about the possibilities, I imagined that in a 
> federation context, IANA or NRO could correlate NIC-Handlers from the same 
> organization in different RIRs.
>
> In addition to the PeeringDB example, other uses (non-exhaustive list) of 
> this solution could be:
>  - Linking between Maintainers of IRR bases and owners of resources in RIRs.
>  - Linking between accounts on the basis of IXPs, and ASN owners.
>  - Authentication and integration of RPKI CA Delegate services.
>
> I believe that we are already at a point where we can go beyond just using 
> email confirmation.
>
> OAuth and similar protocols include benefits such as:
>  - Simplified use of cryptographic protections
>  - Specific definition of the duration of the authorization.
>  - Forced expiration of authorization.
>  - Granular definition of which attributes will have read-only or read and 
> write access.
>
> I know that for a person with little experience everything seems possible, 
> and for more hardened people things do not seem that simple.
> I also know that not everything in this world depends only on technological 
> feasibility. For although there may be protocols and techniques to solve a 
> problem, many questions depend on the layer 9 definitions of the OSI model.
>
> P.S.2: To be honest, I don't know if there are already initiatives in this 
> direction from the point of view of making this a standard resource. But 
> unless I am mistaken, https://www.denic.de/ already has something similar in 
> place.
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Tomasz Rola]

On Tue, Mar 23, 2021 at 10:32:20AM +0200, Mark Tinka wrote:
> 
> 
> On 3/23/21 02:22, Tomasz Rola wrote:
> 
> >I am not going to lament much, either. It is just how it goes. On the
> >brighter side, there will also be a minority, who will come to email
> >exactly because they will be aspiring power users. I think there will
> >always be some aspiring power users, so it is not going to be only bad.
> 
> There will be, but they will keep dwindling.

Things may be coming to this but they do not have to. I understand
that being a power user involves talking to computer with some kind of
a language, as opposed to pointing with finger. One example is unix
commands, where "ls /usr/bin/ /sbin /usr/sbin/ | wc -l" gives me well
over four thousand "words". So the question is, if in a future there
will be systems which allow "talking to computer with words", allowing
to make complex descriptions of "what to do".

Talking to "siri" is not what I am thinking about, because just like
"desktop metaphore", the "assistant metaphore" is trying to hide too
much of underlying complexity to allow "power usage".

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Valdis Klētnieks]

On Tue, 23 Mar 2021 17:34:37 -0600, Grant Taylor via NANOG said:
> On 3/23/21 4:16 PM, Michael Thomas wrote:
> > But they still have the originating domain's From: address.
>
> My opinion is that messages from the mailing list should not have the
> originating domain in the From: address.  The message from the mailing
> list should be from the mailing list's domain.

And if you do that, what's your preferred way of rearranging the RFC822
headers to denote who the mail was originally from? (Hint: this is something
that RFC compliant MUAs must be able to figure out, and get it correct).



pgp9jcM6wUcrJ.pgp
Description: PGP signature

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Michael Thomas]

On 3/23/21 4:34 PM, Grant Taylor via NANOG wrote:

On 3/23/21 4:16 PM, Michael Thomas wrote:

But they still have the originating domain's From: address.


My opinion is that messages from the mailing list should not have the 
originating domain in the From: address.  The message from the mailing 
list should be from the mailing list's domain.


This has the unfortunate downside of teaching people not to pay 
attention to the From: domain. For mailing lists maybe that's an OK 
tradeoff, but it definitely not a good thing overall. I noticed that the 
IETF list does From re-writing for DMARC domains that are p=reject.





Don't try to graft "can I trust what the mailing list purports or not" 
question onto the problem.  Simplify it to "does this message (from 
the mailing list) pass current best practice security tests or not".  
Notice how the second question is the same question that is already 
being posed about all email (presuming receiving server is doing so).



That is the essence of the problem and always has been. If somebody 
resigns an altered message, does that change my decision of what to do 
in the face of DMARC p=reject? That means I need to know something about 
that mailing list if the answer is yes. Best practices have nothing to 
do with it. It is all about reputation. A message mangler can be Lawful 
Evil, after all.




Since Google participated in ARC, that is a pretty tacit admission 
they don't know how to do mailing list reputation either.


IMHO ARC has at least a priming / boot strapping problem.  How does a 
receiver know if they can trust the purported information they receive 
from the sending system or not.  Simply put, it doesn't.  Hence why I 
think that ARC, as I understand it, is going to fail to thrive.


I went back to the DMARC mailing list wondering what magic that ARC 
provided that we didn't think about 15 years ago only to be disappointed 
that the answer was "none". I really don't understand how this got past 
IESG muster, but it was an experiment.





I personally believe that the mailing list manager, or better it's 
underlying SMTP server infrastructure, should uphold strict 
requirements on the incoming messages.  Only clean messages should be 
emitted from the mailing list manager.  Further, those messages should 
themselves adhere to the same high security standards.


Yes, I think that's a given and feeds into their reputation.




Think about it this way:  Is there really anything (of significant 
value) different between a mailing list manager and a person (or other 
form of automation) receiving a message from a mailbox, copying and 
pasting it (work with me here) into a new message and sending it 
$NumberOfSubscribers times per message to the mailing list?  --  I 
don't think there is.


From the standpoint of the receiving domain, it has no clue who mangled 
the original message. The only thing they know is that there isn't a 
valid signature from the originating domain and what the originating 
domain's advice is for that situation.





What would you want SPF / DKIM / DMARC to do if I took a message from 
you (directly vs passing through the mailing list manager) and changed 
the recipient(s) and re-sent it out to one or more other people?  -- 
I'd wager a reasonable lunch that most people would want SPF / DKIM / 
DMARC to detect and possibly thwart such forwarding.  --  So why is a 
mailing list held to different (lower) standards?


This is the so-called replay attack. It's nonsense. Email has always 
been essentially multicast.



An unsigned message is treated the same as a broken signature. That 
doesn't help from the From: signing policy standpoint.


The original From: signature should have been validated, weighted, and 
judged /before/ it made it to the mailing list manager. Further, the 
mailing list manager should have removed any reference to the original 
signature.  


Signatures shouldn't be removed: a broken signature is identical to a 
missing signature security-wise, but broken signatures can be used for 
forensics. I, for example, could reconstruct a very large percentage of 
mailing list messages to unbreak signatures. It was to the point that it 
was quite tempting to use that approach to deal with MLM traversal.


Mike

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Grant Taylor via NANOG]

On 3/23/21 4:16 PM, Michael Thomas wrote:

But they still have the originating domain's From: address.


My opinion is that messages from the mailing list should not have the 
originating domain in the From: address.  The message from the mailing 
list should be from the mailing list's domain.


No matter how you slice it, you can't get around the fact that DMARC is 
meant to defend against unauthorized using of protected domains in the 
From: header.


Manifestly using MLM signatures as means of doing a reputation check is 
a previously unsolved problem hence the silliness of the ARC experiment 
which relies on the same assumption you are making here.


I do not think that any such endorsements / vouchers / etc. will ever 
work well.


I believe that the mailing list being a terminal and originating entity 
is the way forward.  We all send messages explicitly between two 
parties, ourselves and the mailing list.  Subsequently the mailing list 
originates a new / independent message explicitly between itself and a 
single recipient.


Don't try to graft "can I trust what the mailing list purports or not" 
question onto the problem.  Simplify it to "does this message (from the 
mailing list) pass current best practice security tests or not".  Notice 
how the second question is the same question that is already being posed 
about all email (presuming receiving server is doing so).


Since Google participated in ARC, that is a pretty tacit admission 
they don't know how to do mailing list reputation either.


IMHO ARC has at least a priming / boot strapping problem.  How does a 
receiver know if they can trust the purported information they receive 
from the sending system or not.  Simply put, it doesn't.  Hence why I 
think that ARC, as I understand it, is going to fail to thrive.


I personally believe that the mailing list manager, or better it's 
underlying SMTP server infrastructure, should uphold strict requirements 
on the incoming messages.  Only clean messages should be emitted from 
the mailing list manager.  Further, those messages should themselves 
adhere to the same high security standards.


Think about it this way:  Is there really anything (of significant 
value) different between a mailing list manager and a person (or other 
form of automation) receiving a message from a mailbox, copying and 
pasting it (work with me here) into a new message and sending it 
$NumberOfSubscribers times per message to the mailing list?  --  I don't 
think there is.


What would you want SPF / DKIM / DMARC to do if I took a message from 
you (directly vs passing through the mailing list manager) and changed 
the recipient(s) and re-sent it out to one or more other people?  -- 
I'd wager a reasonable lunch that most people would want SPF / DKIM / 
DMARC to detect and possibly thwart such forwarding.  --  So why is a 
mailing list held to different (lower) standards?


Treat the mailing list as a terminal entity that generates a new 
outbound message which happens to be substantially based on the incoming 
message's body contents.


Terminal as in all the SMTP protections for the original sender stop at 
the mailing list manager.  Likewise a new independent set of SMTP 
protections start with the new messages from the mailing list manager to 
subscribers.  Including the contents of the From: header.


The sticking point is the From: address. If I set up a DMARC p=reject 
policy, I should not be surprised that the receiver does what I asked 
and trashes mailing list traffic.


As well it should.

The point in my blog post is that after over 15 years a solution 
is not going to be found, and trust me I have tried back in the 
day.


IMHO:

 - Trying to pass original metadata /through/ the mailing list /and/ 
deliver it successfully is a fool's errand.
 - Treating the mailing list (or anything like it) as a terminal point 
avoids the problem.


That we should just give up caring about mailing list traversal and 
put the burden on MLM's to figure it out by either not changing the 
message body/subject, or using that horrible hack of rewriting the 
From address.


Is it /truly/ a horrible hack?

I post a morbid scenario:  $BenevolentEntity passes away, and states in 
their will and testament that $Beneficiary should receive $Something. 
--  The message did originate /from/ the benevolent entity, but the 
beneficiary heard / received the message from the $Executor, *NOT* the 
$BenevolentEntity.


Mailing lists have been sending out resigned messages for over a decade. 
We still have really low adoption of p=reject signing policy and at 
least part of the problem is because of fear of mailing lists affecting 
users.


As you can probably tell, I suspect that most of those mailing lists 
have not been configured to operate as a terminal entity.


In Microsoft domain parlance, this is the difference of trusting a 
domain vs the transitive counterpart of trusting who the domain trusts. 
IMHO the former is a relatively sim

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Michael Thomas]

On 3/23/21 2:55 PM, Grant Taylor via NANOG wrote:

On 3/23/21 1:40 PM, Michael Thomas wrote:
The big problem with mailing lists is that they screw up security by 
changing the subject/body and breaking DKIM signatures.


What you are describing is a capability, configuration, execution 
issue with the mailing list manager software.


Said another way, what you are describing is *NOT* a problem with the 
concept of mailing lists.


MLMs can easily receive messages -- after their MTA imposes all 
germane filtering -- and generate /new/ but *completely* *independent* 
messages substantially based on the incoming message's content.  These 
/new/ messages come /from/ /the/ /mailing/ /list/!  Thus the mailing 
list operators can leverage all the aforementioned security / safety 
measure for the mailing list.
But they still have the originating domain's From: address. Manifestly 
using MLM signatures as means of doing a reputation check is a 
previously unsolved problem hence the silliness of the ARC experiment 
which relies on the same assumption you are making here. Since Google 
participated in ARC, that is a pretty tacit admission they don't know 
how to do mailing list reputation either.


SPF / DKIM / DMARC are mean to enable detection (and optionally 
blocking) of messages that do not come from their original source. 
Mailing lists are inherently contrary to this.  But the mailing list 
can be a /new/ source.
The sticking point is the From: address. If I set up a DMARC p=reject 
policy, I should not be surprised that the receiver does what I asked 
and trashes mailing list traffic. The point in my blog post is that 
after over 15 years a solution is not going to be found, and trust me I 
have tried back in the day. That we should just give up caring about 
mailing list traversal and put the burden on MLM's to figure it out by 
either not changing the message body/subject, or using that horrible 
hack of rewriting the From address.


This makes companies leery of setting the signing policy to reject 
which makes it much easier for scammers to phish.


Hence, having the mailing list send out /new/ messages with /new/ 
protection measures mean less breakage for people that send messages 
to the mailing list.


Mailing lists have been sending out resigned messages for over a decade. 
We still have really low adoption of p=reject signing policy and at 
least part of the problem is because of fear of mailing lists affecting 
users.




Treating the mailing list as it's own independent entity actually 
enables overall better security.


Aside:  It is trivial to remove things that cause heartburn (DKIM) 
/after/ NANOG's SMTP server applies filtering /before/ it goes into 
Mailman.



An unsigned message is treated the same as a broken signature. That 
doesn't help from the From: signing policy standpoint.


Mike

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Grant Taylor via NANOG]

On 3/23/21 1:40 PM, Michael Thomas wrote:
The big problem with mailing lists is that they screw up security by 
changing the subject/body and breaking DKIM signatures.


What you are describing is a capability, configuration, execution issue 
with the mailing list manager software.


Said another way, what you are describing is *NOT* a problem with the 
concept of mailing lists.


MLMs can easily receive messages -- after their MTA imposes all germane 
filtering -- and generate /new/ but *completely* *independent* messages 
substantially based on the incoming message's content.  These /new/ 
messages come /from/ /the/ /mailing/ /list/!  Thus the mailing list 
operators can leverage all the aforementioned security / safety measure 
for the mailing list.


SPF / DKIM / DMARC are mean to enable detection (and optionally 
blocking) of messages that do not come from their original source. 
Mailing lists are inherently contrary to this.  But the mailing list can 
be a /new/ source.


To whit, I am sending this reply to /exactly/ /one/ recipient, namely 
the NANOG mailing list.  Said recipient will take my content and send it 
out in hundreds of /new/ and /discrete/ messages.  The NANOG mailing 
list is the source of those new messages.  My email server is not 
contacting your email server.


This makes companies leery of setting the signing policy to reject 
which makes it much easier for scammers to phish.


Hence, having the mailing list send out /new/ messages with /new/ 
protection measures mean less breakage for people that send messages to 
the mailing list.


Treating the mailing list as it's own independent entity actually 
enables overall better security.


Aside:  It is trivial to remove things that cause heartburn (DKIM) 
/after/ NANOG's SMTP server applies filtering /before/ it goes into Mailman.


The Nanog list is something of an outlier in that they don't do 
modifications and the DKIM signature survives.


/Currently/, yes.  I wouldn't hold my breath for future solutions.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Valdis Klētnieks]

On Tue, 23 Mar 2021 15:39:49 -, Emil Pfeffer said:

> The generational gap is not an issue it is how things need to be. The network
> engineering the younger generation deals with is not the same networking the 
> old
> generation deals with but built upon this old networks. This two generations 
> do
> not need the same knowledge and it is in each others best interest that they 
> stay
> separated.

The problem comes when the younger generation *does* need access to the same
knowledge - and the older generation is unreachable and/or actually gone.


pgprryT5lI_mT.pgp
Description: PGP signature

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Michael Thomas]

On 3/23/21 1:44 AM, Mikael Abrahamsson via NANOG wrote:

On Mon, 22 Mar 2021, Grant Taylor via NANOG wrote:

If it's the latter, does that mean that you have to constantly keep 
changing /where/ messages are sent to in order to keep up with the 
latest and greatest or at least most popular (in your audience) 
flavor of the day / week / month / year social media site?


All good questions. I've been using IRC+email for 25+ years now and 
from what I can see, IRC has been replaced by slack/discord etc, and 
email has been replaced by Reddit or Github Issues discussions etc. I 
was on a project where the mailing list was shut down and all further 
discussions were pushed to github instead.


I personally think the "web forum" format is inferior but that might 
be a way to reach out as well...


The big problem with mailing lists is that they screw up security by 
changing the subject/body and breaking DKIM signatures. This makes 
companies leery of setting the signing policy to reject which makes it 
much easier for scammers to phish. The Nanog list is something of an 
outlier in that they don't do modifications and the DKIM signature survives.


I wrote a piece about this a while back that companies should just set 
p=reject and ignore the mailing list problem.


https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

Mike

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Seth Mattinen]

On 3/23/21 8:26 AM, Mark Tinka wrote:



On 3/23/21 17:11, Seth Mattinen wrote:




Okay great for those apps, but if nobody tells me where the new action 
is... how does that help me? With the list here at least it's on 
NANOG's website and they tell you how to join in.


This feels like you're saying people are not worthy of being included 
in the future because they don't "know" when they should just know if 
they are worth being included.


To be honest, if you don't hear about it, you probably aren't the target 
market :-). Happens to me all the time, don't take it personally.


I recently found out about Clubhouse, for example. But it's been around, 
for a while now.


I'm not saying that NOG lists are irrelevant - I'm just saying that the 
kids are flipping between screens faster than they can think. Us geezers 
are bound to lag in their world. But if the time is right, we shall hear 
about the Snapchat of the day so we can prepare our networks for ensuing 
breakage.





This happened to WISPA where a enough people decided to split off and 
make Facebook groups the new gathering place to the detriment of the 
mailing lists.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Andy Ringsmuth]

> On 3/22/21 11:22 PM, Cynthia Revström via NANOG wrote:
>> Hi,
>> 
>> As someone from a "younger generation" (2001) who does use mailing lists, 
>> semi-actively participates in RIPE mailing lists but also created a network 
>> community on Discord, I want to chime in here.
>> 
>> > Are they willing to use a (traditional) forum (of sorts) that is
>> dedicated to the venue?  Or Are they wanting things to come to them
>> wherever they happen to be today?  E.g. Facebook group, Discord, Slack, etc?
>> 
>> I haven't ever used facebook beyond receiving some invitation for an event, 
>> and I feel like that's the most common case for people around my age group. 
>> (not using Facebook that is)
>> 
> I'm under the impression that for the younger generations that Facebook is 
> deeply uncool. It's where grandma posts pictures of her knitting.
> 
> Mike

Mike, 

You hit the nail on the head right there.

Among the younger folk, the preferred methods and mediums of communication 
change faster than anything. MySpace two days ago, Facebook yesterday, 
Instagram today, Snapchat tomorrow, etc. etc. etc.

Migrate the infrastructure to InstaTwitSpit today and by the time it is all 
migrated, FaceSplatVue is all the rage.

Email has been here since the beginning of the ’net. It isn’t going away. 
Everyone knows how to use it. It is platform independent. It is not owned by 
Fuckerburg or Dorsey.

-Andy

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[scott]

On Tue, Mar 23, 2021 at 2:35 PM scott > wrote:



Well, now we are likely find out what happens when Discord is bought:


"Microsoft in talks to buy Discord messaging platform - sources"


https://www.reuters.com/article/us-discord-m-a/microsoft-in-talks-to-buy-discord-messaging-platform-sources-idUSKBN2BE320




--

On 3/23/2021 8:39 AM, Tom Beecher wrote:

Nope.

https://www.discourse.org/  != 
https://discord.com/ 





Oops, thanks.  I will go and hide in the corner with my coffee pot...

scott

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Tom Beecher]

Nope.

https://www.discourse.org/ != https://discord.com/

On Tue, Mar 23, 2021 at 2:35 PM scott  wrote:

>
> Well, now we are likely find out what happens when Discord is bought:
>
>
> "Microsoft in talks to buy Discord messaging platform - sources"
>
>
> https://www.reuters.com/article/us-discord-m-a/microsoft-in-talks-to-buy-discord-messaging-platform-sources-idUSKBN2BE320
>
>
> scott
>
>

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[scott]

Well, now we are likely find out what happens when Discord is bought:


"Microsoft in talks to buy Discord messaging platform - sources"

https://www.reuters.com/article/us-discord-m-a/microsoft-in-talks-to-buy-discord-messaging-platform-sources-idUSKBN2BE320


scott

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Alain Hebert]

    Hey, I did some OS/2 network driver for SNA over X.25 card using a 
PRI =D.


    But its all a question of workflow...  Fake busy work created by 
devices/apps battling for your attention ain't my cup of tea.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 3/23/21 2:14 PM, Sabri Berisha wrote:

- On Mar 23, 2021, at 1:09 AM, Mark Tinka mark@tinka.africa wrote:

Hi,


I'm of the opposite view... front-end shiny GUI's are the risk. I'd
babysit them before I let them leave the house. For a long time.

Children of the magenta line...

Most of the more effective troubleshooting techniques will require some sort
of CLI or CLI-like output. In times of crisis, you'll want to be able to
type "show ip bgp summary", instead of waiting for your browser to send a
javascript request to a server, the server to run a python script invoking
netmiko to log onto a node, grab the output, reformat it, have it sent back
to your browser and rendered.

Not to mention that, like pilots, network engineers need hands-on time to
stay effective. Planes have crashed because pilots lost it and relied on
automation (Asiana 214, anyone?).

That said, as a soon-to-be-dinosaur, I try to keep up with the latest and
greatest. I don't want to run the risk of becoming an ATM engineer.

Thanks,

Sabri

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Michael Thomas]

On 3/22/21 11:22 PM, Cynthia Revström via NANOG wrote:

Hi,

As someone from a "younger generation" (2001) who does use mailing 
lists, semi-actively participates in RIPE mailing lists but also 
created a network community on Discord, I want to chime in here.


> Are they willing to use a (traditional) forum (of sorts) that is
dedicated to the venue? Or Are they wanting things to come to them
wherever they happen to be today?  E.g. Facebook group, Discord, 
Slack, etc?


I haven't ever used facebook beyond receiving some invitation for an 
event, and I feel like that's the most common case for people around 
my age group. (not using Facebook that is)


I'm under the impression that for the younger generations that Facebook 
is deeply uncool. It's where grandma posts pictures of her knitting.


Mike

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Sabri Berisha]

- On Mar 23, 2021, at 1:09 AM, Mark Tinka mark@tinka.africa wrote:

Hi,

> I'm of the opposite view... front-end shiny GUI's are the risk. I'd
> babysit them before I let them leave the house. For a long time.

Children of the magenta line...

Most of the more effective troubleshooting techniques will require some sort
of CLI or CLI-like output. In times of crisis, you'll want to be able to
type "show ip bgp summary", instead of waiting for your browser to send a 
javascript request to a server, the server to run a python script invoking
netmiko to log onto a node, grab the output, reformat it, have it sent back
to your browser and rendered.

Not to mention that, like pilots, network engineers need hands-on time to
stay effective. Planes have crashed because pilots lost it and relied on 
automation (Asiana 214, anyone?).

That said, as a soon-to-be-dinosaur, I try to keep up with the latest and 
greatest. I don't want to run the risk of becoming an ATM engineer.

Thanks,

Sabri

Re: Reinventing the wheel on a path to deeper learning

[Grant Taylor via NANOG]

On 3/23/21 12:41 AM, Cynthia Revström via NANOG wrote:
And while Discord is not at all a replacement for mailing lists in my 
opinion, I think it's important to realize that it (and other chat based 
things like it) have their place, especially among the younger groups.


I believe that chat / IM most /definitely/ have their place along side 
mailing lists.  To me they serve different purposes.


IM(ns)HO chat is more real time, low latency, and low bandwidth 
communications with immediate gratification.  Conversely mailing lists 
are decidedly not real time, higher latency, and higher bandwidth 
communications without the immediate gratification.


There's a 3rd form of communications that I've not seen (or missed) in 
the discussions, that being the NANOG in person meetings.


To me, all three forms of communications have their uses and can 
function as a compliment to each other.  However, none of them are 
replacements for any of the others.


It's also important to remember that the types of information that pass 
through each mode of communications are different.  As such, it might be 
possible to actually improve the quality (SNR) of communications in each 
mode if we gravitate towards the mode that best suits the need.  Real 
time discussions of ongoing events (including the "me / here too"s) may 
be better via Discord.  Summaries and longer running discussions are 
probably better suited to a mailing list.  And nothing will beat in 
person presentations at NANOG meetings (or recordings there of).


Perhaps we should spend a few minutes thinking about what question(s) 
we're asking / point(s) that we're making.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Reinventing the wheel on a path to deeper learning

[Matthew Pounsett]

On Tue, 23 Mar 2021 at 02:42, Cynthia Revström via NANOG
 wrote:
>
> And while Discord is not at all a replacement for mailing lists in my 
> opinion, I think it's important to realize that it (and other chat based 
> things like it) have their place, especially among the younger groups.

I'm not even "the younger group" anymore (as a nearly-50 gen-x-er) and
I still prefer chat for many kinds of interaction.

As for NANOG specifically, it would not occur to me to ask on this
list about beginner-level networking problems, and that's as a
long-time NANOG attendee and list subscriber.  NANOG's environment
just doesn't give the vibe that it's a good place to start when you're
just trying to figure things out.  The list traffic and meeting
agendas have always been dominated by either high-capacity or
high-complexity.

Someone trying to sort out early questions is going to be way more
comfortable on a chat platform (that doesn't have a permanent memory),
possibly even in a channel designated for that kind of help.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Emil Pfeffer]

On Tue, Mar 23, 2021 at 09:20:14AM -0500, Mike Hammett wrote:
> "But why it should or shouldn't be clicked..." 
> 
> Sorta like most man pages. 
> 

They both need prior knowledge to use. 
We tend to simplify things in order to save time but then the new generation 
comes
in and thinks the simple things it's all there is and have no willingness to go
back in time and accumulate "useless" knowledge. It is useless because the 
problems
it fixes were already fixed but it is paramount in understanding whats behind 
the 
simple things. Knowledge can only be simplified so much and there's no shortcut 
to
accumulating it. (hence why most people will prefer to just use the tools)

The generational gap is not an issue it is how things need to be. The network
engineering the younger generation deals with is not the same networking the old
generation deals with but built upon this old networks. This two generations do
not need the same knowledge and it is in each others best interest that they 
stay
separated. Although we would gladly help someone that is obviously putting in 
the
effort and is looking to learn we have not volunteered to be teachers and some 
people
need to understand that we prefer to keep it simple because we have no time to 
waste.

It is easy to believe that the method you are using is the one but eventually
the good ones will have to pass the test of time which mailling lists and a 
plethora
of the old tools successfully did. 
-- 

Re: Peering and Caching for Epic Games, Fortnite, et al

[Mark Tinka]

On 3/23/21 17:03, Eric Dugas via NANOG wrote:

Agreed. The few good examples in Canada are Ubisoft/i3D (now mostly 
just i3D) and Riot Games. We don't have Valve or Blizzard here.


Epic Games seems to use Akamai for downloads/updates and AWS for 
backend so I don't see how you can cache/optimize latency other than 
getting in Akamai's own AANP program and peering with AWS.


Gaming networks are not as keen on building out network as generic 
content folk are.


So while they may be seen as "content" sources, they are not 
"content-content" sources, if you follow my drift.


There are some backbones that dedicate their goal to making access to 
gaming services effortless. But those are not as rife as regular ISP's.


Mark.

Re: Peering and Caching for Epic Games, Fortnite, et al

[Martijn Schmidt via NANOG]

Hi folks,

To briefly clarify the "now mostly i3D" situation.. i3D.net was acquired by 
Ubisoft in 2019, and the reason why you're seeing Ubisoft's ASN disappearing 
from the IXPs where they were present is that we are integrating the networks. 
Ubisoft's prefixes are being announced downstream of i3D.net's AS49544 and 
continue to be reachable through a very long list of IXPs.

Another thing to keep in mind is that not all videogaming publishers have 
in-house game hosting capabilities, exactly because it is not easy to build the 
required global footprint to support this type of traffic with sufficient 
low-latency quality. Many will use external hosting providers, either bare 
metal or cloud. And although we are nowadays owned by Ubisoft, we still carry 
lots of non-Ubisoft videogames in our network since helping this industry 
attain low latency has always been and continues to be our core business.

Best regards,
Martijn

On 3/23/21 4:03 PM, Eric Dugas via NANOG wrote:
Agreed. The few good examples in Canada are Ubisoft/i3D (now mostly just i3D) 
and Riot Games. We don't have Valve or Blizzard here.

Epic Games seems to use Akamai for downloads/updates and AWS for backend so I 
don't see how you can cache/optimize latency other than getting in Akamai's own 
AANP program and peering with AWS.

Eric

On Mar 23 2021, at 10:05 am, Mike Hammett 
 wrote:
For an industry (online gaming) with the most "sensitive" customers to latency, 
packet loss, throughput, etc., the online gaming industry is terrible at 
peering. There are a few shining examples of what you should do, but then the 
rest is just content with buying transit from one, two, three players and 
calling it a day.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

From: "Jose Luis Rodriguez" 

To: nanog@nanog.org
Sent: Monday, March 22, 2021 9:13:46 PM
Subject: Peering and Caching for Epic Games, Fortnite, et al

We run a healthy-sized ISP (say, 2.5M households, plus enterprise, etc ) and we 
really, REALLY want to make sure our users have an amazing experience when 
downloading the neverending Fortnite/Spacequest/Blizzard/DigDug  updates that 
run down our pipes. Would love to hear from others about how they're peering 
and caching -- not having the level of success I'd want with the typical 
"aggregators"  (they know who they are ) and would really like to link to the 
source even if it means trenching through the core of the Earth...

Would love pointers, names, or any leads, on or off list.

Thanks

Jose L. Rodriguez
CTO, Totalplay

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Matthew Pounsett]

On Tue, 23 Mar 2021 at 02:46, Cynthia Revström via NANOG
 wrote:
>
> I have used Mattermost but iirc it has very limited access control unless you 
> have the enterprise version and generally doesn't seem to be made for public 
> groups.

I'm going to chime in here since I admin the DNS-OARC Mattermost
server, which is for public groups.  For those not familiar with it,
DNS-OARC is a NOG-like organization specific to the DNS.  More info at
.  I'm writing this just to provide
information as someone who's already operating Mattermost in the use
case under discussion .. not advocating for its use at NANOG.

Less than a year after deploying it (replacing our Jabber server), we
currently have a little under 400 users on their default 1000-seat
not-for-profit license, which is at their E10 (E for Enterprise)
level.  Mattermost has three license levels:  Free, E10, and E20.

We use a chat platform for three main use cases: internal staff chat,
member to member chat, and a public chat platform to accompany the
dns-operati...@dns-oarc.net mailing list, which—again—is a bit like a
DNS-specific version of the public NANOG list.   The main reason we
selected Mattermost for the role is because of the option to self-host
the platform.   On top of the common motivation to not want our data
to disappear because a proprietary platform went away, we have some
additional information and data privacy concerns because we facilitate
confidential communication between  our members.

I agree Mattermost isn't designed with public groups in mind, although
we manage to make it work for that just fine.  The main clue about
their intended use case is that they seem to have made the assumption
that anyone using the platform is well known to the admins of the
platform.  For example, finding and pruning idle users requires you to
write a bit of your own code—the assumption seems to be that you're
onboarding and deleting users as a reaction to some other process
(such as hiring) and not that you might have users where it's unclear
whether they're still using the platform.

Other than that one glaring gap (and they seem to be working on fixing
that) I have found it to do an excellent job.

NANOG as an organization has a lot more financial resources than OARC
and, if it was deemed desirable, I'm sure that something could be
worked out for NFP pricing for more users than the 1000-user cap on
the default NFP license, and probably even for E20 levels of features.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/23/21 17:11, Seth Mattinen wrote:




Okay great for those apps, but if nobody tells me where the new action 
is... how does that help me? With the list here at least it's on 
NANOG's website and they tell you how to join in.


This feels like you're saying people are not worthy of being included 
in the future because they don't "know" when they should just know if 
they are worth being included.


To be honest, if you don't hear about it, you probably aren't the target 
market :-). Happens to me all the time, don't take it personally.


I recently found out about Clubhouse, for example. But it's been around, 
for a while now.


I'm not saying that NOG lists are irrelevant - I'm just saying that the 
kids are flipping between screens faster than they can think. Us geezers 
are bound to lag in their world. But if the time is right, we shall hear 
about the Snapchat of the day so we can prepare our networks for ensuing 
breakage.


Mark.

Re: Peering and Caching for Epic Games, Fortnite, et al

[Tom Beecher]

>
> For an industry (online gaming) with the most "sensitive" customers to
> latency, packet loss, throughput, etc., the online gaming industry is
> terrible at peering.


That's because they often don't really need to.

Content and patch distribution is generally handled via a CDN. For
companies that run games with central hosted servers, those servers are
hosted in leased datacenter space, often behind a large provider's network.
Blizzard , for example, has (I believe) all of their US servers hosted in
ATT locations. Most other games either have their online bits in AWS, or
just do peer to peer communication.



On Tue, Mar 23, 2021 at 10:07 AM Mike Hammett  wrote:

> For an industry (online gaming) with the most "sensitive" customers to
> latency, packet loss, throughput, etc., the online gaming industry is
> terrible at peering. There are a few shining examples of what you should
> do, but then the rest is just content with buying transit from one, two,
> three players and calling it a day.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Jose Luis Rodriguez" 
> *To: *nanog@nanog.org
> *Sent: *Monday, March 22, 2021 9:13:46 PM
> *Subject: *Peering and Caching for Epic Games, Fortnite, et al
>
> We run a healthy-sized ISP (say, 2.5M households, plus enterprise, etc )
> and we really, REALLY want to make sure our users have an amazing
> experience when downloading the neverending
> Fortnite/Spacequest/Blizzard/DigDug  updates that run down our pipes. Would
> love to hear from others about how they're peering and caching -- not
> having the level of success I'd want with the typical "aggregators"  (they
> know who they are ) and would really like to link to the source even if it
> means trenching through the core of the Earth...
>
> Would love pointers, names, or any leads, on or off list.
>
> Thanks
>
> Jose L. Rodriguez
> CTO, Totalplay
>
>

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Seth Mattinen]

On 3/23/21 7:40 AM, Mark Tinka wrote:



On 3/23/21 16:34, Seth Mattinen wrote:


The problem with other "social" formats I've found is that they're 
often an exclusive club you have to know about through connections or 
be invited to. You can also be excluded on a whim.


What you can learn from that is the new brand marketing models of 
today's Internet world.


Standard over-the-top selling is not much of a model anymore. If an app 
(or service) is worth the value it purports, its users will do all the 
marketing for it that it needs.





Okay great for those apps, but if nobody tells me where the new action 
is... how does that help me? With the list here at least it's on NANOG's 
website and they tell you how to join in.


This feels like you're saying people are not worthy of being included in 
the future because they don't "know" when they should just know if they 
are worth being included.

Re: Peering and Caching for Epic Games, Fortnite, et al

[Eric Dugas via NANOG]

Agreed. The few good examples in Canada are Ubisoft/i3D (now mostly just i3D) 
and Riot Games. We don't have Valve or Blizzard here.

Epic Games seems to use Akamai for downloads/updates and AWS for backend so I 
don't see how you can cache/optimize latency other than getting in Akamai's own 
AANP program and peering with AWS.
Eric
On Mar 23 2021, at 10:05 am, Mike Hammett  wrote:
> For an industry (online gaming) with the most "sensitive" customers to 
> latency, packet loss, throughput, etc., the online gaming industry is 
> terrible at peering. There are a few shining examples of what you should do, 
> but then the rest is just content with buying transit from one, two, three 
> players and calling it a day.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
> From: "Jose Luis Rodriguez" 
> To: nanog@nanog.org
> Sent: Monday, March 22, 2021 9:13:46 PM
> Subject: Peering and Caching for Epic Games, Fortnite, et al
>
> We run a healthy-sized ISP (say, 2.5M households, plus enterprise, etc ) and 
> we really, REALLY want to make sure our users have an amazing experience when 
> downloading the neverending Fortnite/Spacequest/Blizzard/DigDug updates that 
> run down our pipes. Would love to hear from others about how they're peering 
> and caching -- not having the level of success I'd want with the typical 
> "aggregators" (they know who they are ) and would really like to link to the 
> source even if it means trenching through the core of the Earth...
>
> Would love pointers, names, or any leads, on or off list.
>
> Thanks
>
> Jose L. Rodriguez
> CTO, Totalplay
>
>
>

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/23/21 16:34, Seth Mattinen wrote:


The problem with other "social" formats I've found is that they're 
often an exclusive club you have to know about through connections or 
be invited to. You can also be excluded on a whim.


What you can learn from that is the new brand marketing models of 
today's Internet world.


Standard over-the-top selling is not much of a model anymore. If an app 
(or service) is worth the value it purports, its users will do all the 
marketing for it that it needs.


Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Seth Mattinen]

On 3/22/21 11:22 PM, Cynthia Revström via NANOG wrote:
I haven't ever used facebook beyond receiving some invitation for an 
event, and I feel like that's the most common case for people around my 
age group. (not using Facebook that is)



Facebook has effectively become social media for old people. It's not 
the future IMO.


The problem with other "social" formats I've found is that they're often 
an exclusive club you have to know about through connections or be 
invited to. You can also be excluded on a whim.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mike Hammett]

"But why it should or shouldn't be clicked..." 

Sorta like most man pages. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: nanog@nanog.org 
Sent: Tuesday, March 23, 2021 3:11:44 AM 
Subject: Re: Perhaps it's time to think about enhancements to the NANOG 
list...? 




On 3/21/21 03:45, Eric Kuhnke wrote: 






But it's another thing to consider that we have a whole new generation of 
people who don't know and don't care what's going underneath the GUI and might 
not be able to do anything with the OS running on bare metal, if they have to. 



If we intend to abstract away configuring devices to a GUI level only and not 
care about what's going on under the hood, then it's time for everyone to just 
run out and renew their MCSE certifications and buy Meraki subscriptions. 


This has been a longstanding concern of mine with the next batch of network 
engineers. 

The GUI may have a check-box that says "ATT Bit". It is there to click, or not 
click. But why it should or shouldn't be clicked is the looming danger we are 
setting up the new blood for. 

Mark. 

Re: Peering and Caching for Epic Games, Fortnite, et al

[Mike Hammett]

For an industry (online gaming) with the most "sensitive" customers to latency, 
packet loss, throughput, etc., the online gaming industry is terrible at 
peering. There are a few shining examples of what you should do, but then the 
rest is just content with buying transit from one, two, three players and 
calling it a day. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Jose Luis Rodriguez"  
To: nanog@nanog.org 
Sent: Monday, March 22, 2021 9:13:46 PM 
Subject: Peering and Caching for Epic Games, Fortnite, et al 


We run a healthy-sized ISP (say, 2.5M households, plus enterprise, etc ) and we 
really, REALLY want to make sure our users have an amazing experience when 
downloading the neverending Fortnite/Spacequest/Blizzard/DigDug updates that 
run down our pipes. Would love to hear from others about how they're peering 
and caching -- not having the level of success I'd want with the typical 
"aggregators" (they know who they are ) and would really like to link to the 
source even if it means trenching through the core of the Earth... 


Would love pointers, names, or any leads, on or off list. 


Thanks 


Jose L. Rodriguez 
CTO, Totalplay 

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Jim Mercer]

On Mon, Mar 22, 2021 at 03:48:02PM -0600, David Siegel wrote:
> We already have a group on Facebook, and it has it's uses.  Like sharing
> group pictures from events and other social-y stuff.

yeah, that's all i need, is to get reprimanded at work while reading up on 
NANOG things, because Wish injected an ad for some plausibly NSFW item.

no thanks.

-- 
Jim Mercer Reptilian Research  j...@reptiles.org+1 416 410-5633

Life should not be a journey to the grave with the intention of
arriving safely in a pretty and well preserved body, but rather
to skid in broadside in a cloud of smoke, thoroughly used up,
totally worn out, and loudly proclaiming "Wow! What a Ride!"
 -- Hunter S. Thompson

Re: Peering and Caching for Epic Games, Fortnite, et al

[John Waters via NANOG]

Hey!  
I know at least for Valve, you can set up a Steam Caching Server, and say do 
the top 100 games or whatnot and update it every week or so, that might put you 
in the right direction. LTT did a good video on this a few years ago, and they 
also posted this guide on their forums to assist with getting one set up.

https://linustechtips.com/topic/962655-steam-caching-tutorial/ 
 

I’ve set up two or three for various larger scale LAN parties, as well as run 
one at home.  Feel free to ping me offline if you want a hand or talking it 
over!

Thanks Much,
John Waters
Chief Architect,
Capitol Hosting Solutions, LLC
john@capitolsolutions.cloud 
https://chs.gg


> On Mar 22, 2021, at 19:13, Jose Luis Rodriguez  wrote:
> 
> We run a healthy-sized ISP (say, 2.5M households, plus enterprise, etc ) and 
> we really, REALLY want to make sure our users have an amazing experience when 
> downloading the neverending Fortnite/Spacequest/Blizzard/DigDug  updates that 
> run down our pipes. Would love to hear from others about how they're peering 
> and caching -- not having the level of success I'd want with the typical 
> "aggregators"  (they know who they are ) and would really like to link to the 
> source even if it means trenching through the core of the Earth...
> 
> Would love pointers, names, or any leads, on or off list. 
> 
> Thanks
> 
> Jose L. Rodriguez
> CTO, Totalplay

Re: OT: Re: Facebook and other walled gardens

[Christopher Conforti]

On Mon, 22 Mar 2021 11:41:22 -0700
William Herrin  wrote:

> On Mon, Mar 22, 2021 at 10:23 AM Andy Ringsmuth 
> wrote:
> > No. Use a communication method that is available globally, not
> > proprietary and doesn’t require me to sell my soul to the devil
> > simply to participate.  
> 
> Hi Andy,
> 
> I refused to get a Facebook account until I was paid to. Now that I
> have one, I wonder why I bothered. I isolate it in its own browser
> profile so it can't snoop the rest of my web activity and I gave it an
> alias email address that only they have. I mostly  control what
> information I give them. I like having an effortless way to keep up
> with my extended friends and family. In spite of that, I was surprised
> how good a job Facebook did targeting ads to my interests -- the
> knight hoodies were just too cool.
> 
> > Sigh. It is probably a losing battle. You kids get off my grass!  
> 
> The world moves on. I still don't like the idea of Facebook, but I
> actually like Facebook.
> 
> Regards,
> Bill Herrin
> 
> P.S. Facebook's "Portal Plus" device is simply the best personal video
> conferencing device I've ever used. Clear audio. Following camera that
> keeps you in frame. It's slick.
> 
> P.p.s. Did you know that accessing customers' private information
> without the customer's explicit permission is a zero-tolerance
> first-time firing offense at Facebook? I didn't! Seems they got
> religion after Cambridge Analytica. They even have strong technical
> controls to stop it. They process the heck out of your data but they
> do not, do not look.
> 

No, they just sell it to another gaggle of chuckleheads who *do* look.
It doesn't matter whether or not they look, I don't want them having it
in the first place. :P

-- 
Christopher Conforti


pgp6gWFx9xo91.pgp
Description: OpenPGP digital signature

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/23/21 11:37, Alfie Pates wrote:

More opinions, from someone old and jaded enough to prefer IRC but 
quite a bit younger than the NANOG mailing list itself!


I feel like Mattermost bridged into a private IRC server (Matterbridge 
is really good at puppetry these days: 
https://github.com/42wim/matterbridge 
) would cover the widest gamut 
of old hands who like IRC and newer users more familiar with 
slack/discord/similar platforms, without forcing people onto one or 
the other. (Discord bridging is also a possibility, but I cannot 
emphasise enough how absolutely unenthusiastic I am using Discord for 
anything work-related.)


As for improving the mailing list experience, I think a migration to 
mailman3 would make interacting with the mailing list a lot more 
friendly for folks not used to the quirks of mailman2. Hyperkitty (the 
mailman3 archives renderer / web interface) is a really nice 
experience for browsing list archives, and has functionality to enable 
replies / new threads / etc, which are _super_ usable. Again, I think 
this would cover the widest gamut of users both new and old, whilst 
still remaining definitively a mailing list and allowing searching of 
all of the NANOG archives.


Discourse is an utterly dire user experience for a larger community 
such as NANOG. I'm subscribed to a few Discourse instances - the 
mailing-list mode just isn't worth using (It does not behave like a 
traditional mailing list, nor a forum!) and I find the web interface 
sluggish and fairly unintuitive (scaling is apparently expensive): All 
of this seems to contribute to a much less satisfying forum experience.


Personally, I'm not bothered by any of this at all. The state-of-the-art 
will naturally gravitate to where it wants to go, and the dust will 
settle where it does.


I quite enjoy the mailing list format, but in as much as I am now 
running Telegram on my desktop to interact with the kids that aren't 
keen on the mailing list alternative of the forum, I have accepted that 
I will simply have to be ready and adapt to the order of the day, or get 
left behind in my utopia.


There's no right or wrong answer... just what is.

Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/23/21 11:35, Cynthia Revström wrote:


I think this is at least partially true, but I think it is more not
wanting to be disrespected at the time they ask these questions.
No one was born with this kind of knowledge, and everyone was clueless
at some point in time.


Totally agree.

It is the result of the centuries of an industrial revolution that has 
shaped us to consider anything less than expertise as being considerable 
of anyone's time.


The kids have grown up in an age where information is democratized, 
i.e., you are far better off if you are curious and ask questions, 
rather than assume you know everything and don't need to learn anymore. 
Mobile messaging apps do not have this kind of pressure, compared to 
your garden-variety, 30-year old mailing list concept.


Not to say that either is good or bad, but to realize what works for a 
generation that is more focused on outcomes and solutions, rather than 
outcomes, solutions, and many times, posturing.




Also a permanent public archive is not a requirement of a mailing list
even if it is common.


Indeed. However, "just for posterity" is not an uncommon reason why folk 
that like mailing lists continue to do so.





Also, at least I often feel like the more casual conversational chat
format is easier than emails and this is the case for many of my
friends as well.


Couldn't agree with you more.

Keeping it simple so you can reach your result faster and most 
efficiently is often understood more by the kids than us geezers. While 
we are fighting about whether Discourse or Mailman are appropriate, the 
kids have probably dumped both and found something that gets them to the 
promised land 5 seconds after they install the app.


We'd be remiss to ignore this approach.

Mark.

OAuth for RIRs - There is already any Idea like that?

[Douglas Fischer]

For me, every day it becomes more evident the need to validate information
managed by the RIRs / NIRs / LIRs on separate information platforms.

A very simple example is PeeringDB itself, which requires confirmation of
correlation between the ASN whois contact and the account that is
registering the organization.

P.S.1: At least for me, this is more evident when it comes to numerical
resources, but without going much deeper into the analysis, I believe that
this is also applicable to name resources.

I was wondering how complex it would be for RIRs / NIRs to implement some
mechanism similar to the OAuth of NIC-Handler accounts to, through a
delimitation protocol, allow accounts between information platforms to be
correlated, information to be confirmed and maybe even inserted and updated.

Still dreaming a little bit about the possibilities, I imagined that in a
federation context, IANA or NRO could correlate NIC-Handlers from the same
organization in different RIRs.

In addition to the PeeringDB example, other uses (non-exhaustive list) of
this solution could be:
 - Linking between Maintainers of IRR bases and owners of resources in RIRs.
 - Linking between accounts on the basis of IXPs, and ASN owners.
 - Authentication and integration of RPKI CA Delegate services.

I believe that we are already at a point where we can go beyond just using
email confirmation.

OAuth and similar protocols include benefits such as:
 - Simplified use of cryptographic protections
 - Specific definition of the duration of the authorization.
 - Forced expiration of authorization.
 - Granular definition of which attributes will have read-only or read and
write access.

I know that for a person with little experience everything seems possible,
and for more hardened people things do not seem that simple.
I also know that not everything in this world depends only on technological
feasibility. For although there may be protocols and techniques to solve a
problem, many questions depend on the layer 9 definitions of the OSI model.

P.S.2: To be honest, I don't know if there are already initiatives in this
direction from the point of view of making this a standard resource. But
unless I am mistaken, https://www.denic.de/ already has something similar
in place.
-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Alfie Pates]

More opinions, from someone old and jaded enough to prefer IRC but quite a bit 
younger than the NANOG mailing list itself!

I feel like Mattermost bridged into a private IRC server (Matterbridge is 
really good at puppetry these days: https://github.com/42wim/matterbridge) 
would cover the widest gamut of old hands who like IRC and newer users more 
familiar with slack/discord/similar platforms, without forcing people onto one 
or the other. (Discord bridging is also a possibility, but I cannot emphasise 
enough how absolutely unenthusiastic I am using Discord for anything 
work-related.)

As for improving the mailing list experience, I think a migration to mailman3 
would make interacting with the mailing list a lot more friendly for folks not 
used to the quirks of mailman2. Hyperkitty (the mailman3 archives renderer / 
web interface) is a really nice experience for browsing list archives, and has 
functionality to enable replies / new threads / etc, which are _super_ usable. 
Again, I think this would cover the widest gamut of users both new and old, 
whilst still remaining definitively a mailing list and allowing searching of 
all of the NANOG archives.

Discourse is an utterly dire user experience for a larger community such as 
NANOG. I'm subscribed to a few Discourse instances - the mailing-list mode just 
isn't worth using (It does not behave like a traditional mailing list, nor a 
forum!) and I find the web interface sluggish and fairly unintuitive (scaling 
is apparently expensive): All of this seems to contribute to a much less 
satisfying forum experience.

Cheers,
a

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Cynthia Revström via NANOG]

> Many new, young engineers will also feel more comfortable posting on message 
> apps because the group is small, well-known and reasonably private, i.e., 
> they are less afraid about sounding clueless to the whole world, on record, 
> forever.

I think this is at least partially true, but I think it is more not
wanting to be disrespected at the time they ask these questions.
No one was born with this kind of knowledge, and everyone was clueless
at some point in time.
Also a permanent public archive is not a requirement of a mailing list
even if it is common.

Also, at least I often feel like the more casual conversational chat
format is easier than emails and this is the case for many of my
friends as well.

-Cynthia

On Tue, Mar 23, 2021 at 9:38 AM Mark Tinka  wrote:
>
>
>
> On 3/23/21 08:22, Cynthia Revström via NANOG wrote:
>
>
> Using a chat system they are already familiar with to ask more casual 
> questions is a lot easier for some.
> Especially if you are thinking of people who are just starting out, some of 
> which will be part of the next generation of network engineers.
>
>
> Many new, young engineers will also feel more comfortable posting on message 
> apps because the group is small, well-known and reasonably private, i.e., 
> they are less afraid about sounding clueless to the whole world, on record, 
> forever.
>
> Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Eric Kuhnke]

For persons considering mattermost, I would recommend instead looking into
a self hosted Matrix + Synapse (matrix protocol server daemon) setup, which
is fully open source.

https://en.wikipedia.org/wiki/Matrix_(protocol)

Element is one typical GUI client for it, but there are many options.
https://en.wikipedia.org/wiki/Element_(software)



On Mon, Mar 22, 2021 at 11:45 PM Cynthia Revström via NANOG 
wrote:

> I have used Mattermost but iirc it has very limited access control unless
> you have the enterprise version and generally doesn't seem to be made for
> public groups.
>
> This in addition to probably the main problem, it will have higher barrier
> to entry especially for those already using Discord for other purposes.
>
> -Cynthia
>
> On Tue, Mar 23, 2021, 07:38 Karl Auer  wrote:
>
>> On Tue, 2021-03-23 at 07:22 +0100, Cynthia Revström via NANOG wrote:
>> > Because Discord is proprietary, you can't host your own instance
>>
>> For reasons of confidentiality we implemented a MatterMost server for
>> company use. It is free, works well, runs on our own servers. It lacks
>> some of the bells and whistles that Discord has (in particular it has
>> no audio or screensharing), but as an instant messaging platform for us
>> it's worked very well indeed.
>>
>>
>> Regards, K.
>>
>> --
>> ~~~
>> Karl Auer (ka...@biplane.com.au)
>> http://www.biplane.com.au/kauer
>>
>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
>>
>>
>>
>>

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mikael Abrahamsson via NANOG]

On Mon, 22 Mar 2021, Grant Taylor via NANOG wrote:

If it's the latter, does that mean that you have to constantly keep 
changing /where/ messages are sent to in order to keep up with the 
latest and greatest or at least most popular (in your audience) flavor 
of the day / week / month / year social media site?


All good questions. I've been using IRC+email for 25+ years now and from 
what I can see, IRC has been replaced by slack/discord etc, and email has 
been replaced by Reddit or Github Issues discussions etc. I was on a 
project where the mailing list was shut down and all further discussions 
were pushed to github instead.


I personally think the "web forum" format is inferior but that might be a 
way to reach out as well...


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Edward McNair]

Discourse is completely open source. We could run our own instance, if we chose 
to. Currently, we opted for third party hosting, but we shift to self hosting 
at anytime. All data is ours, and could be backed up and self-hosted in a few 
hours. For our beta test we imported the entire mailing list archive. It’s 
currently a read-only mirror of the archive. Any new posts are synced to our 
read-only Discourse instance. 


Edward McNair
Executive Director

emcn...@nanog.org | +1 866-902-1336 ext. 102  | www.nanog.org
NANOG | 305 E. Eisenhower Pkwy, Suite 100 | Ann Arbor, MI 48108, USA

> On Mar 22, 2021, at 4:39 PM, james.cut...@consultant.com wrote:
> 
> On Mar 22, 2021, at 6:01 PM, scott  wrote:
>> 
>> One last thing before I stop.  How would the numerous NANOG archives work 
>> when everything is on Discourse?  The same?
> 
> Absolutely not! 
> 
> The archives on Discourse and the like, along with everything else, is 
> subject to the marketing-driven application owner’s whims. One should not 
> expect archives to be maintained indefinitely. And, when the vendor decides 
> to save disk space, do not count on being informed of the decision before 
> information goes to the bit bucket. 
> 
> NANOG threads from last century are still available and do not require a 
> modern browser or, in fact, any browser.  
> 
> This is the genius of a group driven mailing list using basic RFC-compliant 
> content and transport: The business purpose of the mailing list is set by the 
> technical and social needs of NANOG and not by the financial wants of a 
> particular vendor. What is the value of the NANOG list archive? If it is 
> non-zero over time, do not make it dependent on the business practices of any 
> but NANOG itself.
> 
> James R. Cutler - james.cut...@consultant.com
> GPG keys: hkps://hkps.pool.sks-keyservers.net
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: Reinventing the wheel on a path to deeper learning

[Mark Tinka]

On 3/23/21 08:41, Cynthia Revström via NANOG wrote:



And while Discord is not at all a replacement for mailing lists in my 
opinion, I think it's important to realize that it (and other chat 
based things like it) have their place, especially among the younger 
groups.


Best advice we can all digest.

We can't fight what the kids are doing. They grew up with this 
(Internet) thing. Many of us lucked into it. The mindset and 
expectations couldn't be more different.


Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/23/21 08:22, Cynthia Revström via NANOG wrote:



Using a chat system they are already familiar with to ask more casual 
questions is a lot easier for some.
Especially if you are thinking of people who are just starting out, 
some of which will be part of the next generation of network engineers.


Many new, young engineers will also feel more comfortable posting on 
message apps because the group is small, well-known and reasonably 
private, i.e., they are less afraid about sounding clueless to the whole 
world, on record, forever.


Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/23/21 02:22, Tomasz Rola wrote:


I am not going to lament much, either. It is just how it goes. On the
brighter side, there will also be a minority, who will come to email
exactly because they will be aspiring power users. I think there will
always be some aspiring power users, so it is not going to be only bad.


There will be, but they will keep dwindling.

It's a serious concern for me, and a relevant topic to discuss as any 
other on a NOG list such as this. It's the future of network operations 
as (don't) know it.


Mark.

Re: OT: Re: Facebook and other walled gardens

[Mark Tinka]

On 3/22/21 19:22, Andy Ringsmuth wrote:


Sigh. It is probably a losing battle. You kids get off my grass!


You're right about that last part.

The kids are using what they feel gives them value and simplicity.

I'm old skool, but I'll be the first one to find a way to reach them via 
the tools they like to use. Because, for better or worse, the next batch 
of network engineers are in that pool, somewhere.


I mean, I've had to install one of those desktop web app things for 
Telegram, because a NOG list I'm on is far busier there than it is on 
the main mailing list. And it's a useful bunch of folk.


Mark.

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Mark Tinka]

On 3/22/21 17:55, Grant Taylor via NANOG wrote:



Part of my struggle is that I fail to see how it scales to poll 
multiple sites (or app icon notifications) when there are 10s, 100s, 
or even more things to check.  This is /exactly/ one of the reasons 
that I *strongly* /prefer/ email, it comes to me and gets filed in the 
proper folders. Where messages sit waiting to be read with the folder 
indicating that there are unread messages in it. I then go read them 
when it's convenient for me to do so.  But most importantly, I don't 
have to go check multiple -> many places.  The unread notification / 
count percolates up to one single location.


It's just a group of people on a "secure" messaging app.

Props if the app has a desktop version so you don't break your knuckles 
typing on your i-thing.


Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/22/21 15:14, Mike Hammett wrote:

I would love to have HTTP GUI that just does all of the dirty work. 
However, a sufficient number of people affiliated with that 
organization do indeed need to be able to CLI their way through the 
troubleshooting process for when the HTTP GUI inevitably fails 
(everything inevitably fails).


And this is where it tends to fall flat - when the GUI fails and an 
engineer can no longer setup a peering session with CLI.


The GUI is written in code, much of which will be via CLI. So we can't 
really run away from CLI, unless we are saying that CLI is reserved for 
those who use it to build the GUI, and not for those for whom the GUI is 
being built.


You can also implement a reasonable amount of automation without a GUI.

My goal is to babysit as few layers as possible.

Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/21/21 16:03, Noah wrote:



When we requested for feedback, them gen-z cried out loud for 
interactions to happen on some social media app through groups or 
channels, and since they are the target audience and the majority, we 
settled for discord and telegram which they actively engage on :-).


We still maintain the mailing list though and most announcement are 
done via it but things are changing hey


This is the real problem - there are many NOG discussions shifting on to 
mobile messaging apps (Signal and Telegram, specifically) in the 
developing markets, even when mailing lists exist.


Reasons abound as to why this is happening. The bottom line is that this 
is happening, and appears to be the preference.


There's a GUI for you...

Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/21/21 03:45, Eric Kuhnke wrote:



But it's another thing to consider that we have a whole new generation 
of people who /don't know and don't care/ what's going underneath the 
GUI and might not be able to do anything with the OS running on bare 
metal, if they have to.


If we intend to abstract away configuring devices to a GUI level only 
and not care about what's going on under the hood, then it's time for 
everyone to just run out and renew their MCSE certifications and buy 
Meraki subscriptions.


This has been a longstanding concern of mine with the next batch of 
network engineers.


The GUI may have a check-box that says "ATT Bit". It is there to click, 
or not click. But why it should or shouldn't be clicked is the looming 
danger we are setting up the new blood for.


Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/21/21 03:34, David Siegel wrote:



...not to mention that all mature networks are moving more towards GUI 
front ends for their automated network.  As the complexity of 
a network increases, CLI access becomes considerably more risky.


The idea that "real engineers use the CLI" is dinosaur thinking that 
will eventually land those with that philosophy out of a job.  Just my 
personal $.02 (though I'm certainly not alone in my opinion).


I wonder what those fancy GUI things are actually doing in the back-end.

I'm of the opposite view... front-end shiny GUI's are the risk. I'd 
babysit them before I let them leave the house. For a long time.


Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/21/21 01:52, Brielle wrote:


This is how I’m viewing a lot of this too.  It’s like the posts on stack 
exchange et al, Reddit, and various forums that are just closed with “fixed” 
and no details or follow up.

Kinda defeats the whole purpose of a mailing list with an archive since the 
same questions can come up again and again and no actual answers to the 
questions.


Well, people that post with a "reply off-list" often do so because they 
don't want to get blamed for impacting the SNR.


I feel reasonably confident to hazard that if this fear did not exist, 
information flow would be a lot more transparent.


Mark.

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Mark Tinka]

On 3/20/21 23:43, Tom Beecher wrote:


A large portion of these emails lately have contained some variation
of 'contact me off list'. How does that provide any benefit to the
community? Is anyone else in the community getting any information
about what providers may be on a pathway that would help them? They
are not.


I don't see an issue with that. Off-list contact is about keeping 
exchanges that may not be of material interest to the majority at a 
minimum. I've often found others who want to know as well chime in 
stating so.


During these times that we can't travel to conferences, the social 
capital from this and similar lists is worth its weight in words.


Mark.