Re: jon postel

[Elmar K. Bins]

joey@gmail.com (Joseph) wrote:

> A good book on the topic of the early internet is "Where Wizards Stay Up
> Late" by Katie Hafner and Matthew Lyon.

+1

The only thing I have to criticize is that the book has way too few pages.

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service)

[Alex Band]

Thanks a lot for your overview Christopher. We’re very happy that ARIN is 
working to address the concerns expressed by the community about the Relying 
Party Agreement and TAL distribution. 

Based on earlier conversations on this list [1], NLnet Labs intended to ship a 
new release of the free, open-source Routinator Relying Party software on short 
notice. Other Relying Party vendors are planning similar steps [2]. However, 
the remaining concern you voiced in the third paragraph of your e-mail has 
paused our effort. 

The planned Routinator release would leverage the possibility to include the 
ARIN TAL and no longer require explicit consent to the RPA. As no additional 
steps are needed after installation this greatly simplifies TAL management, 
which will be especially advantageous for deployment in unattended environments:

https://github.com/NLnetLabs/routinator/pull/796 (code)
https://routinator--796.org.readthedocs.build/en/796/configuration.html 
(documentation)

We hope ARIN will be able to clarify the current RPA text to address your third 
paragraph, so that we are in a position to release Routinator with one fewer 
hurdle to adoption.

Kind regards,

Alex

[1] https://seclists.org/nanog/2022/Sep/212
[2] https://github.com/cloudflare/cfrpki/issues/112 


> On 16 Oct 2022, at 23:52, Christopher S. Yoo  wrote:
> 
> As the coauthors of the 2019 NSF-supported report that contributed to the 
> current momentum toward overcoming the barriers RPKI adoption, a prior 
> posting asked for our assessment of the changes.  Our apologies that we won’t 
> be able to join you at this NANOG.  We hope to put together some type of 
> program in Atlanta in February.
>  We would say that intent of ARIN’s Sept. 26 and 29 updates ((link and link) 
> to the RPA—to permit distribution of the TAL without signing the 
> RPA—represent positive steps to address the most significant concern that we 
> raised.  In particular, the language in Section 5 added by the Sept. 29 
> update explicitly stating, “Notwithstanding the foregoing, You are 
> specifically allowed to publicly distribute the ARIN TAL, including by 
> embedding the ARIN TAL in relying party software,” appears to authorize 
> including ARIN’s TAL in all distributions of validator software, and RPKI 
> adopters would no longer need to download ARIN’s TAL from its website.  If 
> effective, this is would remove the single most important legal obstacle to 
> broader use of RPKI.
>  The continuing wrinkle is that Section 5 authorizes distribution of ORCP 
> services (including the ARIN TAL) only as permitted by the ORCP service 
> terms.  Section 9 requires third parties receiving this information either to 
> have agreed to the RPA or to have entered into an agreement with the 
> distributing party that includes the key terms of the RPA.  That would 
> suggest that anyone distributing validator software with ARIN’s TAL must 
> ensure that the recipient has agreed to the RPA in order to avoid violating 
> the ORCP service terms.  Although open source typically relies on licenses 
> that are good against all users regardless of knowledge or assent (because 
> they sound in property instead of contract), assent to the terms of the RPA 
> could be incorporated into the distribution process, perhaps in the same 
> manner used for other certificate authorities, which typically have terms of 
> use.
>  Another comment on this thread asked if ARIN has now addressed the other 
> issues raised by our report.  It is our assessment that ARIN has adequately 
> addressed three of our other concerns, has announced its intention to address 
> two others, and partially addressed one.
>  The three issues that ARIN has adequately addressed include:
>  
> • Dropping provision of the RSA requiring legacy address holders to 
> acknowledge ARIN’s property rights in IP addresses:  dropped in update to 
> LRSA dated Sept. 12, 2022 (link).
> • Drop provision of RPA prohibiting sharing of RPKI-derived data in a 
> machine-readable format:  authorized for informational purposes by update to 
> RPA dated Oct. 21, 2019 (link); authorized for routing purposes by update to 
> RPA dated Sept. 26, 2022 (link).
> • Better dissemination of best practices to the community:  addressed by 
> expansion of RPKI training at FISPA, WISPA, CaribNOG, and NANOG.
>  ARIN has its intention to address two of our other concerns in the near 
> future:
>  
> • Better disclosure to government agencies of ARIN’s willingness to waive 
> insemination and choice of law clauses when barred by law:  likely to be 
> addressed by ARIN’s announced plans to create webpage specifically for 
> governments.
> • Better disclosure of operational practices, such as uptime, update 
> frequency, and response expectations:  likely to be addressed further by 
> planned update to certificate practices statement.
>  It partially addressed one concern that we raised.
>  
> • Dropping blanket indemnification cla

Re: jon postel

[John Curran]

RFC 2468 is brief but captures the both pleasure of working with Jon and his 
selfless spirit 
in pursuit of a better Internet. 

/John

> On 16 Oct 2022, at 8:28 PM, Daniel Sterling  wrote:
> 
> One of the best things about this list is first hand accounts of our internet 
> lore
> 
> Does anyone have any stories about working with or near John they would like 
> to share with the list? It would definitely make my day to hear more about 
> the early internet
> 
> Thanks,
> Dan

2:45 apple's talk on responsiveness tuesday

[Dave Taht]

It's "fun" to run their new go based responsiveness test on  the
conference wifi: https://github.com/network-quality/goresponsiveness -
especially
with two or more people at the same time. Hotel wifi is *even* more
fun. in-Bar 5G comparing it (or the new speedtest app which is also
measuring roughly the same things) to 4G, oh my! Would love it if more
folk tried it and shared data!

Also: https://github.com/Zoxc/crusader is shaping up, and has a
staggered start test now.

And of course, there's always flent.

I'm not at this nanog, tho I wish I was.


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC

Re: jon postel

[Grant Taylor via NANOG]

On 10/16/22 8:28 PM, Joseph wrote:
A good book on the topic of the early internet is "Where Wizards Stay Up 
Late" by Katie Hafner and Matthew Lyon. A large part of the book covers 
happenings at Bolt Beranek and Newman, and there are plenty of mentions 
of Jon Postel.


+1 (with an extremely large value of one)

I have (re)read Where Wizards Stay Up Late /and/ recommended it to many 
people many different times.


In my not so humble opinion, Where Wizards Stay Up Late should be 
required reading for anyone wanting to learn about the history / 
development of the ARPAnet and the Internet.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: jon postel

[Carsten Bormann]

On 2022-10-17, at 16:57, Grant Taylor via NANOG  wrote:
> 
> In my not so humble opinion, Where Wizards Stay Up Late should be required 
> reading for anyone wanting to learn about the history / development of the 
> ARPAnet and the Internet.

That said, it would be a worthwhile project to collect the places in which this 
source can be supplemented with additional information (a.k.a. grains of salt).

Grüße, Carsten

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Douglas Fischer]

