Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Axel Beckert]

Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 RM: aiccu -- ROM; SixXS has been shut down and no 
replacement popped up within 3 months
Control: reassign -2 ftp.debian.org

Hi,

Ansgar Burchardt wrote:
> SixXS will shutdown on 2017-06-06[1].  Unless there are other tunnel
> providers used with aiccu, it seems useless to include in stretch.
> >From a quick glance at [2], SixXS is the only provider using AYIYA and
> TIC which is what I believe aiccu implements.

What I've written in https://bugs.debian.org/864783 three months ago
is still valid:

> And unfortunately, neither
>
> * SixXS changed their mind, nor
> * did SixXS open-source the server implementation, nor
> * did someone else come up with an AYIYA(*) server implementation or a
>   comparable service.

Also citing from that mail:

> Mike and me agreed to keep it around in Debian Unstable for at least a
> few more months in the hope that any of the above mentioned events
> still happen. If neither of these events happen (within a year or so),
> we'll likely let aiccu also be removed from Debian Unstable.

3 months are now over and there's no sign of improvement of the
situation. So let's remove aiccu from unstable, too.

We'll definitely leave the git repo under collab-maint, in case
there's a reason to resume maintaining an aiccu package in Debian.

P.S.: I'm keeping the RC bug open for aiccu so that it doesn't
propagate to testing while waiting for being removed. Hence the clone
instead of just reassigning.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Axel Beckert]

Hi once again,

Ansgar Burchardt wrote:
> From a quick glance at [2], SixXS is the only provider using AYIYA and
> TIC

JFTR: It's not necessary that a (3rd party) tunnel service provider
exists for using aiccu. What equally suffices to make use of it (and
hence IMHO validates its existence in Debian) is freely available code
for tunnel servers you can run yourself.

> which is what I believe aiccu implements.

According to the README, aiccu also supports other tunneling
protocols, namely two variants of 6in4/RFC 2893. According to the man
page it additionally also supports TINC.

There surely exist other server backends for 6in4 and TINC. I though
haven't found any other AYIYA server implementation.

Leaves us with TIC, the Tunnel Information and Control protocol. We
also need a server for that as TIC seems to be the common ground for
all the above mentioned tunneling protocols if used with aiccu.

And for TIC, there exists at least one free server implementation
(although so far not packaged for Debian):

https://metacpan.org/pod/Net::SixXS::TIC::Server
https://metacpan.org/pod/distribution/Net-SixXS/script/sixxs-tic-server

While it only seems to allow one user, it seems to suffice to tell
aiccu where it should connect to, at least according to its
description.

I will probably play around with that to become my own tunnel
provider, but that will be unlikely before the release of Stretch.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Pim van Pelt]

On Tue, May 30, 2017 at 11:05 PM, Axel Beckert  wrote:
> Control: severity -1 important
> Control: tag -1 confirmed
>
> Hi Ansgar,
>
> Ansgar Burchardt wrote:
>> Severity: serious
>
> I disagree with severity.
>
>> SixXS will shutdown on 2017-06-06[1].
>
> Yes, well-known and already discussed (on IRC IIRC) by us package
> maintainers.
>
>> Unless there are other tunnel providers used with aiccu, it seems
>> useless to include in stretch.
>
> Yes, but before we decide to pull the line I want to wait until _at
> least_ that date (which is next week and not today) and _not_ pull the
> line _before_ this date.
Agreed, although the install base won't change between now and the
sunset, so I'm not too fussed about in-or-out at this point. See below
though.
> Pim van Pelt wrote:
>> It may be in our future to opensource the server implementation
>
> Any reason why you can't publish it as is?
https://sixxs.net/sunset describes this, here's the pertinent language:

| Will you open source SixXS code?
|
| We do not currently have plans to open source any code that is not
already publicly available.
| Although our provisioning servers and routing daemon (sixxsd) are
very well thought out, they
| do have some intricate dependencies on how we built SixXS. As such,
offering the code base
| will not be necessarily useful for others. Over time, given effort
on Jeroen’s part, this may
| change. We cannot make any promises at this point.

Additional thought -- I do not look forward to explaining to several
integrators how to use the server code, although it's reasonably
standalone, the SixXS server works in conjunction with our automation
bits on the provisioning server side. Also worth pointing out, if
you're interested, is this piece:

| Will you hand over the project to other folks?
|
| We are fairly protective of our brand and position in the community.
Due to the nature of SixXS,
| which rests on an open source client (aiccu) with a closed source
server (sixxsd), we are not
| willing to hand over the project. However, that aside, the main
justification for our decision as
| outlined in this document, is that we are of the belief that IPv6
Tunnel Brokers are no longer
| facilitating access providers moving to IPv6, and as such do not
wish for the project to be
| continued. Handing it over to other folks will not allow us to
satisfy our concerns.

If my mission is to stop tunnelbrokers, opensourcing the code is not
productive. However, we may change our mind after a certain cool-down
period. Time will tell, which is why I was opting for a resubmission
iff we decide to go that route.


>> but at that point we can stand up a repo for ourselves.
>
> This comment by Pim makes me even think that we should keeping it in
> Stretch. Because why else should upstream keep a Debian package
> maintained in an external repo if a suitable server will be available
> soon-ish?
>
>> Would you be open to resubmitting in such a scenario?
>
> Sure.
Thanks!

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Axel Beckert]

Control: severity -1 important
Control: tag -1 confirmed

Hi Ansgar,

Ansgar Burchardt wrote:
> Severity: serious

I disagree with severity.

> SixXS will shutdown on 2017-06-06[1].

Yes, well-known and already discussed (on IRC IIRC) by us package
maintainers.

> Unless there are other tunnel providers used with aiccu, it seems
> useless to include in stretch.

Yes, but before we decide to pull the line I want to wait until _at
least_ that date (which is next week and not today) and _not_ pull the
line _before_ this date.

Pim van Pelt wrote:
> It may be in our future to opensource the server implementation

Any reason why you can't publish it as is?

> but at that point we can stand up a repo for ourselves.

This comment by Pim makes me even think that we should keeping it in
Stretch. Because why else should upstream keep a Debian package
maintained in an external repo if a suitable server will be available
soon-ish?

> Would you be open to resubmitting in such a scenario?

Sure.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Pim van Pelt]

Agreed. It may be in our future to opensource the server implementation but
at that point we can stand up a repo for ourselves. Would you be open to
resubmitting in such a scenario?

Pim

On May 30, 2017 14:09, "Ansgar Burchardt"  wrote:

> Source: aiccu
> Version: 20070115-17
> Severity: serious
>
> SixXS will shutdown on 2017-06-06[1].  Unless there are other tunnel
> providers used with aiccu, it seems useless to include in stretch.
> From a quick glance at [2], SixXS is the only provider using AYIYA and
> TIC which is what I believe aiccu implements.
>
> Ansgar
>
>   [1] 
>   [2] 
>
>

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Ansgar Burchardt]

Source: aiccu
Version: 20070115-17
Severity: serious

SixXS will shutdown on 2017-06-06[1].  Unless there are other tunnel
providers used with aiccu, it seems useless to include in stretch.
>From a quick glance at [2], SixXS is the only provider using AYIYA and
TIC which is what I believe aiccu implements.

Ansgar

  [1] 
  [2]