is the API key, which is enabled and has ?Update an existing
> measurement? granted
>
> The error I get back is:
>
> {"error":{"status":400,"code":104,"detail":"JSON parse error - No JSON
> object could be decoded","title":"Bad Request"}}
>
> In case it?s relevant, I?m running curl 7.53.1 on Windows 10.
>
> Thanks in advance for any suggestions.
>
> colin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From camin at ripe.net Thu Apr 6 13:59:05 2017
From: camin at ripe.net (Chris Amin)
Date: Thu, 6 Apr 2017 13:59:05 +0200
Subject: [atlas] Behind the scenes changes to measurement creation
Message-ID: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net>
Dear colleagues,
Today we deployed behind-the-scenes changes to the measurement creation
process, both when using the website and the REST API. These changes
should not have any visible effects, with the exception of improvements
to the measurement API reference[1] to make it easier to see which
options belong to which measurement type.
Although we've tested these changes extensively, they are significant so
I am sending this mail to ask you to please let us know if you notice
any problems or changes when creating measurements.
Kind regards,
Chris Amin
RIPE NCC
[1] https://atlas.ripe.net/docs/api/v2/reference/#!/api/Measurement_List_GET
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From camin at ripe.net Fri Apr 7 12:55:34 2017
From: camin at ripe.net (Chris Amin)
Date: Fri, 7 Apr 2017 12:55:34 +0200
Subject: [atlas] Behind the scenes changes to measurement creation
In-Reply-To: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net>
References: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net>
Message-ID: <58816364-61d7-8f9f-9145-ada4f4b118fb@ripe.net>
Dear all,
There were several problems with these changes that have now been fixed:
* When creating groups of measurements at the same time, only the first
one would have probes scheduled, meaning that the other measurements
would not receive results. This happened for 26 measurement creation
requests before being fixed.
* Measurements were scheduled more slowly so you may have seen delays
before getting results.
* Some measurements created using the API would display an error when
viewing their details on the UI; these measurements have been fixed, and
the problem no longer exists for new measurements.
* The API became temporarily more strict in accepting certain values,
which caused the command-line tools to stop working for some measurement
types. The API has reverted to being more liberal in these cases,
although this may be deprecated in the future -- any changes will be
communicated clearly.
Apologies for any inconvenience that these issues may have caused.
Please do let us know if you notice anything else unusual when
scheduling and using RIPE Atlas measurements.
Kind regards,
Chris Amin
RIPE NCC
On 06/04/2017 13:59, Chris Amin wrote:
> Today we deployed behind-the-scenes changes to the measurement creation
> process, both when using the website and the REST API. These changes
> should not have any visible effects, with the exception of improvements
> to the measurement API reference[1] to make it easier to see which
> options belong to which measurement type.
>
> Although we've tested these changes extensively, they are significant so
> I am sending this mail to ask you to please let us know if you notice
> any problems or changes when creating measurements.
>
> Kind regards,
> Chris Amin
> RIPE NCC
>
> [1] https://atlas.ripe.net/docs/api/v2/reference/#!/api/Measurement_List_GET
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From colin at interisle.net Fri Apr 7 20:42:06 2017
From: colin at interisle.net (Colin Strutt)
Date: Fri, 7 Apr 2017 14:42:06 -0400
Subject: [atlas] Problems trying to add a probe to a measurement
In-Reply-To: <00d701d2abbe$bf030db0$3d092910$@interisle.net>
References: <00d701d2abbe$bf030db0$3d092910$@interisle.net>
Message-ID: <058c01d2afce$a863c400$f92b4c00$@interisle.net>
As a result of some debugging with significant help from Viktor Naumov,
we've been able to solve the problem.
In fact there are two problems:
1. The example in the ripe_atlas_api_V2_manual.pdf is wrong
2. The example shows using curl under UNIX; Windows requires a
completely different approach to make the curl command word.
The example in the manual (page 84) shows JSON that it not accepted by
atlas.ripe.net - the outer "layer" of JSON needs to be removed.
So rather than
'{"probes":[{"action":"add","requested":1,"type":"country","value":"NL"}]}'
you need to use
'{"action":"add","requested":1,"type":"country","value":"NL"}'
And, while the example works on UNIX, it does not work, as shown, on
Windows.
It took a while to work out why.
It appears that, in UNIX the single quote is used to escape the contents in
between, so what gets sent to the HTTP server is just
{"action":"add","requested":1,"type":"country","value":"NL"}
But this "convention" does not work on Windows.
Instead, the single quotes should be removed, and then *every* double-quote
has to be escaped, with a backslash character, in order for the correct JSON
to be sent to the HTTP server.
This is the corrected version of the example in the API manual for a
UNIX-based system:
~$ curl -H "Content-Type: application/json" -H "Accept: application/json" -X
POST -d '{"action":"add","requested":1,"type":"country","value":"NL"}'
https://atlas.ripe.net/api/v2/measurements/100076/participation-requests/?ke
y=YOUR_API_KEY
And this is the version that needs to be used for a Windows system:
C:\> curl -H "Content-Type: application/json" -H "Accept: application/json"
-X POST -d
{\"action\":\"add\",\"requested\":1,\"type\":\"country\",\"value\":\"NL\"}
https://atlas.ripe.net/api/v2/measurements/100076/participation-requests/?ke
y=YOUR_API_KEY
Apologies for the poor line-breaking in the above two examples in this email
message.
colin
From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Colin
Strutt
Sent: Sunday, April 2, 2017 10:38 AM
To: ripe-atlas at ripe.net
Subject: [atlas] Problems trying to add a probe to a measurement
I'm trying to add a probe, by probe number, to an existing, running
measurement, using curl, following the example and description on page 84 of
the "RIPE Atlas API v2 manual". However, I'm getting an error message that
does not clearly point me to the problem, and thus allow me to correct my
error.
Here's what I'm entering (with the <.> as placeholders, explained below)
curl -H "Content-Type: application/json" -H "Accept: application/json" -X
POST -d
'{"probes":[{"action":"add","requested":1,"type":"probes","value":""}]}'
https://atlas.ripe.net/api/v2/measurements//participation-requests/?key=<
a>
where:
is the number of the probe I'm trying to add, and I can access it at
https://atlas.ripe.net/probes/
is the measurement to which I'm trying to add it - it's a running
measurement, and I can access it at https://atlas.ripe.net/measurements/
is the API key, which is enabled and has "Update an existing
measurement" granted
The error I get back is:
{"error":{"status":400,"code":104,"detail":"JSON parse error - No JSON
object could be decoded","title":"Bad Request"}}
In case it's relevant, I'm running curl 7.53.1 on Windows 10.
Thanks in advance for any suggestions.
colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mir at ripe.net Mon Apr 10 14:38:46 2017
From: mir at ripe.net (Mirjam Kuehne)
Date: Mon, 10 Apr 2017 14:38:46 +0200
Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy
In-Reply-To:
References:
Message-ID: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
Dear colleagues,
TraceMON is a client-side tool for visualising network topology
generated by traceroutes reaching one or more targets in a network. It
provides a one-click access to a set of information useful during day to
day operations. Please find more details on RIPE Labs:
https://labs.ripe.net/Members/massimo_candela/tracemon-traceroute-visualisation-network-debugging-tool
Kind regards,
Mirjam Kuhne
RIPE NCC
From randy at psg.com Tue Apr 11 04:45:38 2017
From: randy at psg.com (Randy Bush)
Date: Mon, 10 Apr 2017 19:45:38 -0700
Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy
In-Reply-To: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
References:
<52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
Message-ID:
ok, it is pretty cool. many creds.
is there an api to which, for example, nlring folk could hook
ring-trace?
randy, always making trouble
From mcandela at ripe.net Tue Apr 11 10:02:26 2017
From: mcandela at ripe.net (Massimo Candela)
Date: Tue, 11 Apr 2017 10:02:26 +0200
Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy
In-Reply-To:
References:
<52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
Message-ID: <165B6A2A-22ED-4607-B0B3-A384D9FFFA4A@ripe.net>
Not yet, but it?s matter of time.
The idea is to create an open-source tool able to support whatever traceroute collection. The first release is RIPE Atlas centric, but as soon as I have time I will make it generic.
Of course, the code is open, help on GitHub is welcome
Ciao,
Massimo
> On 11 Apr 2017, at 04:45, Randy Bush wrote:
>
> ok, it is pretty cool. many creds.
>
> is there an api to which, for example, nlring folk could hook
> ring-trace?
>
> randy, always making trouble
From mcandela at ripe.net Tue Apr 11 11:04:54 2017
From: mcandela at ripe.net (Massimo Candela)
Date: Tue, 11 Apr 2017 11:04:54 +0200
Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy
In-Reply-To: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
References:
<52847800-1fd1-ba11-3d70-357e627ca294@ripe.net>
Message-ID:
I received some questions about the exact location of TraceMON in Atlas.
The tool is embedded by default on the detail page of each of the traceroute measurements in RIPE Atlas.
Any RIPE Atlas user can access it by selecting a traceroute measurement in the measurements listing page [1] and clicking on the TraceMON tab.
If you instead want just a quick demo: https://massimo.ripe.net/tracemon/widget/
I will try to collect some interesting cases on the link above.
Ciao,
Massimo
[1] https://atlas.ripe.net/measurements/?search=&status=&af=&kind=2%2C4&age=#!tab-public
> On 10 Apr 2017, at 14:38, Mirjam Kuehne wrote:
>
>
>
> Dear colleagues,
>
> TraceMON is a client-side tool for visualising network topology
> generated by traceroutes reaching one or more targets in a network. It
> provides a one-click access to a set of information useful during day to
> day operations. Please find more details on RIPE Labs:
>
> https://labs.ripe.net/Members/massimo_candela/tracemon-traceroute-visualisation-network-debugging-tool
>
> Kind regards,
> Mirjam Kuhne
> RIPE NCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From georg.kahest at internet.ee Thu Apr 13 11:08:02 2017
From: georg.kahest at internet.ee (Georg Kahest)
Date: Thu, 13 Apr 2017 12:08:02 +0300
Subject: [atlas] status-check misbehaving
Message-ID:
Hello,
Am I misunderstanding something or the status-checks are kind of broken:
Yesterday i made new measurement:
https://atlas.ripe.net/measurements/8038852/
I noticed some probes werent reaching my ipv6 host, so decided to remove
them like you can see from the Probe specifications section.
Now when i goto
https://atlas.ripe.net/api/v2/measurements/8038852/status-check/
I can still see the removed probes in status-check page (which contains
17 errors ) in reality if i'm lookin at measurement probe page i should
have only two errors.
So it seems that status-check isnt updated once probes are removed from
a measurement.
--
Georg Kahest
System Administrator / S?steemiadministraator
Eesti Interneti SA Paldiski mnt 80, 10617 Tallinn
Tel 727 1016
www.internet.ee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
From bryan at digitalocean.com Thu Apr 13 19:40:05 2017
From: bryan at digitalocean.com (Bryan Socha)
Date: Thu, 13 Apr 2017 13:40:05 -0400
Subject: [atlas] Are there plans for faster than 1G anchors?
Message-ID:
We're finding it harder and harder to support the 1G nic interface on the
anchors. We'd love to add more but would need a 10g port at minimum (25G
or 40G would also work).
Are there any plans to update them for networks that can't easily support a
1G nic?
Bryan Socha
Network Engineer
DigitalOcean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From anandb at ripe.net Tue Apr 18 11:18:47 2017
From: anandb at ripe.net (Anand Buddhdev)
Date: Tue, 18 Apr 2017 11:18:47 +0200
Subject: [atlas] RIPE Atlas Maintenance Today
Message-ID: <28f52c5533d37c347d17d68a73fce651@ripe.net>
Dear colleagues,
Today, between 11:15 and 16:00 (UTC+2) we will be performing maintenance
on the RIPE Atlas infrastructure. Some probes may disconnect briefly
during this time.
Kind regards
Anand Buddhdev
Senior Engineer
From alexmil at ics.forth.gr Tue Apr 18 14:04:00 2017
From: alexmil at ics.forth.gr (Alexandros Milolidakis)
Date: Tue, 18 Apr 2017 14:04:00 +0200
Subject: [atlas] Behind the scenes changes to measurement creation
In-Reply-To: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net>
Message-ID:
Hi Chris ,
It seems that stop_time , start_time etc don't work anymore.
For example picking all trace route measurements which stopped before yesterday yields no results.
https://atlas.ripe.net:443/api/v2/measurements/?stop_time__lt=1492469625&type=traceroute
Could you take look?
Thanks
Alex
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From camin at ripe.net Tue Apr 18 15:26:41 2017
From: camin at ripe.net (Chris Amin)
Date: Tue, 18 Apr 2017 15:26:41 +0200
Subject: [atlas] Behind the scenes changes to measurement creation
In-Reply-To:
References:
Message-ID: <68c9539b-bb68-1a13-b031-c407a4f43f87@ripe.net>
Dear Alex,
Apologies, thank you for picking up on this. The stop_time and
start_time lt, lte, gt and gte fields were incorrectly working like
their exact match counterpart. This has now been fixed and these filters
should work as expected.
Kind regards,
Chris
On 18/04/2017 14:04, Alexandros Milolidakis wrote:
> Hi Chris ,
> It seems that stop_time , start_time etc don't work anymore.
> For example picking all trace route measurements which stopped before yesterday yields no results.
> https://atlas.ripe.net:443/api/v2/measurements/?stop_time__lt=1492469625&type=traceroute
> Could you take look?
> Thanks
> Alex
>
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From camin at ripe.net Wed Apr 19 12:08:01 2017
From: camin at ripe.net (Chris Amin)
Date: Wed, 19 Apr 2017 12:08:01 +0200
Subject: [atlas] status-check misbehaving
In-Reply-To:
References:
Message-ID: <179f6e82-711d-93ce-d919-e3c5c3f4d236@ripe.net>
Dear Georg,
The current behaviour is for all probes that have returned results in
the past three days to be included in the status-check report. That's
why removing the probes from the measurement did not immediately remove
them from the status-check.
We will review this behaviour because I can see how it is desirable to
be able to immediately remove probes from the status check, and users
will generally not care about results from probes that they have
explicitly removed. For now your status-check does not include the old
probes since they were removed more than three days ago -- if you have
to remove more probes just keep in mind that the effect is not currently
immediate.
Kind regards,
Chris Amin
RIPE NCC
On 13/04/2017 11:08, Georg Kahest wrote:
> Hello,
>
> Am I misunderstanding something or the status-checks are kind of broken:
>
> Yesterday i made new measurement:
>
> https://atlas.ripe.net/measurements/8038852/
>
> I noticed some probes werent reaching my ipv6 host, so decided to remove
> them like you can see from the Probe specifications section.
>
> Now when i goto
> https://atlas.ripe.net/api/v2/measurements/8038852/status-check/
>
> I can still see the removed probes in status-check page (which contains
> 17 errors ) in reality if i'm lookin at measurement probe page i should
> have only two errors.
>
> So it seems that status-check isnt updated once probes are removed from
> a measurement.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From romeo.zwart at ripe.net Thu Apr 20 16:10:39 2017
From: romeo.zwart at ripe.net (Romeo Zwart)
Date: Thu, 20 Apr 2017 16:10:39 +0200
Subject: [atlas] Are there plans for faster than 1G anchors?
In-Reply-To:
References:
Message-ID: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net>
Hi Bryan,
On 17/04/13 19:40 , Bryan Socha wrote:
> We're finding it harder and harder to support the 1G nic interface on
> the anchors. We'd love to add more but would need a 10g port at
> minimum (25G or 40G would also work).
>
> Are there any plans to update them for networks that can't easily
> support a 1G nic?
Interesting question. :) I can see the logic of this from the
perspective of some operators. However, we are not considering adding
10GE or higher port speeds to the RIPE Atlas anchors. The reasons for
this are manyfold:
- Though this would possibly be technically feasible with some Soekris
models that have PCI Express capabilities, there would be a non-trivial
and as yet undefined amount of engineering work involved for us to make
this an operationally supported option.
- By expanding hardware support options we increase the burden on our
limited-resourced operational team.
- The current GE port speed already is a significant overkill for a
measurement network that is not designed to do capacity/throughput
tests. As a side note: we also have a strong requirement from many of
our anchor hosts in other regions of the world to keep the actual
bandwidth requirements for the anchors in the order of kilobits per
second or less.
- Our assessment is that most of our anchor hosts (current and
prospective) will be able to support 1G somewhere in their networks for
at least the next 3-5 years.
I hope this clarifies our reasoning and addresses your question.
Kind regards,
Romeo
> Bryan Socha
> Network Engineer
> DigitalOcean
>
From colinj at mx5.org.uk Thu Apr 20 16:26:11 2017
From: colinj at mx5.org.uk (Colin Johnston)
Date: Thu, 20 Apr 2017 15:26:11 +0100
Subject: [atlas] Are there plans for faster than 1G anchors?
In-Reply-To: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net>
References:
<48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net>
Message-ID:
vm virtual image would be great though so that underlying network would be transparent to the application.
Colin
> On 20 Apr 2017, at 15:10, Romeo Zwart wrote:
>
> Hi Bryan,
>
> On 17/04/13 19:40 , Bryan Socha wrote:
>> We're finding it harder and harder to support the 1G nic interface on
>> the anchors. We'd love to add more but would need a 10g port at
>> minimum (25G or 40G would also work).
>>
>> Are there any plans to update them for networks that can't easily
>> support a 1G nic?
>
> Interesting question. :) I can see the logic of this from the
> perspective of some operators. However, we are not considering adding
> 10GE or higher port speeds to the RIPE Atlas anchors. The reasons for
> this are manyfold:
>
> - Though this would possibly be technically feasible with some Soekris
> models that have PCI Express capabilities, there would be a non-trivial
> and as yet undefined amount of engineering work involved for us to make
> this an operationally supported option.
> - By expanding hardware support options we increase the burden on our
> limited-resourced operational team.
> - The current GE port speed already is a significant overkill for a
> measurement network that is not designed to do capacity/throughput
> tests. As a side note: we also have a strong requirement from many of
> our anchor hosts in other regions of the world to keep the actual
> bandwidth requirements for the anchors in the order of kilobits per
> second or less.
> - Our assessment is that most of our anchor hosts (current and
> prospective) will be able to support 1G somewhere in their networks for
> at least the next 3-5 years.
>
> I hope this clarifies our reasoning and addresses your question.
>
> Kind regards,
> Romeo
>
>
>
>
>> Bryan Socha
>> Network Engineer
>> DigitalOcean
>>
>
>
From bryan at digitalocean.com Thu Apr 20 17:35:37 2017
From: bryan at digitalocean.com (Bryan Socha)
Date: Thu, 20 Apr 2017 11:35:37 -0400
Subject: [atlas] Are there plans for faster than 1G anchors?
In-Reply-To:
References:
<48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net>
Message-ID:
VM image or maybe follow what nlnog's the ring did and automate with an
anchor sponsor giving you a base install you can control. That's even
easier for me to support then dealing with specific hardware.
But this is something to think about for future proofing and not requiring
sponsors to find a spot and put it in more ideal locations. Depending on
cost, maybe something like moving up to 10g ports that would support 1G
with sfp-t adapters. We looked into that for our hardware and turned out
we just can't do 1G on most of the hardware we are using these days. Food
for thought on what the future anchor design should be as for us it's not
about needing 10g bandwidth, it's having a 1G port to plug it into that has
become a challenge.
Bryan Socha
Network Engineer
DigitalOcean
On Thu, Apr 20, 2017 at 10:26 AM, Colin Johnston wrote:
> vm virtual image would be great though so that underlying network would be
> transparent to the application.
>
> Colin
>
> > On 20 Apr 2017, at 15:10, Romeo Zwart wrote:
> >
> > Hi Bryan,
> >
> > On 17/04/13 19:40 , Bryan Socha wrote:
> >> We're finding it harder and harder to support the 1G nic interface on
> >> the anchors. We'd love to add more but would need a 10g port at
> >> minimum (25G or 40G would also work).
> >>
> >> Are there any plans to update them for networks that can't easily
> >> support a 1G nic?
> >
> > Interesting question. :) I can see the logic of this from the
> > perspective of some operators. However, we are not considering adding
> > 10GE or higher port speeds to the RIPE Atlas anchors. The reasons for
> > this are manyfold:
> >
> > - Though this would possibly be technically feasible with some Soekris
> > models that have PCI Express capabilities, there would be a non-trivial
> > and as yet undefined amount of engineering work involved for us to make
> > this an operationally supported option.
> > - By expanding hardware support options we increase the burden on our
> > limited-resourced operational team.
> > - The current GE port speed already is a significant overkill for a
> > measurement network that is not designed to do capacity/throughput
> > tests. As a side note: we also have a strong requirement from many of
> > our anchor hosts in other regions of the world to keep the actual
> > bandwidth requirements for the anchors in the order of kilobits per
> > second or less.
> > - Our assessment is that most of our anchor hosts (current and
> > prospective) will be able to support 1G somewhere in their networks for
> > at least the next 3-5 years.
> >
> > I hope this clarifies our reasoning and addresses your question.
> >
> > Kind regards,
> > Romeo
> >
> >
> >
> >
> >> Bryan Socha
> >> Network Engineer
> >> DigitalOcean
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gert at space.net Thu Apr 20 17:48:21 2017
From: gert at space.net (Gert Doering)
Date: Thu, 20 Apr 2017 17:48:21 +0200
Subject: [atlas] Are there plans for faster than 1G anchors?
In-Reply-To:
References:
<48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net>
Message-ID: <20170420154821.GB25069@Space.Net>
Hi,
On Thu, Apr 20, 2017 at 03:26:11PM +0100, Colin Johnston wrote:
> vm virtual image would be great though so that underlying network would be transparent to the application.
Welcome back, we've missed your contributions.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: