Re: jon postel

[Joseph]

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

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

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.

Joseph

Re: jon postel

[Randy Bush]

> 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

somewhere around i have a protocol violation ticket he issued.

---

Who says that routing unallocated address space is ungood?  -- Randy Bush
Routing unallocated address space is ungood!  -- Jon Postel

randy

Re: jon postel

[Daniel Sterling]

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

On Sun, Oct 16, 2022, 8:01 PM Nathan Angelacos  wrote:

>
> >
> > Early unix had a similar philosophical debate. Everything is a simple
> > file (including most devices), make commands which do one thing and
> > do it well so they can be connected together in new ways (an almost
> > prescient view on the ubiquity of multi-cpu/core systems), when in
> > doubt generalize and let the user specialize for their needs, don't
> > try to guess everything your program will be used for.
>
>
>
> Oh. you mean SaaS?  or WebSockets?  or REST? or :)
>
> I remember an old guy I worked with.   We were decommissioning our
> Prime for this new thing called "Novell 286"
>
> He said "The computer industry is like the car industry in the 50's.
> We add more grille, more fenders, more wings.   But it is still a car."
>
>

Re: jon postel

[Nathan Angelacos]

> 
> Early unix had a similar philosophical debate. Everything is a simple
> file (including most devices), make commands which do one thing and
> do it well so they can be connected together in new ways (an almost
> prescient view on the ubiquity of multi-cpu/core systems), when in
> doubt generalize and let the user specialize for their needs, don't
> try to guess everything your program will be used for.



Oh. you mean SaaS?  or WebSockets?  or REST? or :)

I remember an old guy I worked with.   We were decommissioning our
Prime for this new thing called "Novell 286"

He said "The computer industry is like the car industry in the 50's.  
We add more grille, more fenders, more wings.   But it is still a car."

Re: jon postel

[bzs]

On October 16, 2022 at 14:18 ra...@psg.com (Randy Bush) wrote:
 > my favorite is
 > 
 > It's perfectly appropriate to be upset.  I thought of it in a slightly
 > different way--like a space that we were exploring and, in the early days,
 > we figured out this consistent path through the space: IP, TCP, and so on.
 > What's been happening over the last few years is that the IETF is filling
 > the rest of the space with every alternative approach, not necessarily any
 > better.  Every possible alternative is now being written down.  And it's not
 > useful.  -- Jon Postel

Early unix had a similar philosophical debate. Everything is a simple
file (including most devices), make commands which do one thing and do
it well so they can be connected together in new ways (an almost
prescient view on the ubiquity of multi-cpu/core systems), when in
doubt generalize and let the user specialize for their needs, don't
try to guess everything your program will be used for.

Then we got: POP-QUIZ! Name which letters a-z which aren't options to
ls?

Granted computing was more data processing than UI back then, but even
desktop apps like word processing had this style (e.g., a separate
program to format math equations or tables which could be piped into
from the general word processing program in a pipeline, and another to
do final formatting for the printing device.)

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: jon postel

[Jay Hennigan]

On 10/16/22 15:55, Nathan Angelacos wrote:


I got on the "interwebs" just before Al Gore invented the internet (no
political statement, just that is the way it was back then.)   15 3.5"
floppy disks, a 33Mhz 486, slackware, (and a really reliable USRobotics
modem.)


About the same time for me, may have been a 286. I remember fiddling 
with init strings and Trumpet Winsock.


It wasn't really the interWEBs then. The web was a small part of the 
experience for me. USENET, email, FTP, Archie, gopher with a splash of 
www for flavor.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: jon postel

[Nathan Angelacos]

On Sun, 2022-10-16 at 13:23 -0700, Randy Bush wrote:
> it's been 24 years, and we still live in his shadow and stand on his
> shoulders.  we try not to stand on his toes.
> 
> randy

I got on the "interwebs" just before Al Gore invented the internet (no
political statement, just that is the way it was back then.)   15 3.5"
floppy disks, a 33Mhz 486, slackware, (and a really reliable USRobotics
modem.)

I found this thing called "RFC"... and Jim Postel was a man I really
wanted to meet.  

Thanks, Randy, for reminding me of the shoulders I stand on.

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)

