Re: SIP fax sending software?

[Eric Kuhnke]

I would recommend simply outsourcing it to voip.ms for $2 a month. Port
your fax DID to them.

Incoming fax arrive as PDF in your choice of email inbox.

You can send outbound fax from a predefined list of your own email
addresses, destination to f...@voip.ms. Put the destination phone number in
the subject line, attach the document to be faxed as a PDF.

There is also an https web portal for uploading documents to be faxed,
there is no tacky addition of advertisement.

https://wiki.voip.ms/article/Virtual_Fax

On Wed, May 30, 2018 at 1:13 PM, John R. Levine  wrote:

> Can anyone recommend software that sends faxes over SIP?  I have plenty of
> inbound fax to email services, but now and then I need to send a reply and
> it looks tacky to use one of the free web ones that put an ad on it.
>
> I know that if I wanted to pay $15/mo there are lots of lovely services
> but we're taking about one fax a month, maybe, here.
>
> Ideally it'd take a postscript or PDF or Word document and a phone number
> and fax it to that number.  I have Ubuntu, FreeBSD, and MacOS boxes.  Any
> suggestions?
>
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>

Re: ICANN GDPR lawsuit

[Stephen Satchell]

On 06/01/2018 09:37 AM, McBride, Mack wrote:
> For routing whois information there aren't going to be many individuals and 
> it would seem
> that the corporations who employee individuals should be the ones protecting 
> those individuals
> work emails by providing a generic contact email forward.  Which is good 
> practice anyway
> since people leave and go on vacation and problems still happen.
> And the routing whois information is a lot more relevant to most of us here.

+1

Perhaps the Right Thing(SM) to do is to update the best practices
documents regarding role e-mail accounts for network operators.

1.  Add "networkmas...@example.com" to the list of required role accounts.

2.  Require that e-mail sent to role "networkmas...@example.com" be
accessible in some way by all technical people for the network in
question.  This can be done using a ticket system, or a simple mail
exploder.

3.  Require that e-mail sent to role account "ab...@example.com" by
accessible in some way by all members of the abuse desk.  This can be
done using a ticket system, or a simple mail exploder.

4.  Require the WHOIS information specify exactly these role accounts
for TECH and ABUSE, not a person.  This gets around the GDPR
requirements while maintaining the usefulness of the WHOIS without
having to go through an intermediate party or web site.

ICANN may want to consider this idea when adjusting its contracts with
registrars to eliminate GDPR exposure.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 02 Jun, 2018

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  702696
Prefixes after maximum aggregation (per Origin AS):  269990
Deaggregation factor:  2.60
Unique aggregates announced (without unneeded subnets):  337923
Total ASes present in the Internet Routing Table: 60877
Prefixes per ASN: 11.54
Origin-only ASes present in the Internet Routing Table:   52561
Origin ASes announcing only one prefix:   22956
Transit ASes present in the Internet Routing Table:8316
Transit-only ASes present in the Internet Routing Table:278
Average AS path length visible in the Internet Routing Table:   4.0
Max AS path length visible:  30
Max AS path prepend of ASN ( 30873)  28
Prefixes from unregistered ASNs in the Routing Table:50
Number of instances of unregistered ASNs:50
Number of 32-bit ASNs allocated by the RIRs:  22804
Number of 32-bit ASNs visible in the Routing Table:   18382
Prefixes from 32-bit ASNs in the Routing Table:   76690
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:261
Number of addresses announced to Internet:   2860375619
Equivalent to 170 /8s, 125 /16s and 222 /24s
Percentage of available address space announced:   77.3
Percentage of allocated address space announced:   77.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.9
Total number of prefixes smaller than registry allocations:  234878

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   191697
Total APNIC prefixes after maximum aggregation:   54440
APNIC Deaggregation factor:3.52
Prefixes being announced from the APNIC address blocks:  190523
Unique aggregates announced from the APNIC address blocks:78035
APNIC Region origin ASes present in the Internet Routing Table:8841
APNIC Prefixes per ASN:   21.55
APNIC Region origin ASes announcing only one prefix:   2475
APNIC Region transit ASes present in the Internet Routing Table:   1329
Average APNIC Region AS path length visible:4.0
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3821
Number of APNIC addresses announced to Internet:  767462658
Equivalent to 45 /8s, 190 /16s and 141 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:209013
Total ARIN prefixes after maximum aggregation:99347
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   209718
Unique aggregates announced from the ARIN address blocks: 99231
ARIN Region origin ASes present in the Internet Routing Table:18196
ARIN Prefixes per ASN:11.53
A

