Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Yang Yu]

> > Why not publish RFC8805 Geofeed directly in inetnum remarks section?
>
> for some flat fan out last kilometer providers that could be the
> inetnum: object from hell.  there are global providers which segment
> large prefixes over diverse areas.  etc.
>
> i doubt the rpsl providers would like multi-megabyte inetnum:s.  rpsl
> providers already throttle in defense.

I was thinking about geofeed on customer assignment objects for
networks that manage their own objects
(https://www.afrinic.net/press/214-creating-customer-assignments),
only 1 line of geofeed remark needed on each object (more objects
should be created if used in different locations).
But not all RIR have customer assignment objects (can't create
sub-assignment objects on ARIN direct assignment resources). HTTP feed
does make sense when customer assignment object is not an option.

> we are not expecting these lookups to be done frequently.  i agree that
> would hammer servers, both rpsl and geofeed.  do you have stronger words
> to suggest than
>
>5.  Operational Considerations
>...
>An entity fetching geofeed data through these mechanisms MUST NOT do
>frequent real-time look-ups to prevent load on RPSL servers.  And do
>not fetch at midnight, because everyone else may.
>
> i agree that we do not want the DDoS that is currently happening to RPKI
> publication servers.  perhaps explicit time limits, e.g daily?
I am more concerned about clients having to make large amount of HTTP
requests if this field gets widely used, maybe some clients can just
read input like RPKI VRP (https://rpki.cloudflare.com/rpki.json)
Client can try to keep track of geofeed URLs and only download the
file during iteration, despite the same file referenced by multiple
objects.

>
> > How to handle other stuff that might exist in remarks field? Or the
> > draft would explicitly require Geofeed to be in its own remarks field?
>
> the document tries to be explicit that it is the latter.  that is the
> intent of
>
>3.  inetnum: Class
>...
>the syntax of a Geofeed remarks: attribute which contains a URL of a
>geofeed file.  The format MUST be as in this example, "remarks:
>Geofeed " followed by a URL which will vary.  ---> probably add 
> clarification here that Geofeed MUST be the only value in this particular 
> remarks field, nothing before/after it
>
>inetnum: 192.0.2.0/24 # example
>remarks: Geofeed https://example.com/geofeed.csv
>
>Any particular inetnum: object MAY have, at most, one geofeed
>reference.
>
> is there more specific wording that would help clarify?
see above


Yang

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Sean Donelan]

On Fri, 11 Sep 2020, Matt Erculiani wrote:

Linking relevant past thread about devices that don't alert for
emergencies and, of course, a heated debate on if they should:
https://mailman.nanog.org/pipermail/nanog/2019-March/199721.html



Yep.  I'm not naive.  I keep saying something, because one day it will 
matter, when the CEOs claim no one said anything.


I fully expect the CEOs of Alphabet, Amazon and Apple in some future 
congressional hearing, after a major disaster, will follow the same 
script as previous CEOs from automotive, tobacco, chemical, etc. 
industries; that they are shocked and saddened, but no one ever said 
something. Later, in past cases, it will turn out someone did say 
something but were ignored.


True, about 100 clear-channel 50,000 watt AM radio stations still carry 
emergency alerts. But its not the 1950s anymore. That's not where most 
people spend their attention span. People are using streaming devices 
now.



There are cases, usually as a result of individual engineer's 
bad experience during a crisis, such as Google's SOS Alerts 
product for people already aware and actively looking for more 
information about a crisis.


https://blog.google/products/search/mapping-wildfires-with-satellite-data/

  "Ten years ago, I was inside the Google office in Haifa, Israel when the
  devastating Carmel Mountain fire started blazing not far from us. The
  team started searching the web to learn more. And while we did find
  some details confirming what we already knew—a large fire was taking
  place outside of our door—we experienced a potentially life-impacting
  information gap. "

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Sat, Sep 12, 2020 at 4:43 PM Randy Bush  wrote:

> hi ca
>
>
>
> > I gave your I-D a try in the real world, and it does not work with a
>
> > major player.
>
>
>
> i.e. arin and radb, your region, which does not do rpsl as others do.
>
> we know this, which is why the OP $subjest was
>
>
>
>   "how would draft-ymbk-opsawg-finding-geofeeds work in noam?"
>
>
>
> > I thought you might know this, and could have saved me a few hours of
>
> > tinkering...
>
>
>
> yikes!  did not mean to send you down a rabbit hole.  apologies.  i had
>
> naïvely assumed the $subject would have warned you.
>

Ok, then i can reply to the subject.

It does not work

There are likely 100 ways to do this that do work (dns, peeringdb, other
rpsl comment fields ...), and you choose the one that does not.

Try harder.

CB


>
>
> > But to help others along, inetnum does not work at RADB.  Web form,
>
> > email, nada.
>
>
>
> my personal guess is that radb might choose to adapt, similarly to
>
> irrd's thoughts.  but arin?  ha ha.
>
>
>
> so my guess is an open source simple shim to adapt the the noam
>
> snowflakiness.  i.e. be able to consume arin nethandle and radb
>
> comments.
>
>
>
> but i am hoping that others might have brighter ideas.
>
>
>
> randy
>
>

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

hi ca

> I gave your I-D a try in the real world, and it does not work with a
> major player.

i.e. arin and radb, your region, which does not do rpsl as others do.
we know this, which is why the OP $subjest was

  "how would draft-ymbk-opsawg-finding-geofeeds work in noam?"

> I thought you might know this, and could have saved me a few hours of
> tinkering...

yikes!  did not mean to send you down a rabbit hole.  apologies.  i had
naïvely assumed the $subject would have warned you.

> But to help others along, inetnum does not work at RADB.  Web form,
> email, nada.

my personal guess is that radb might choose to adapt, similarly to
irrd's thoughts.  but arin?  ha ha.

so my guess is an open source simple shim to adapt the the noam
snowflakiness.  i.e. be able to consume arin nethandle and radb
comments.

but i am hoping that others might have brighter ideas.

randy

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

yang,

> Why not publish RFC8805 Geofeed directly in inetnum remarks section?

for some flat fan out last kilometer providers that could be the
inetnum: object from hell.  there are global providers which segment
large prefixes over diverse areas.  etc.

i doubt the rpsl providers would like multi-megabyte inetnum:s.  rpsl
providers already throttle in defense.

> Then there is no more need to host HTTP server. 1 HTTP request per
> inetnum/inetnum6 object seems a bit tedious.

we are not expecting these lookups to be done frequently.  i agree that
would hammer servers, both rpsl and geofeed.  do you have stronger words
to suggest than

   5.  Operational Considerations
   ...
   An entity fetching geofeed data through these mechanisms MUST NOT do
   frequent real-time look-ups to prevent load on RPSL servers.  And do
   not fetch at midnight, because everyone else may.

i agree that we do not want the DDoS that is currently happening to RPKI
publication servers.  perhaps explicit time limits, e.g daily?

> How to handle other stuff that might exist in remarks field? Or the
> draft would explicitly require Geofeed to be in its own remarks field?

the document tries to be explicit that it is the latter.  that is the
intent of

   3.  inetnum: Class
   ...
   the syntax of a Geofeed remarks: attribute which contains a URL of a
   geofeed file.  The format MUST be as in this example, "remarks:
   Geofeed " followed by a URL which will vary.

   inetnum: 192.0.2.0/24 # example
   remarks: Geofeed https://example.com/geofeed.csv

   Any particular inetnum: object MAY have, at most, one geofeed
   reference.

is there more specific wording that would help clarify?

note that use of the remarks: attribute is for rpsl services which do
not implement the specific geofeed: attribute.  [ e.g. see the PR for
IIRDv4 https://github.com/irrdnet/irrd/issues/396 ]

> Specific to the north american RIR, NetHandle is in registry (not in
> irr) abd bulk access requires application
> (https://www.arin.net/reference/research/bulkwhois/#accessing-bulk-whois-data),
> download requires cookies and takes ~10 mins. imo this could be made
> easier like https://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz

there are a lot of things arin could make life more easy for operators.
and cash could fall from the sky.

> NetHandle is not exactly inetnum (e.g. comments instead of remarks
> field, different prefix format). Would the RIR provide converted
> inetnum objects or the users would be expected to handle this?

i currently fear a custom stub to do just this for consumers of north
american data.

randy

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Yang Yu]

On Fri, Sep 11, 2020 at 1:48 PM Randy Bush  wrote:
>
> would folk familiar with the north american RIR and IRR registries be
> kind enough to suggest how this might adapt?  thanks.
>

Hi Randy,

Why not publish RFC8805 Geofeed directly in inetnum remarks section?
Then there is no more need to host HTTP server. 1 HTTP request per
inetnum/inetnum6 object seems a bit tedious.

How to handle other stuff that might exist in remarks field? Or the
draft would explicitly require Geofeed to be in its own remarks field?

Specific to the north american RIR, NetHandle is in registry (not in
irr) abd bulk access requires application
(https://www.arin.net/reference/research/bulkwhois/#accessing-bulk-whois-data),
download requires cookies and takes ~10 mins. imo this could be made
easier like https://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz

NetHandle is not exactly inetnum (e.g. comments instead of remarks
field, different prefix format). Would the RIR provide converted
inetnum objects or the users would be expected to handle this?


Yang

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Sat, Sep 12, 2020 at 1:13 PM Randy Bush  wrote:

> hi camron
>
> sad to say, the days of faxing around number assigments have passed.
> the kiddie googlers who wrote the geofeeds rfc probably have not even
> seen a fax machine.  they just did not like having a hundred gnomes in
> the basement dealing with everybody's formats.  given silicon valley
> housing costs, gnome armies do not scale well.  and, imiho, the format
> they developed is sufficiently boring that it might work.
>
> ten thousand providers emailing each other spreadsheets is not very
> pretty or reliable at global scale.  the plague is teaching normal folk
> the concept of exponential.
>
> so where A *finds* B's geofeed data is an ugly issue.  i agree that rpsl
> sucks.  like democracy, it may suck less than the alternatives.  but if
> you have a better suggestion, puhleeze!
>
> > 2. Why can’t arin just provide me a web portal to add city / state
> > info in my already existing rpki roa form?
>
> and then where do those data go?  you wanna go through the ietf process
> of putting it in the rpki, which has no 'remarks' as an intermediate
> hack?
>
> and 10,000 consumers of the data would have to sign arin legal papers.
> and arin is just one corner of a large world and becoming less and less
> relevant.
>
> as to using zip codes; aside from the international issues, in many
> locales postal codes are sufficiently specific to reveal personal
> identity.  or at least this is why some geofeed designers told me they
> avoided postal codes.  but this document is not about those choices
> anyway; geofeed file format was assumed.
>
> i hope you noted that the rpki-based signing is entirely optional.  i
> certainly do not sign my geofeed files, and am not aware of any other
> deployment of this tech which does.
>
> randy
>

Hi Randy,

Just business in this email.

I gave your I-D a try in the real world, and it does not work with a major
player.  I thought you might know this, and could have saved me a few hours
of tinkering... But to help others along,  inetnum does not work at RADB.
Web form, email, nada.

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

hi camron

sad to say, the days of faxing around number assigments have passed.
the kiddie googlers who wrote the geofeeds rfc probably have not even
seen a fax machine.  they just did not like having a hundred gnomes in
the basement dealing with everybody's formats.  given silicon valley
housing costs, gnome armies do not scale well.  and, imiho, the format
they developed is sufficiently boring that it might work.

ten thousand providers emailing each other spreadsheets is not very
pretty or reliable at global scale.  the plague is teaching normal folk
the concept of exponential.

so where A *finds* B's geofeed data is an ugly issue.  i agree that rpsl
sucks.  like democracy, it may suck less than the alternatives.  but if
you have a better suggestion, puhleeze!

> 2. Why can’t arin just provide me a web portal to add city / state
> info in my already existing rpki roa form?

and then where do those data go?  you wanna go through the ietf process
of putting it in the rpki, which has no 'remarks' as an intermediate
hack?

and 10,000 consumers of the data would have to sign arin legal papers.
and arin is just one corner of a large world and becoming less and less
relevant.

as to using zip codes; aside from the international issues, in many
locales postal codes are sufficiently specific to reveal personal
identity.  or at least this is why some geofeed designers told me they
avoided postal codes.  but this document is not about those choices
anyway; geofeed file format was assumed.

i hope you noted that the rpki-based signing is entirely optional.  i
certainly do not sign my geofeed files, and am not aware of any other
deployment of this tech which does.

randy

RE: sr - spring - what's the deal with 2 names

[Adrian Farrel]

>> Does anyone know the scope on why we have 2 names for this ?
>
> SPRING is the IETF working group name - Source Packet Routing in Networking
> Segment Routing is under SPRING

Yeah, sorry, this was my fault. Gotta have a catchy name.

As to "SPRINGv4" as others have said, this is not a recognised term in the 
IETF. I can think of it meaning a number of things (ranging from a private 
invention of SRv4, up to RFC 8663). You're going to have to check with the 
vendor using the term to find out what they mean, and possibly why they are 
using a new term instead of an existing one.

Cheers,
Adrian

RE: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Chuck Church]

Isn’t this a better topic for CNet as opposed to NANOG?

 

Chuck

 

From: NANOG  On Behalf Of 
ITechGeek
Sent: Friday, September 11, 2020 4:12 PM
To: nanog@nanog.org
Subject: Re: Wildfires: Reminder smart devices don't include emergency warnings 
while streaming

 

At least cell phones have a reliable way to know where they are at any given 
moment.  Would you really trust providers sending out emergency notifications 
based on something like GeoIP or based on the zipcode on the account?

 

---

-ITG (ITechGeek)  |  i...@itechgeek.com  

i...@secure.itg.nu   (Protonmail) (Fingerprint: 
7d1a160f)

https://keybase.io/itechgeek  |  https://itg.nu/

Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: 
http://fb.me/Jbwa.Net

 

 

On Fri, Sep 11, 2020 at 3:49 PM Sean Donelan mailto:s...@donelan.com> > wrote:

On Fri, 11 Sep 2020, William Herrin wrote:
> tl;dr: keep your cell phone on and with you 'cause only a few things
> get emergency alerts and only when they're turned on.

You sound like the CTIA in the 2000s when it was opposed to requiring 
emergency alerts on cell phones.  "Its unnecessary to require cell phones 
have emergency alerts, because people get emergency alerts other ways."

The problem was all the consumer electronic industry groups always point 
at "someone else."  The cable industry said it was unnecessary in the 
1980s because local TV stations had emergency alerts.  The TV industry 
said it was unnecessary in the 1970s because local radio stations had 
emergency alerts.  Etc. etc. etc.

The reason your cell phone has emergency alerts, is the FCC required them.

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Fri, Sep 11, 2020 at 1:49 PM Randy Bush  wrote:

> would folk familiar with the north american RIR and IRR registries be
>
> kind enough to suggest how this might adapt?  thanks.
>
>
>
> A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
>
> has been successfully submitted by Randy Bush and posted to the
>
> IETF repository.
>
>
>
> Name:   draft-ymbk-opsawg-finding-geofeeds
>
> Revision:   02
>
> Title:  Finding and Using Geofeed Data
>
> Document date:  2020-09-11
>
> Group:  Individual Submission
>
> Pages:  16
>
> URL:
> https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
>
> Htmlized:
> https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02
>
>
>
> Abstract:
>
>This document describes how to find and authenticate geofeed data.
>
>
I suppose in a pinch i could read this in detail, it is a problem i would
like to solve, but you lost my interest at RPSL and i totally tuned out by
the mention of cryptographic signatures... and some blah blah about rpki...
although i did enjoy the inclusion or the random text strings displaying
what entropy looks like

1.  How is this easier than me emailing a spreadsheet to Akamai and others
with subnets and zip codes and make them figure it out?  They are being
paid to figure this out, not me the eyeball network. Put the burden on the
org getting paid.

2. Why can’t arin just provide me a web portal to add city / state info in
my already existing rpki roa form?

I hate paying Merit for radb, i dont want to rely on them and their janky
website for another thing. Every time i touch it i am slightly afraid some
auto generated filter is going blackhole my network because i made a typo,
and they only update their pull of radb every 72 hours ...

Make it is easy, and it will get done ... this excludes rpsl and anything
requiring me to use the openssl command line


>
>

Re: Wildfires: Clear fuel from hilltop and remote area communications towers

[Etienne-Victor Depasquale]

Don, your answer to Eric's valid point is open to broad interpretation -
what is your point, exactly?

On Sat, Sep 12, 2020 at 3:24 AM Don Gould  wrote:

> Eric they have the same issues in Australia.   You might want to join
> aunog, if you haven't already, I'm sure you'll find endorsement for these
> issues.
>
> Fuel management is a problem. Finding the right balance between management
> and ecological issues is political and complex with many vested interests
> driving the narrative.
>
> D
>
>
>
> --
> Don Gould
> 5 Cargill Place
> Richmond
> Christchurch, New Zealand
> Mobile/Telegram: + 64 21 114 0699
> www.bowenvale.co.nz
>
>
>  Original message 
> From: Eric Kuhnke 
> Date: 12/09/20 10:14 am (GMT+12:00)
> To: "nanog@nanog.org list" 
> Subject: Wildfires: Clear fuel from hilltop and remote area communications
> towers
>
> Over the past week I think I've seen about 20 to 30 photos of burnt out
> communications sites in Oregon and California.
>
> Due to the often remote and unstaffed nature of many of these sites,
> there's a natural tendency for brush, shrubs, grass and small trees to grow
> close to the tower compounds on many hilltop sites.
>
> Many of these sites also support emergency communications services.
>
> In the subject line I'm using "fuel" as defined by firefighters, not
> literally meaning petroleum fuels, but anything flammable.
>
> In some places there are ecological or political concerns with maintaining
> a cleared perimeter around telecom tower sites. This might be a time to
> re-visit the logical purpose of some of these policies, if allowing fuel to
> grow right up to the tower and telecom equipment shelters greatly increases
> the likelihood of the whole thing going up in flames.
>
>
>
>

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale