Hi Wes,
On Oct 28, 2011, at 1:52 PM, Wes Beebee wrote:
> What happens when both RA and DHCPv6 are configured?
Both sets of routes are configured.
This is exactly analogous to a situation where RAs are used and an
administrator has configured some routes using a configuration tool like
"rout
On Oct 18, 2011, at 2:29 PM, Jari Arkko wrote:
> 2. Whether to allocate an EUI-64 from the IANA block and base the IID on
> that, or to allocate just a reserved value per RFC 5453. Collisions are
> extremely unlikely in either case. Personally, I'd prefer an EUI-64 based
> approach though, beca
On Sep 27, 2011, at 3:15 PM, Manfredi, Albert E wrote:
> Doesn't seem logical to conclude that a NAT would be involved in any of this.
> But even if it is, what's wrong with a "basic NAT," i.e. one that provides a
> simple one to one mapping for a subset of the internal addresses?
If you do nee
I had a thought on the use of zero UDP checksums in IPv6...
What if we allowed the use of zero checksums for UDP as a _negotiated
option_ in IETF tunneling protocols? Those protocols could default to
the use of UDP Lite (or UDP with non-zero checksums if their designers
prefer) and negoti
Hi Vijayrajan,
On Oct 7, 2009, at 12:25 PM, Vijayrajan ranganathan wrote:
Hi Everyone,
Is there a notion that auto-configured IPv6 addresses based on
globally unique prefixes are transient compared to manually configured
ones?
Auto-configured global IPv6 addresses are "leased" to an interfac
On Aug 11, 2009, at 2:45 PM, Dino Farinacci wrote:
I was talking about running an ITR as a logical interface on a LISP-
aware end-node or a home gateway, so I'm not talking about
something that would need to scale to handle 100K simultaneous
connections.
Doesn't matter. You can still talk
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping cache
and the results of mapping lookups?
Because you could have 100K of them. Interface data structures co
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
We call "LISP t
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum fie
Hi Steinar,
On Aug 11, 2009, at 4:11 AM, sth...@nethelp.no wrote:
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set
of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packet
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
So, if I want LISP on a non-open-source desktop, you think I
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly dep
Hi Havard,
On Aug 7, 2009, at 8:22 PM, Havard Eidnes wrote:
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a
IPv6
packet?
Um, sur
Does UDP-Lite work through NAT
boxes? (LISP has a mobile-node mode, which we would like to see
work through
NAT boxes, so any proposed alternative solution has to work through
NAT boxes
too.)
For IPv6?
Sorry I didn't reply to this in the earlier message...
(1) There isn't enough NAT de
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packets received, 0 dropped due to bad checksum (ip
header checksum)
1,004,72
Hi Noel,
On Aug 7, 2009, at 3:31 PM, Noel Chiappa wrote:
From: Francis Dupont
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a IPv6
p
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
=> in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and simpl
Hi Fred,
On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote:
How are non-TCP/UDP flows handled by these legacy systems
today? For example, 6to4 uses ip-proto-41.
My understanding is that these flows will not be handled well...
Since ECMP load balancers will have limited information availab
Hi Fred,
There are three things we are trying to address here:
- We want to support load balancing through legacy systems that only
support load balancing based on the 5-tuple of IP src/dest address,
protocol/next header and UDP or TCP src/dest ports. To meet this goal,
we need a UDP (or
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will
only identify flows using the 5-tuple described in the draft. These
devices d
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we (as a
group) are assuming that the reasons for requiring ipv6 udp checksums
as stated +10 years ago are still valid, I don't see data supporting
that fact.
There are some cl
On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
What was the original reason for removing the ability to do zero
checksums on udp in v6? Are we sure that that decision is still
sensible/appropriate in today's internet/world?
I have not been around long enough to have been there when tha
Hi Joel,
On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote:
Reading this discussion, there seem to be a small number of
practical choices.
If the vendor hardware that is / will be handling IPv6 can handle
the flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to u
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
vendors to adopt the IPv6 flow-label as input-keys to their hash-
calculations for LAG/ECMP, it takes [a lot] of time to see that
materialize in the field. Practic
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
Hi Noel,
On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote:
Dino, why don't we just drop the 'inside IPv6' encapsulations from
the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6
encapsulations could be
documented in a short non-IETF note that's posted on a personal web
page
s
Hi Noel,
On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote:
Dino, why don't we just drop the 'inside IPv6' encapsulations from
the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6
encapsulations could be
documented in a short non-IETF note that's posted on a personal web
page
s
Hi Byzek,
On Jul 30, 2009, at 8:31 PM, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can’t do UDP checksum calculations during encapsulation
because it
doesn’t have access to the entire packet. Most hardware is
streamlined to
only provide
On Aug 4, 2009, at 7:28 AM, Iljitsch van Beijnum wrote:
On 31 jul 2009, at 9:06, Rémi Denis-Courmont wrote:
Sounds like this would require a third datagram protocol number, that
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UD
On Aug 3, 2009, at 5:15 PM, Rémi Denis-Courmont wrote:
(1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable
choice for LISP encapsulation? When we looked into this for CAPWAP
(another IP-in-UDP/IP tunneling case), we found that UDP-Lite would
meet our needs for IPv6, so we did not
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev this shortly and comments would be appreciated.
If you do rev this document, I would like to see:
(1) An explanation of the difference in applicability between this
Hi Pekka,
On Jul 31, 2009, at 3:47 AM, Pekka Savola wrote:
On Thu, 30 Jul 2009, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can¹t do UDP checksum calculations during encapsulation
because it
doesn¹t have access to the entire packet. Most h
On Jul 31, 2009, at 3:06 AM, Rémi Denis-Courmont wrote:
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like there is opposition to overloading UDP-Lite. Then the 64-
translators
would convert it t
On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote:
What I'm saying is that *if* UDP us used, it needs to be used
according to the RFCs that capture the IETF consensus on their use,
or the IETF consensus must be revised.
And what we are are saying is to be practical (and sensible).
Well,
Hi Dino.
We also need to consider the possibility that a packet will be
received by a different LISP node than the one for which it was
intended, or that it will arrive at the correct LISP destination
with the wrong source address in the external header. What happens
in those cases?
Hi Dino,
On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote:
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how muc
Hi Dino,
On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote:
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how muc
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the "outer"
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the "outer"
Hi Remi,
On Jul 27, 2009, at 4:27 PM, Rémi Després wrote:
Two constraints on IPv6 address formats appear to be unnecessary
while prohibiting some designs that are useful to enhance IPv6
benefits:
- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these addres
Hi Remi,
On Jul 27, 2009, at 4:27 PM, Rémi Després wrote:
Two constraints on IPv6 address formats appear to be unnecessary
while prohibiting some designs that are useful to enhance IPv6
benefits:
- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these addres
Hi Bob and Brian,
Could you tell me which drafts correspond the following agenda items:
- DSL Line Identification using Rtr. Sol.
- Ephemeral IPv6 Addresses
- IPv6 Address State Extension
- Domain name-based interface selection
- Load balancing on IPv6 anycast address
Thanks,
Margaret
On Nov
Has there been any resolution on how/if it will be possible to attend
this meeting remotely (conference bridge, web conference, jabber room,
etc.)?
I will not be able to travel to Montreal, but would like to attend all
or part of the meeting remotely, if possible.
Thanks,
Margaret
On Sep
w-6man-ulac-analysis-01
A new version of I-D, draft-mrw-6man-ulac-analysis-01.txt has been
successfuly submitted by Margaret Wasserman and posted to the IETF
repository.
Filename:draft-mrw-6man-ulac-analysis
Revision:01
Title: An Analysis of Centrally Assigned Unique
-Original Message-
From: Margaret Wasserman [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 5:36 PM
To: Per Heldal
Cc: ipv6@ietf.org
Subject: Re: New Version Notification for
draft-mrw-6man-ulac-analysis-00
Hi Per,
Regardless of the listed arguments one may also question IETFs
Hi Per,
Regardless of the listed arguments one may also question IETFs role in
the definition of (any) ULA as there is no technical reason why
such an
address-block must be tagged 'special'.
Thanks for raising this point. Others have made a similar argument
in the past, and it should de
ge:
From: IETF I-D Submission Tool <[EMAIL PROTECTED]>
Date: November 11, 2007 10:16:15 PM EST
To: [EMAIL PROTECTED]
Subject: New Version Notification for draft-mrw-6man-ulac-analysis-00
A new version of I-D, draft-mrw-6man-ulac-analysis-00.txt has been
successfuly submitted by Margaret Wass
ge: en-us, en
To: Margaret Wasserman <[EMAIL PROTECTED]>,
Mark Townsley <[EMAIL PROTECTED]>,
Robert Hinden <[EMAIL PROTECTED]>,
Brian Haberman <[EMAIL PROTECTED]>
Subject: Fwd: IPR Notification
X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001);
[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]
Hi All,
We have created an Internet Area mailing list -- [EMAIL PROTECTED]
This list will be used to announce Internet area BOFs, to discuss
Internet area WG charter updates and to discuss other issues related
to the Interne
Hi Suresh,
Thanks for the quick turnaround!
When the new draft comes out, I will send it to IETF LC. After we
make it through IETF LC, the document will be reviewed by the full
IESG. So, at this point, there are no further changes that need to
be made, but you may need to make changes base
I have a process-related concern with draft-ietf-ipv6-ndproxy-02.txt
that I would like to discuss on this list to see what others think...
I haven't reached the point (yet) where I have a fully-formed
objection, but I have a strong enough concern that I thought it would
be worth some discuss
Hi Jinmei,
At 2:57 AM +0900 5/14/05, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
I've asked related questions about this comment on the wg list two
times, including requested information at the Minneapolis meeting, but
I've not got any responses...if this comment does not require
At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.2 Conventions used in this document . . . . . . . . . . . . 5
Why is the RFC 2119 section
Hi All,
I have a few AD Review comments on
draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have
resolved before I send this document to IETF LC. I've included those
comments below.
Brian and Bob, the tracker indicates that this document is intended
for publication as a Draft Standard
Hi All,
I have finished my AD review of
draft-ietf-ipv6-optimistic-dad-05.txt. I found no blocking issues,
and I have sent the document to IETF Last Call.
Margaret
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrat
Hi Bob,
Should there also be an upate to the IANA considerations section
asking IANA to list this allocation as deprecated?
Margaret
At 11:46 AM -0800 3/16/05, Bob Hinden wrote:
Hi,
At last weeks IPv6 session in Minneapolis, the working group reached
a consensus to deprecate the "IPv4-compatible
This looks good to me, Bob.
Let me know when the IPv6 WG is comfortable with the text, and I will
put in an RFC Editor note and approve the document.
Thanks,
Margaret
At 5:58 PM -0800 3/10/05, Bob Hinden wrote:
Here is what I hope to be the final update.
Thanks,
Bob
---
4.
Hi All,
During IESG review, Mark Andrews raised a significant operational
concern regarding the DNS section of the ULA document
(draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently
delaying approval of the document until the issue can be resolved.
The concern, which is shared by other
Hi Dave,
Point taken. How about:
A proxy MUST ensure that loops are prevented, either by running
the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
proxy interfaces as described below, or by being deployable only in
an environment where physical loops cannot occur. For example, in
On Wed, Dec 08, 2004 at 09:27:50AM -0500, Brian Haberman wrote:
I agree that it is a problem, but not one specific to ULAs.
Indeed, it's the dont-publish-unreachables's draft space... but that one
never reached consensus or thus publication.
Right. And, while I personally agree with the
don't-pu
Hi Mark,
Thats why I said the DNS section was a "cop out". The DNS
information hadn't been collected, distilled and put on
paper. I attempted to do that.
* Don't publish ambigious addresses global.
* It is unwise (but not wrong) to publish unreachable addre
Hi Pekka,
There is a new version of this document available at:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt
Could you check if it addresses your substantial concerns?
Margaret
At 12:15 AM +0200 11/13/04, Pekka Savola wrote:
On Sat, 30 Oct 2004, The IESG wrote:
The
Hi Jinmei,
Sorry, but I seem to have failed to respond to this message...
At 5:26 AM +0900 11/5/04, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
I basically think we should publish 2461bis and 2462bis at the same
timing with consistent changes. So, it would make sense to hold one
At 3:39 AM +0900 11/5/04, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
Thanks, but don't you actually mean this one?
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
(At least RFC3315 does not call itself "Dynamic Host Configuration
Protocol version 6").
You are c
HI Jinmei,
Thank you for making these changes. The changes you've made do a
very good job of reflecting my feedback. I believe that the document
is much clearer and more concise with the changes you have made, and
the document with the changes is acceptable to me. Do you agree that
these cha
At 2:54 PM -0500 11/3/04, Dan Lanciani wrote:
Is this ARIN discussion archived somewhere?
The discussion I've seen happened on a mailing list archived at:
http://www.arin.net/mailing_lists/ppml/index.html
I'm not on the list, and the archives seem to end shortly after this
discussion was started o
At 7:53 PM +0200 11/2/04, Pekka Savola wrote:
http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html
Generic comment: is token really on Margaret w/ all of those AD
followup documents?
Hi Pekka,
Sort of... When a document is updated, the document automatically
goes to the AD
At 1:12 PM +0200 10/30/04, Brian E Carpenter wrote:
Because it has no *reasonable* use? Is it reasonable to use HTTP this way?
It doesn't really bother me that it isn't covered by the latest URI syntax
(and therefore not by IRI syntax). I must say I have largely ignored
the whole scoped address
et
At 2:28 PM -0600 10/29/04, JORDI PALET MARTINEZ wrote:
Hi Margaret,
Why not ? We are using the [] to enclose the IPv6 address, so then the %
will be also inside the square brackets, right ?
Regards,
Jordi
De: Margaret Wasserman <[EMAIL PROTECTED]>
Responder a: [EMAIL PROTECTED]
Fecha:
Hi All,
We're having a discussion on URIs and IRIs in the IESG that has led
me to realize that the URL literal IPv6 address format described in
RFC 2732 does not contain any provision for including a zone ID. I
don't think that we could simply add a "%zone-id" to the end of the
IP address, bec
Hi Jinmei,
Thanks for the response!
If we remove "stateful" from rfc2462bis, I think we'd also need to
change the name of the bit in rfc2461bis accordingly. Otherwise, the
result would rather be more confusing. So I asked the wg whether
- we should clean up all the occurrences of "stateful" and r
Hi Jinmei,
I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have
several comments on this document that I believe should be resolved
before this document is sent to IETF Last Call for publication as a
Draft Standard.
All of my comments are included below, but my most serious con
Hi All,
I support the idea of splitting this draft into two portions for
several reasons.
First, some facts as I understand them:
(1) The uncertainty regarding the status of unicast site-local
addressing and its eventual deprecation has caused concerns for
enterprises considering the deployment
At 12:56 PM +0200 3/23/04, Jari Arkko wrote:
I think it would be possible to detect loops if we wanted really
hard to do that. That might just
lead to reinvention of the spanning tree protocol, though.
This is a danger, yes.
Why is this a danger?
IMO, the ND proxy mechanism effectively does br
Apparently there are some people in the IETF who use mail readers
that cannot handle standard text attachments. For those people, here
is a resend of the e-mail I sent earlier with the attachment included
in-line. Sorry for the duplication.
Hi All,
I've completed my AD evaluation of
draft-i
Hi All,
I've completed my AD evaluation of
draft-ietf-ipv6-unique-local-addr-03.txt. My comments (attached
below) include a few substantive issues that I would like to discuss
with the WG before sending this draft to IETF last call. Thoughts?
I have also included a few non-blocking editorial
Hi Mukesh,
One of the issues raised was about rate limiting methods
suggested by the draft. The draft suggests Timer-based,
Bandwidth-based and Token-bucket based methods for limiting
the rate of the ICMP messages.
After going through the discussion about this in the archive
and thinking about thi
> => In 6.2.7 :
>
>Routers SHOULD inspect valid Router Advertisements sent by other
>routers and verify that the routers are advertising consistent
>information on a link. Detected inconsistencies indicate
> that one or
>more routers might be misconfigured and SHOULD be logged
> to:
>
>Nodes that implement DHCP MUST use DHCP upon the receipt of a
>Router Advertisement with the 'M' flag set (see section 5.5.3 of
>RFC2462). In addition, in the absence of a router,
>IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this
>context, 'use DH
Hi Eric,
> I have been speaking to different
> companies here in Israel, and the basic answer is that if I
> can not have site locals and NAT then I will not move to IPv6.
If these people are happy with IPv4 NAT, why would they want
to move to IPv6? They couldn't need more address space (net
> The second is the side point I raised with Margaret: in the
> general case of "things in specifications", removing something
> from a specification does not mean that someone can still use
> it. Deprecation protects such a usage, but removal does not.
Scott's posting made a distinction be
Hi Fred,
> So in the general case I don't see a problem with deprecating
> things under the right circumstances, but I do have a problem with
> removing them outright. Deprecation doesn't prevent people from using
> them, but outright removal can be dangerous. And in this case, the
> assertio
Hi Scott,
Speaking only for myself, I would like to address a couple of the
points that you have made.
> It is my opinion that there is a difference between a working group
> deciding to adopt a technology and a working group deciding
> to delete a technology from an existing IETF specificat
ations experts
involved in our discussions and decisions. We hope that you will
continue to participate in the IPv6 WG, that you will continue to
speak out when you see problems, and that you will continue to help
us by getting additional applications experts involved in the IPv6
WG.
Bob Hinden
At 08:57 AM 9/23/2003 +0200, Kurt Erik Lindqvist wrote:
> True, but if we wish to remain relevant, something has to be written
> somewhere. I fully agree that doing so in *this* document may not be
> worth it; it might be worth it in some other doc, e.g. sl-impact.
I agree with Pekka. HAving this
86 matches
Mail list logo