I already had this idea, I even implemented it in the desperate time of the
512K "bug".
And with that I can tell you:
Do not do it! You will be bothered!

But if you want to go this way, what I can recommend is to try not to put
routes in the FIB that match your Default.

Talking about having a default route other than /dev/null is already a
problem at first...
Because a Transit Provider is not expected to use the Default route.
But I'm not even going to get into that (many flames will arise).

If you really decide to use a default route and choose what will not and
what will not apply to the FIB, you must be prepared for a certain
complexity in these choices.
And the more Peers and DFZ views you have, the more complex it will be.

In a very simplified hypothetical example of dual-homed DFZ, take the best
routes from link B, and leave the default by link A.

There are even tools that, comparing flow analysis and routes exported from
the RIB, "choose" the routes with more matching packages, and apply that
for you.
But thinking in this way, the transition to the dark side of the force is
already beginning to be made. Walking through the valley of death until
arriving in the land of the Route Optimizers.

My memory is not helping me...
But I think the name of one of the projects that did this magic was rt-flow
or flow-rt. Something like.

Em seg., 10 de out. de 2022 às 12:01, Edvinas Kairys <
edvinas.em...@gmail.com> escreveu:

> Hello,
>
> We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has
> 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it
> will be not enough - so we're thinking to deny all /24s to save the memory.
> What do you think about that approach - I know it could provide some
> misbehavior. But theoretically every filtered /24 could be routed via
> smaller prefix /23 /22 /21 or etc. But of course it could be a situation
> when denied /24 will not be covered by any smaller prefix.
>
> What do you think about this approach ?
>
> Also maybe you know - some advices for edge routers that have at least
> 8x100G interfaces and "good" memory for prefix count ? Thanks
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: jon postel

[Grant Taylor via NANOG]

On 10/17/22 10:54 AM, Carsten Bormann wrote:
That said, it would be a worthwhile project to collect the places 
in which this source can be supplemented with additional information 
(a.k.a. grains of salt).


Agreed.

I believe there is much discussion to this effect on the Internet 
History mailing list.


Link - Internet-history Info Page
 - https://elists.isoc.org/mailman/listinfo/internet-history



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: jon postel

[Dave Taht]

That book needs a sequel.

+10 on the internet history mailing list also.

Looking for historical AS1239 Sprintlink on-net site lists, POP lists, etc

[Eric Kuhnke]

If anyone has on-net site/POP lists for AS1239 that are at least 8-10 years
old or older, I'm wondering if I could get a copy.

Obviously nothing that anybody signed an NDA for, maybe some people out
there have some spreadsheets or text files that were shared by Sprint sales
persons many years ago.

This is related to some information I am gathering to improve documentation
of what will apparently become part of Cogent in the Pacific Northwest,
with T-Mobile's sale of sprint's wireline business.

-Eric

Re: jon postel

[Greg Skinner via NANOG]

Jon Postel participated in many online forums such as the tcp-ip mailing list.  
To access them, I’ve been using the archives at ban.ai 
, but I can’t 
access them currently.  They’re also available via Google Groups 
, but unfortunately there’s 
a lot of spam there.  You could also visit the IETF mailing list archives 
 that go back to 1992.

—gregbo

On Oct 16, 2022, at 5:28 PM, Daniel Sterling  wrote:

> One of the best things about this list is first hand accounts of our
> internet lore
> 
> Does anyone have any stories about working with or near John they would
> like to share with the list? It would definitely make my day to hear more
> about the early internet
> 
> Thanks,
> Dan