RE: ICANN GDPR lawsuit

[McBride, Mack]

The whois guard solution seems workable where the registrar just forwards 
information.
It would be nice if there were corporate phone numbers as GDPR doesn't apply to 
corporations.
For routing whois information there aren't going to be many individuals and it 
would seem
that the corporations who employee individuals should be the ones protecting 
those individuals
work emails by providing a generic contact email forward.  Which is good 
practice anyway
since people leave and go on vacation and problems still happen.
And the routing whois information is a lot more relevant to most of us here.
Of course anyone posting to a public list should be aware that their email 
address is
part of that information.  Which is particularly relevant to this list.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
Sent: Friday, June 01, 2018 9:24 AM
To: l...@satchell.net
Cc: nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit

On Fri, Jun 1, 2018 at 8:47 AM, Stephen Satchell  wrote:
> In other words, how do you do your job in light of the GDPR 
> restrictions on accessing contact information for other network operators?
>
> Please be specific.  A lot of NOC policies and procedures will need to 
> be updated.

Publish role accounts in whois instead of personal information?

Sorry, I don't mean to break up an energetic tirade but a phone number is not 
PII when it's attached to "hostmaster" instead of "John Doe".
You and I like knowing that there's a specific person there and it certainly 
helps when auditing public policy compliance but as a technical matter contact 
doesn't have to work that way.

I noticed that Namecheap solved their GDPR problem by simply making their 
"WhoisGuard" product free.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com  b...@herrin.us Dirtside 
Systems . Web: 
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: ICANN GDPR lawsuit

[William Herrin]

On Fri, Jun 1, 2018 at 8:47 AM, Stephen Satchell  wrote:
> In other words, how do you do your job in light of the GDPR restrictions
> on accessing contact information for other network operators?
>
> Please be specific.  A lot of NOC policies and procedures will need to
> be updated.

Publish role accounts in whois instead of personal information?

Sorry, I don't mean to break up an energetic tirade but a phone number
is not PII when it's attached to "hostmaster" instead of "John Doe".
You and I like knowing that there's a specific person there and it
certainly helps when auditing public policy compliance but as a
technical matter contact doesn't have to work that way.

I noticed that Namecheap solved their GDPR problem by simply making
their "WhoisGuard" product free.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: SoftLayer Contact

[Mark Tinka]

On 1/Jun/18 13:03, Jared Mauch wrote:

> I heard back and they corrected the problem.
>
> Reminder to keep your peering contacts handy :-)

And that max-prefix song :-)...

Mark.

Re: ICANN GDPR lawsuit

[niels=nanog]

* l...@satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]:
How does your shop, Niels, go about making contact with an operator 
that is hijacking one of your netblocks, or is doing something weird 
with routing that is causing your customers problems, or has broken 
BGP?


The same as we do now, by posting on NANOG "Can someone from ASx / 
largetelco.com contact me offlist?"



-- Niels.

Re: ICANN GDPR lawsuit

[John Peach]

On 06/01/2018 08:47 AM, Stephen Satchell wrote:

On 06/01/2018 05:24 AM, niels=na...@bakker.net wrote:

* h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]:

The entire whois debacle will only get resolved when some hackers attack
www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
response they get will be "sorry, we can't determine who is attacking
you since that contravenes GDPR", will the EU light bulb go on that
something in GDPR needs to be tweaked.


Please stop inciting lawbreaking, and stop spreading long debunked
talking points.  Both are really inappropriate for this list.


OK, then let's talk about something that IS appropriate for this list.
How does your shop, Niels, go about making contact with an operator that
is hijacking one of your netblocks, or is doing something weird with
routing that is causing your customers problems, or has broken BGP?