[Christopher S. Yoo]

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 clause in favor of disclaimer of 
warranties and liability:  revised RPA to exclude indemnification for ARIN's 
gross negligence by update to RPA dated Oct. 21, 2019 
(link).

We hope these comments are helpful and look forward to continuing to work with 
the community on removing the remaining legal barriers to RPKI adoption.

Christopher Yoo (on behalf of myself and David Wishnick)

Re: jon postel

[Dave Taht]

On Sun, Oct 16, 2022 at 2:21 PM Randy Bush  wrote:
>
> my favorite is
>
> It's perfectly appropriate to be upset.  I thought of it in a slightly
> different way--like a space that we were exploring and, in the early days,
> we figured out this consistent path through the space: IP, TCP, and so on.
> What's been happening over the last few years is that the IETF is filling
> the rest of the space with every alternative approach, not necessarily any
> better.  Every possible alternative is now being written down.  And it's not
> useful.  -- Jon Postel

I wish I'd met him. I know I would have liked him a lot. We wear the
same sandals.

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

[Randy Bush]

my favorite is

It's perfectly appropriate to be upset.  I thought of it in a slightly
different way--like a space that we were exploring and, in the early days,
we figured out this consistent path through the space: IP, TCP, and so on.
What's been happening over the last few years is that the IETF is filling
the rest of the space with every alternative approach, not necessarily any
better.  Every possible alternative is now being written down.  And it's not
useful.  -- Jon Postel

Re: jon postel

[Noah]

On Sun, 16 Oct 2022, 23:24 Randy Bush,  wrote:

> it's been 24 years, and we still live in his shadow and stand on his
> shoulders.  we try not to stand on his toes.
>

"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel



> randy
>

./noah

>

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

[Owen DeLong via NANOG]

This situation isn’t helped by RIR policies that require you to announce the 
aggregate in region even if the more specifics are scattered around the world. 

The whole territorial exclusivity game played by some RIRs may well cause more 
harm than good at this point.

Yes, I realize this is a reversal of my previous views on the subject. I’m 
becoming more aware of more circumstances in which this idea is fraught and 
causing problems for legitimate users more than for policy forum shoppers and 
leasing companies. 

Owen


> On Oct 16, 2022, at 01:01, Matthew Petach  wrote:
> 
> 
> 
> 
>> On Tue, Oct 11, 2022 at 7:03 PM William Herrin  wrote:
>> On Tue, Oct 11, 2022 at 5:32 PM Matthew Petach  wrote:
>> [...]
>> All TCP/IP routing is more-specific route first. That is the expected
>> behavior. I honestly don't fathom your view that BGP is or should be
>> different from that norm. If the origin of a covering route has no
>> problem sinking the traffic when the more-specific is offline, I don't
>> see the problem. You shouldn't be taking them offline with route
>> filtering.
> 
> *facepalm*
> 
> Right.  That's the entire point I started off the subthread with.
> 
> The problem lay with an organization that *did* have a problem
> sinking the traffic when the more-specific was not available.
> They had chunked up their allocation into smaller pieces 
> which were distributed to different island locations with no 
> internal network connectivity to the island sites.
> 
> They were announcing a covering prefix for all the more 
> specifics, where the covering less specific announcement 
> had no reachability to the more specifics; so when a network 
> filtered out the more specifics, the traffic fell on the floor, because 
> it was sent to a location that was announcing the supernet that 
> had no reachability to the correct destination. 
> 
> Their assumption that *everyone* would hear the more specifics, 
> and thus the traffic would flow to the right island location was the 
> "failure to understand BGP" that I was commenting on, and noting 
> that while it is entirely correct to decide if you want to filter prefixes 
> of an arbitrary length from entering your network, you may discover 
> in the process that other networks that do not understand BGP and 
> routing in general may complain that you have Broken The Internet(tm)
> by doing so.
> 
> Assuming that your announcement of more specifics will always pull 
> traffic away from a less-specific announcement is overly-optimistic.
> While it may *often* work, you should still be prepared to deal with 
> traffic arriving at your least-specific announcement as well.
>   
> This turned out to be something that not every network on the
> Internet fully grasps, and my original message was warning that 
> filtering on /24s would potentially bring complaints from networks 
> like those.
> 
> It took a roundabout path, but I'm glad we eventually both ended 
> up at the same place.   :)
> 
> Thanks!
> 
> Matt
> 

jon postel

[Randy Bush]

it's been 24 years, and we still live in his shadow and stand on his
shoulders.  we try not to stand on his toes.

randy

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

[William Herrin]

On Sun, Oct 16, 2022 at 1:01 AM Matthew Petach  wrote:
> Their assumption that *everyone* would hear the more specifics,
> and thus the traffic would flow to the right island location was the
> "failure to understand BGP" that I was commenting on, and noting
> that while it is entirely correct to decide if you want to filter prefixes
> of an arbitrary length from entering your network, you may discover
> in the process that other networks that do not understand BGP and
> routing in general may complain that you have Broken The Internet(tm)
> by doing so.

Matthew,

We studied aggregation to death back in the IRTF Routing Research
Group. The bottom line is that you can aggregate at the source and you
can aggregate at the BGP leaf nodes (transits, no downstreams or
peers) but RIB aggregation anywhere else in the interdomain protocol
breaks the network. You may wish that you could filter those
more-specific prefixes but you are quite mistaken: that is NOT how BGP
works. In point of fact, we couldn't come up with any theoretical
interdomain routing protocol in which it was possible to filter
conventionally legitimate prefixes and have the system operate
reasonably. As near as we could determine, no such thing exists.

When I design a covering route, I include a VPN to the site with the
more-specific to catch the occasional misrouted packet. But then I
also parse the TCP SYN packets and reduce the MSS because there are
knuckleheads which think they can filter ICMP and have TCP merrily
work without functional path MTU discovery. Those folks are wrong too,
TCP doesn't work the way they think, but I'd rather keep the customer
than win the argument.

Regards,
Bill Herrin


>
> Assuming that your announcement of more specifics will always pull
> traffic away from a less-specific announcement is overly-optimistic.
> While it may *often* work, you should still be prepared to deal with
> traffic arriving at your least-specific announcement as well.
>
> This turned out to be something that not every network on the
> Internet fully grasps, and my original message was warning that
> filtering on /24s would potentially bring complaints from networks
> like those.
>
> It took a roundabout path, but I'm glad we eventually both ended
> up at the same place.   :)
>
> Thanks!
>
> Matt
>


-- 
For hire. https://bill.herrin.us/resume/

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

[Matthew Petach]

On Tue, Oct 11, 2022 at 7:03 PM William Herrin  wrote:

> On Tue, Oct 11, 2022 at 5:32 PM Matthew Petach 
> wrote:
> [...]
> All TCP/IP routing is more-specific route first. That is the expected
> behavior. I honestly don't fathom your view that BGP is or should be
> different from that norm. If the origin of a covering route has no
> problem sinking the traffic when the more-specific is offline, I don't
> see the problem. You shouldn't be taking them offline with route
> filtering.
>

*facepalm*

Right.  That's the entire point I started off the subthread with.

The problem lay with an organization that *did* have a problem
sinking the traffic when the more-specific was not available.
They had chunked up their allocation into smaller pieces
which were distributed to different island locations with no
internal network connectivity to the island sites.

They were announcing a covering prefix for all the more
specifics, where the covering less specific announcement
had no reachability to the more specifics; so when a network
filtered out the more specifics, the traffic fell on the floor, because
it was sent to a location that was announcing the supernet that
had no reachability to the correct destination.

Their assumption that *everyone* would hear the more specifics,
and thus the traffic would flow to the right island location was the
"failure to understand BGP" that I was commenting on, and noting
that while it is entirely correct to decide if you want to filter prefixes
of an arbitrary length from entering your network, you may discover
in the process that other networks that do not understand BGP and
routing in general may complain that you have Broken The Internet(tm)
by doing so.

Assuming that your announcement of more specifics will always pull
traffic away from a less-specific announcement is overly-optimistic.
While it may *often* work, you should still be prepared to deal with
traffic arriving at your least-specific announcement as well.

This turned out to be something that not every network on the
Internet fully grasps, and my original message was warning that
filtering on /24s would potentially bring complaints from networks
like those.

It took a roundabout path, but I'm glad we eventually both ended
up at the same place.   :)

Thanks!

Matt