I will say right now that in large shops, the owner is NOT the right
contact.  In fact, if things are broken enough you may not be able to
send email to the owner -- he could be isolated.  The registration
authorities want the owner contact for legal reasons.  We poor sods in
the trenches need tech contacts, preferably contacts with clue.

In other words, how do you do your job in light of the GDPR restrictions
on accessing contact information for other network operators?

Please be specific.  A lot of NOC policies and procedures will need to
be updated.

Right now my policies and procedures book says to use WHOIS.  What needs
to change?



$dayjob has approaching 800 domains registered, of which a handful are 
set up for email and the hostmaster address was on only one of those. We 
only discovered the problem when a certificate authority attempted to 
contact us for one of the other domains. At that point I found that 
Network Solutions had removed all our contact information and trying to 
find someone with a clue at NetSol is nigh on impossible.


--
John
PGP Public Key: 412934AC

Re: ICANN GDPR lawsuit

[Stephen Satchell]

On 06/01/2018 05:24 AM, niels=na...@bakker.net wrote:
> * h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]:
>> The entire whois debacle will only get resolved when some hackers attack
>> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
>> response they get will be "sorry, we can't determine who is attacking
>> you since that contravenes GDPR", will the EU light bulb go on that
>> something in GDPR needs to be tweaked.
> 
> Please stop inciting lawbreaking, and stop spreading long debunked
> talking points.  Both are really inappropriate for this list.

OK, then let's talk about something that IS appropriate for this list.
How does your shop, Niels, go about making contact with an operator that
is hijacking one of your netblocks, or is doing something weird with
routing that is causing your customers problems, or has broken BGP?

I will say right now that in large shops, the owner is NOT the right
contact.  In fact, if things are broken enough you may not be able to
send email to the owner -- he could be isolated.  The registration
authorities want the owner contact for legal reasons.  We poor sods in
the trenches need tech contacts, preferably contacts with clue.

In other words, how do you do your job in light of the GDPR restrictions
on accessing contact information for other network operators?

Please be specific.  A lot of NOC policies and procedures will need to
be updated.

Right now my policies and procedures book says to use WHOIS.  What needs
to change?

Re: ICANN GDPR lawsuit

[Hank Nussbacher]

On 01/06/2018 15:24, niels=na...@bakker.net wrote:
> * h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]:
>> The entire whois debacle will only get resolved when some hackers attack
>> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
>> response they get will be "sorry, we can't determine who is attacking
>> you since that contravenes GDPR", will the EU light bulb go on that
>> something in GDPR needs to be tweaked.
>
> Please stop inciting lawbreaking, and stop spreading long debunked
> talking points.  Both are really inappropriate for this list.
>
>
> -- Niels.
>
The point was not to encourage law breaking.  Sorry if that what was
perceived.  The point is that the people who designed GDPR did not take
whois into consideration in the least.  And we  all will suffer because
of that.

-Hank

Re: ICANN GDPR lawsuit

[niels=nanog]

* h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]:

The entire whois debacle will only get resolved when some hackers attack
www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
response they get will be "sorry, we can't determine who is attacking
you since that contravenes GDPR", will the EU light bulb go on that
something in GDPR needs to be tweaked.


Please stop inciting lawbreaking, and stop spreading long debunked 
talking points.  Both are really inappropriate for this list.



-- Niels.

Re: SoftLayer Contact

[Jared Mauch]

I heard back and they corrected the problem.

Reminder to keep your peering contacts handy :-)

- Jared

> On May 31, 2018, at 8:43 PM, Jared Mauch  wrote:
> 
> We noticed this as well and sent peering@ a note.
> 
> - Jared
> 
>> On May 31, 2018, at 8:37 PM, Nikolas Geyer  wrote:
>> 
>> Anybody from SoftLayer (AS36351) on list? You have been leaking 700,000+ 
>> routes to some AMSIX peers for a while now.
>> 
>> Cheers,
>> Nik.
>> 
>> Sent from my iPhone
>